Что такое трассировка маршрута в Windows (tracert) и Linux (traceroute): разбор Бородача

Всем привет! Как вы уже поняли, сегодня я подробно, но максимально кратко попробую рассказать про то – что же такое трассировка маршрута в локальных и глобальных сетях. Также расскажу, в чем отличие измерения трассировки в Windows и Linux. Некоторые думают, что при вводе примерно одинаковых команд инженер будет получать одну и ту же информацию, но на деле это не совсем так – об этом поподробнее чуть ниже. Если у вас будут какие-то вопросы и дополнения, то пишите в комментариях.

ПРИМЕЧАНИЕ! Трассировка маршрута не «ускоряет интернет» и ничего сама не чинит. Это диагностический инструмент. Он показывает, через какие маршрутизаторы примерно идет трафик до нужного сайта, сервера или IP-адреса. По результату можно понять, где начинается задержка, где пакеты перестают отвечать и на каком участке сети может быть проблема.

Определение

Трассировка – по сути это тестирование, при котором пользователь может увидеть, по какому пути проходит пакет данных до конечного сервера. То есть через какие узлы он проходит и с какой задержкой. Например, при стандартной команде «Ping» вы получите информацию о времени отклика или время отправки и приема пакета. А при трассировке вы увидите через какие IP узлов проходит этот самый пакет до конечного сервера.

Проще говоря, ping отвечает на вопрос: «Сервер вообще отвечает и какой до него примерный отклик?». А трассировка отвечает на другой вопрос: «Через какие промежуточные маршрутизаторы мы идем до этого сервера?». Например, если игра тормозит, ping может показать высокий отклик до сервера. Но только трассировка поможет увидеть, где именно начинается скачок задержки: уже у вас дома, на узле провайдера, на магистральном операторе или ближе к самому игровому серверу.

Часто данной утилитой пользуются инженеры или системные администраторы, чтобы выявить слабые стороны сети. В общем, штуковина полезная почти для всех. Далее я расскажу, как сделать трассировку до сайта или до выделенного игрового сервера, а также как вообще ею пользоваться.

ВАЖНО! Не делайте вывод по одной трассировке. Маршруты в интернете могут меняться, часть узлов может не отвечать на диагностические запросы, а некоторые маршрутизаторы специально режут ICMP или UDP-ответы. Если проблема плавающая, лучше сделать несколько трассировок в разное время и сравнить результат. Для полной картины полезно проверить еще и обычный ping – подробнее про нормальные значения можно почитать тут: какой пинг считается хорошим.

Windows

В «окнах» данную функцию выполняет системный модуль или утилита «Tracert». Как вы понимаете, она расположена в папке «System32», как и другие подобные микропрограммы. Для запуска обычно нужно использовать командную строку, PowerShell или Windows Terminal. Утилита спокойно работает как с доменными именами, так и с IP адресами, в том числе IPv4 и IPv6. Также плюс в том, что ее не нужно устанавливать и она идет в стандартном пакете Windows на всех популярных версиях: XP, 7, 8, 8.1, 10 и 11.

Для обычной трассировки права администратора чаще всего не нужны. То есть команду можно запускать и из обычной командной строки. Но если вы параллельно хотите менять сетевые настройки, сбрасывать DNS, перезапускать службы или выполнять команды вроде netsh, тогда уже лучше открыть консоль от имени администратора. Если не знаете, как ее открыть, можете посмотреть отдельную инструкцию – как открыть командную строку в Windows.

А теперь давайте попробуем ее использовать. Для этого вам нужно запустить командную строку. В Windows 7 переходим в «Пуск» – «Все программы» – открываем папку «Стандартные», а после этого нажимаем правой кнопкой по командной строке и открываем с правами администратора.

ПРИМЕЧАНИЕ! Также можно открыть через + R и команду cmd.

В Windows 10 и Windows 11 можно нажать правой кнопкой мыши по «Пуску» и выбрать «Терминал», «PowerShell» или «Командная строка», если такой пункт есть. В новых сборках Windows чаще открывается именно «Терминал», но команды внутри работают точно так же.

Далее все делается достаточно просто – сначала прописываем команду «tracert», а потом через пробел выписываем IP адрес сервера. Я в качестве примера использовал один известный DNS серверов:

tracert 8.8.8.8

Плюс еще в том, что можно использовать не только IP, но также и доменное имя, которое состоит из букв. Давайте для примера проведем тест с Яндексом:

tracert yandex.ru

Тут мы видим несколько шагов. Каждый шаг – это прохождение пакета от одного маршрутизатора к другому. Также вы видите время прохождения, которое пишется в миллисекундах. Далее вы видите название узла и IP адрес, который указан в скобках. Если же узел не сможет ответить или время ожидания будет превышено, то в столбце времени вы увидите звездочку (*).

Три столбца времени – это три отдельных запроса к одному и тому же шагу. Например, если вы видите значения 5 ms, 6 ms и 5 ms, то все нормально. Если первый запрос 5 ms, второй 200 ms, а третий снова 6 ms, это может быть единичный скачок или приоритизация трафика на маршрутизаторе. Если же задержка резко выросла на одном шаге и дальше остается высокой на всех следующих, это уже больше похоже на реальную проблему на этом участке маршрута.

СОВЕТ! Если трассировка по доменному имени не запускается, попробуйте трассировку по IP. Например, сначала выполните ping yandex.ru, посмотрите IP-адрес, а потом запустите tracert уже до этого IP. Если по IP работает, а по имени нет, проблема может быть в DNS. По похожим DNS-ошибкам можно посмотреть инструкцию – как исправить ERR_NAME_NOT_RESOLVED.

А теперь давайте я расскажу про проблему данного тестирования. Проблема состоит в том, что команда не показывает некоторые узлы, а именно коммутаторы, которые работают со вторым уровнем модели OSI. А все из-за того, что у них нет интерфейсного представления подключенных устройств в IP виде. То есть коммутация происходит на втором уровне, где нет IP адресов, а связь идет с помощью таблицы MAC-адресов. И понятно дело, что в таблице такие узлы не отображаются.

Более подробно советую также почитать про модель OSI и про коммутаторы.

В итоге для данной команды все коммутаторы, работающие со вторым уровнем модели OSI – просто невидимы. «Tracert» использует ICMP (Internet Control Message Protocol) протокол, который передает данные в IP пакете, со значением TTL. TTL – это время жизни пакета.

Изначально при отправке пакета на первый узел значение TTL равно единице. И при трассировке отправляется сразу три пакета – именно поэтому мы видим три столбца времени. Если все пакеты приходят обратно, то мы видим время по всем трем столбцам. Далее TTL увеличивается на единицу, и отправляется еще три пакета на следующий узел. И так до победного конца, пока последний запрос не достигнет конечного узла.

Если говорить совсем просто, TTL – это счетчик «сколько маршрутизаторов можно пройти». Первый пакет живет только один переход и умирает на первом маршрутизаторе. Второй живет два перехода и умирает на втором. Каждый маршрутизатор, где пакет «умирает», отправляет ответ назад, и благодаря этому мы видим маршрут. Поэтому трассировка не «заглядывает» в сеть магическим способом, а просто специально отправляет пакеты с разным TTL.

ПРИМЕЧАНИЕ! Если вы видите звездочку, но пакет все равно идет через данный узел дальше, то скорее всего на данном маршрутизаторе или сервере есть настройка, которая не обрабатывает диагностические ICMP-ответы или отвечает на них с низким приоритетом. Очень часто такие ответы ограничивают из-за нагрузки и защиты от атак. Одна звездочка в середине маршрута еще не означает, что интернет сломан.

Как у любой утилиты тут есть список дополнительных параметров, которые могут немного изменить тестирование. Для вызова нужно ввести:

tracert /?

Самые полезные параметры:

• tracert -d 8.8.8.8 – не пытаться определять имена узлов. Трассировка часто проходит быстрее, потому что Windows не тратит время на обратный DNS.
• tracert -h 15 yandex.ru – ограничить максимальное число переходов. Полезно, если нужно быстро проверить только первые узлы.
• tracert -w 1000 yandex.ru – задать время ожидания ответа в миллисекундах. Например, 1000 – это 1 секунда.
• tracert -4 yandex.ru – принудительно использовать IPv4.
• tracert -6 yandex.ru – принудительно использовать IPv6.

IPv6 сейчас встречается все чаще, поэтому иногда трассировка до одного и того же сайта по IPv4 и IPv6 показывает разные маршруты. Это нормально. У провайдера могут быть разные магистральные каналы для IPv4 и IPv6. Если у вас сайты открываются странно, а в трассировке по IPv6 видны обрывы, проверьте работу IPv6 отдельно – что делать, если IPv6 без доступа к сети.

Команда очень полезная не только для работы и тестирования рабочих сетей, но даже для выявления проблем с интернетом. Помню у моего друга постоянно был высокий отклик в «Counter-Strike», но он все никак не мог понять почему – ведь у меня в соседнем доме был пинг на порядок меньше. При трассировке он увидел, что на первом провайдерском узле есть сильный скачок задержки. В итоге он обратился к оператору, и им поменяли старый коммутатор, который стоял там, наверное, еще с эпохи Российской Империи.

ПРИМЕР! Если уже первый шаг после вашего роутера показывает огромную задержку или потери, проблема может быть у провайдера, в линии до дома или в оборудовании на подъезде. Если задержка нормальная до нескольких первых узлов, а потом резко растет ближе к другой стране, скорее всего проблема уже не у вас дома. В таком случае оператору полезно отправить скриншот или текст результата трассировки.

Pathping и PowerShell в Windows

В Windows есть еще одна полезная утилита – pathping. Она похожа на смесь ping и tracert. Сначала она строит маршрут, а потом некоторое время проверяет узлы и показывает статистику потерь. Команда работает дольше, зато дает больше информации, если проблема связана не только с задержкой, но и с потерей пакетов.

Пример:

pathping yandex.ru

Не закрывайте окно сразу. Утилита может работать несколько минут. В конце вы увидите статистику по промежуточным узлам. Но тут есть тот же нюанс: если маршрутизатор не отвечает на ICMP или режет диагностические запросы, это может выглядеть как потери на конкретном узле. Поэтому смотреть нужно не только на один подозрительный шаг, а на всю картину. Если потери начались на одном узле и продолжаются дальше до конечного сервера – это более показательно. Если потери только на промежуточном узле, а дальше все нормально – возможно, этот узел просто не любит отвечать на диагностику.

В PowerShell есть команда для проверки конкретного TCP-порта:

Test-NetConnection yandex.ru -Port 443

Она не заменяет трассировку маршрута, но помогает понять, доступен ли конкретный порт. Например, сайт работает через 443 порт, почтовый сервер может использовать 587 или 993, а игровой сервер – свой порт. Если ping проходит, а порт не открывается, проблема может быть в фаерволе, маршрутизации, блокировке порта или самом сервисе.

Для проверки домашней локальной сети иногда полезнее начинать не с трассировки, а с обычного IP и ping. Если два компьютера в одной сети не видят друг друга, сначала проверьте их адреса и одну подсеть. По этой теме есть отдельный материал – как проверить подключение по локальной сети.

Linux

Итак, в Windows мы уже разобрались, что трассировку выполняет утилита «tracert.exe». В Linux утилита имеет другое название: «traceroute», – и также выполняет данную функцию, но немного по-другому.

В некоторых дистрибутивах Linux traceroute может быть не установлен по умолчанию. Если команда не найдена, ее можно поставить через пакетный менеджер. Например, в Ubuntu, Debian и Linux Mint:

sudo apt update
sudo apt install traceroute

В Fedora можно использовать:

sudo dnf install traceroute

В Arch Linux:

sudo pacman -S traceroute

Вспомним немного как работает tracert на примере нижней картинки:

1. Host отправляет узлу «Router1» запрос с TTL = 1.
2. Запрос приходит на «Router1», и он, видя, что TTL равен всего одному, его уменьшает и отправляет ответ.
3. Ответ приходит от первого узла и Host записывает его в таблицу трассировки.
4. Далее идет запрос на второй узел уже с TTL увеличенным на один.
5. Так продолжается до тех пор, пока запрос не дойдет до конечного сервера.

Проблема в том, что у «tracert» в Windows нет возможности сделать запрос с нужным пользователю портом. Из-за этого он немного узконаправленный. Классический «traceroute» в Linux по умолчанию часто использует UDP-запросы к высоким портам. Обычно это порты, на которых конечный сервер ничего не слушает. Когда пакет доходит до конечного узла, сервер отвечает сообщением о недоступности порта, и traceroute понимает, что маршрут завершен.

Запускаем программу аналогично через консоль. Также у нее есть свои параметры.

Обычный пример:

traceroute yandex.ru

Если нужно не ждать обратного определения имен, можно добавить параметр:

traceroute -n yandex.ru

Так вывод часто становится быстрее и чище, потому что вы видите только IP-адреса.

Кстати, есть возможность при трассировке использовать не UDP, а ICMP протокол, для этого нужно дописать параметр «-I».

Пример:

traceroute -I yandex.ru

Еще один полезный вариант – TCP-трассировка. Она может быть полезна, если обычная UDP или ICMP трассировка режется фаерволом, а вам нужно проверить путь именно до веб-сервера на 443 порту:

traceroute -T -p 443 yandex.ru

Этот вариант не гарантирует, что вы увидите абсолютно все узлы, но иногда он лучше показывает реальный путь до сервиса, который работает через TCP. Например, если сайт открывается по HTTPS, проверка через TCP 443 ближе к реальному трафику браузера, чем обычная ICMP-трассировка.

ПРИМЕЧАНИЕ! Разные протоколы трассировки могут показывать разные результаты до одного и того же сайта. Это не обязательно ошибка. Маршрутизаторы, фаерволы и балансировщики могут по-разному обрабатывать ICMP, UDP и TCP. Поэтому для диагностики сайта иногда полезно сравнить обычный traceroute, ICMP-вариант и TCP-вариант до 443 порта.

macOS

На macOS тоже есть трассировка, и работает она через терминал. Откройте «Terminal» и выполните:

traceroute yandex.ru

Для ICMP-варианта в macOS часто используют отдельную команду:

traceroute -I yandex.ru

Также можно использовать встроенные сетевые утилиты и сторонние программы, но терминала достаточно почти всегда. Если вы привыкли к Windows, главное отличие простое: в Windows команда называется tracert, а в macOS и Linux – traceroute. Логика похожая, но параметры отличаются.

Если вы отправляете результат трассировки провайдеру или администратору, лучше приложить еще информацию о времени проверки, своем городе, типе подключения и целевом сайте или сервере. Например: «Проверка по Wi-Fi вечером, сайт такой-то, проблема только с этим ресурсом». Без контекста даже правильный вывод трассировки может быть сложно трактовать.

Как правильно читать результат

Многие пользователи видят звездочки и сразу думают: «Все, тут проблема». На самом деле все чуть сложнее. Промежуточный маршрутизатор может не отвечать на traceroute, но спокойно пропускать обычный трафик дальше. Поэтому важнее смотреть не на одну строчку, а на поведение всего маршрута.

Ориентируйтесь на такие признаки:

• Проблема на первом шаге. Часто это ваш роутер или локальная сеть. Проверьте Wi-Fi, кабель, нагрузку на роутер и подключение по LAN.
• Проблема на втором-третьем шаге. Часто это сеть провайдера или узел сразу после вашего дома. Тут уже есть смысл обращаться к оператору.
• Задержка выросла далеко в маршруте. Возможно, проблема на магистрали, в другой стране, у хостинга или у самого сервера.
• Звездочки только на одном промежуточном узле, а дальше все нормально. Скорее всего, узел просто не отвечает на диагностику, но трафик пропускает.
• Звездочки начинаются с какого-то шага и дальше до конца ничего нет. Возможна блокировка, недоступность сервера, фильтрация или обрыв маршрута.

СОВЕТ! Если вы хотите отправить результат в поддержку, не делайте скриншот маленького окна, где половина строк не видна. В Windows можно выделить текст в консоли мышкой, нажать Enter и вставить его в письмо или чат. Еще удобнее сохранить результат в файл командой tracert yandex.ru > trace.txt. Файл появится в текущей папке, и его можно отправить специалисту.

Также помните про Wi-Fi. Если у вас по трассировке уже первый узел отвечает нестабильно, проверьте подключение кабелем. Очень часто проблема не у провайдера и не у сервера, а в домашнем Wi-Fi: слабый сигнал, перегруженный канал, старый роутер, дальняя комната, репитер или соседские сети. Если интернет в целом работает медленно, можно дополнительно посмотреть рекомендации – как увеличить скорость интернета.

Частые вопросы

Трассировка показывает звездочки – это точно поломка?

Нет, не всегда. Звездочка означает, что на конкретный диагностический запрос не пришел ответ за отведенное время. Узел может быть настроен так, что не отвечает на ICMP или UDP, но обычный трафик пропускает. Если после звездочек маршрут продолжается и конечный сервер отвечает, это не обязательно проблема.

 

Почему ping до сайта есть, а трассировка обрывается?

Потому что ping и traceroute могут использовать разные типы запросов, а промежуточные узлы могут отвечать на них по-разному. Также сервер может отвечать на обычный ping, но не показывать весь маршрут. Для проверки попробуйте tracert -d, трассировку по IP, а в Linux – ICMP или TCP-вариант.

 

Можно ли в Windows сделать трассировку до конкретного порта?

Стандартная команда tracert не умеет указывать порт. Для проверки доступности TCP-порта можно использовать PowerShell: Test-NetConnection site.ru -Port 443. Для полноценной TCP-трассировки в Windows нужны сторонние инструменты, например tracetcp, WinMTR, PingPlotter или аналоги.

 

Чем tracert отличается от pathping?

tracert быстро показывает маршрут до узла. pathping сначала строит маршрут, а потом дольше собирает статистику по потерям. Если нужно быстро посмотреть путь – используйте tracert. Если нужно понять, где могут теряться пакеты – попробуйте pathping.

 

Почему трассировка в Windows и Linux отличается?

В Windows tracert обычно использует ICMP Echo Request. В Linux traceroute по умолчанию часто использует UDP-запросы к высоким портам, но может работать и через ICMP или TCP. Из-за этого фаерволы и маршрутизаторы могут отвечать по-разному, а вывод команд может отличаться.

 

Можно ли по трассировке узнать точный физический путь кабеля?

Нет. Трассировка показывает IP-узлы, которые ответили на диагностические запросы. Она не показывает все коммутаторы второго уровня, точные кабельные линии, стойки, кроссы и внутреннюю схему провайдера. География по IP тоже может ошибаться, поэтому не стоит считать ее абсолютной истиной.

 

Что лучше отправить провайдеру при проблемах?

Отправьте результат ping, tracert или pathping до проблемного сайта или сервера. Укажите время проверки, тип подключения, город, провайдера, работает ли проблема по кабелю и по Wi-Fi. Если проблема только в игре, укажите адрес игрового сервера, если он известен.

 

Почему первый узел в трассировке – это мой роутер?

Потому что пакет сначала выходит из вашего компьютера на домашний маршрутизатор, а уже потом идет к провайдеру. Обычно это адрес вроде 192.168.0.1 или 192.168.1.1. Если уже до первого узла большая задержка или потери, сначала проверяйте домашнюю сеть, Wi-Fi, кабель и сам роутер.

Видео

YouTube