Traceroute и Tracert: для чего предназначены утилиты и как ими правильно пользоваться?

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

Сразу внесу важное уточнение, чтобы не было лишних ожиданий. Команда tracert не всегда показывает «виновника» на 100% и не является волшебной кнопкой для доказательства проблемы. Но она очень полезна как первый шаг диагностики. С ее помощью можно понять, доходит ли трафик хотя бы до вашего роутера, уходит ли дальше в сеть провайдера, не замирает ли маршрут на промежуточном узле и есть ли смысл копать в сторону DNS, потери пакетов или перегруженного канала. Поэтому в связке с ping и проверкой потери пакетов эта команда реально полезна.

Назначение команды

«Tracert» – это встроенная командная утилита Windows, которая выполняет трассировку маршрута до указанного узла сети – локальной или глобальной. Утилита интегрирована в ОС и ее можно запускать через «Командную строку», PowerShell или Windows Terminal. Исполняемый файл называется «tracert.exe» и находится в системной папке System32.

Команда «tracert» – частый гость во время сетевой диагностики и troubleshooting. С ее помощью определяется маршрут, по которому следует пакет до указанного узла. Преимущество программы в том, что она работает с доменными именами, IPv4 и IPv6. Кроме определения маршрута программа показывает время прохождения запросов до промежуточных и конечного узлов.

С помощью команды можно узнать:

1. На каком участке маршрута перестают приходить ответы – в локальной сети, на стороне провайдера, на промежуточных узлах или ближе к конечному серверу.
2. Где примерно начинаются скачки задержки, если связь формально есть, но работает нестабильно.
3. Какой путь в данный момент проходит трафик до нужного ресурса.

А вот чего tracert не умеет делать надежно, так это «доказывать подмену сайта» или подтверждать, что конечный ресурс «точно тот самый». По одному только маршруту нельзя уверенно делать вывод о подмене веб-страницы, безопасности соединения или содержимом трафика. Для таких задач нужны уже другие инструменты и другой уровень проверки. Поэтому tracert – это именно утилита маршрутизации и диагностики пути, а не универсальный детектор взлома или подмены.

Основные моменты работы и анализ

Чтобы провести трассировку пакетов данных от собственного ПК до сервера, введите его IP-адрес или доменное имя после основной команды.

Как видно на примере, после ввода команды и IP-адреса или домена утилита определяет маршрут до целевого ресурса. Если указан домен, Windows сначала сама попытается определить его IP-адрес. Дальше в результатах будут показаны промежуточные узлы, через которые приходится проходить пакетам, чтобы добраться до конечного сервера. Это полезно уже хотя бы потому, что по трассировке можно отличить локальную проблему от удаленной. Например, если ответ обрывается уже на первом шаге, стоит проверять свой роутер, сетевой адаптер или основной шлюз. Если первые 2-3 хопа проходят нормально, а дальше начинаются таймауты – проблема может быть уже не у вас дома.

Примечательно, что команда понимает и доменные имена, выявляя их IP-адреса автоматически.

Когда вводится команда для трассировки маршрута, каждая пронумерованная строка называется шагом, прыжком или хопом. В рамках вывода это один промежуточный узел на пути до конечного адресата. Обычно на каждой строке вы видите три замера времени – это не три разных маршрута, а три последовательных запроса к одному и тому же хопу. Благодаря этому можно быстро понять, насколько стабильно отвечает узел. Если один столбец показывает 5 мс, второй 7 мс, а третий уже 90 мс – это повод присмотреться к маршруту внимательнее.

Хопы, которые наблюдаются при работе утилиты, – это маршрутизаторы, L3-коммутаторы или другие сетевые устройства, работающие на сетевом уровне и умеющие уменьшать TTL. Важно отметить, что провайдеры действительно используют и обычные L2-коммутаторы, которые не участвуют в ответах tracert напрямую. Поэтому таких устройств в трассировке вы обычно не увидите. Для пользователя это выглядит так: трафик вроде проходит через массу оборудования, а на экране видны только отдельные точки. И это нормально. Tracert не рисует вам всю физическую схему провайдера, а показывает только те узлы, которые реально участвуют в маршрутизации на IP-уровне.

СОВЕТ! Буква L обозначает уровень, на котором работает коммутирующее устройство – советую почитать про уровни модели OSI. Это полезно, чтобы понимать, почему часть оборудования в трассировке видна, а часть – нет.

Делая запрос, утилита отправляет по три запроса на каждый хоп, постепенно увеличивая TTL. Сначала пакет уходит с TTL = 1, затем с TTL = 2 и так далее, пока не будет достигнут конечный узел или лимит по количеству шагов. Каждый маршрутизатор на пути уменьшает TTL минимум на единицу. Когда TTL падает до нуля, промежуточное устройство обычно отвечает служебным сообщением, и на основании этого ответа tracert понимает, какой именно узел оказался следующим на маршруте.

При отсутствии ответа в таблице могут появляться «*» в одном, двух или всех трех столбцах. Это не всегда означает, что узел сломан, недоступен или что именно он вызывает проблему. Очень часто промежуточные маршрутизаторы просто не отвечают на ICMP-запросы, ограничивают такие ответы или обрабатывают их с низким приоритетом. Из-за этого хоп может выглядеть «подозрительно», но следующий узел при этом отвечает нормально. И вот это как раз ключевой момент анализа: если на одном хопе идут звездочки, а дальше маршрут продолжается, то проблема может быть именно в политике ответа конкретного устройства, а не в реальном обрыве канала.

Первые три столбца содержат RTT – время отклика в миллисекундах для каждого из трех запросов. Четвертый столбец обычно показывает IP-адрес или имя узла, если Windows смогла выполнить обратное DNS-разрешение. Если хотите ускорить вывод и убрать лишние DNS-задержки, используйте ключ «/d» – тогда будут выводиться только IP-адреса без попыток преобразовать их в имена.

Здесь полезно запомнить простое правило анализа. Если высокий пинг или звездочки появились на одном промежуточном узле, но на всех следующих узлах задержка снова нормальная, то паниковать рано. Часто такой узел просто медленно отвечает именно на диагностические запросы. А вот если скачок задержки начался на каком-то хопе и тянется до самого конца маршрута, тогда это уже больше похоже на реальную проблему в этом сегменте сети.

Более подробно про механизм трассировки читаем тут. А если хотите понять, как быстро узнать адрес домашнего маршрутизатора перед диагностикой, вот полезный материал – как узнать основной шлюз.

Отправляемые пакеты

Диагностика сети происходит благодаря посылаемым пакетам. Утилита «tracert» в Windows использует ICMP Echo Request или ICMPv6-сообщения. Это важно, потому что многие путают Windows-утилиту с Linux-командой traceroute и думают, что они работают абсолютно одинаково. На самом деле логика у них похожая, но реализация по умолчанию отличается.

Классическая команда traceroute в Linux и многих Unix-подобных системах традиционно использует UDP-запросы по умолчанию, хотя в ряде реализаций может работать и через ICMP, и через TCP. Поэтому результаты трассировки между Windows и Linux иногда отличаются не потому, что одна из систем «врет», а потому что запросы проходят немного по-разному и сетевые устройства реагируют на них не одинаково. Для обычного пользователя главный вывод простой: если вы проверяете один и тот же ресурс с Windows и Linux и получаете разную картину, это не всегда ошибка. Это может быть нормальная особенность самой методики диагностики.

Также в интернете можно встретить советы про построение графической карты маршрута через сторонние инструменты, Perl-библиотеки, graphviz и разные скрипты. Такое действительно существует, но это уже не встроенная возможность tracert, а отдельные надстройки. Для базовой домашней диагностики они почти никогда не нужны. Намного полезнее сначала научиться читать обычный текстовый вывод и понимать, где локальная проблема, а где уже история уровня провайдера или удаленного сервера.

ICMP-сообщение отправляется в составе IP-пакета. У такого пакета есть собственное время жизни – TTL, то есть Time To Live. Но здесь я бы сразу убрал частую путаницу. TTL не «увеличивается внутри одного уже отправленного пакета». Для каждого нового этапа tracert отправляет новые пакеты с новым значением TTL: сначала 1, потом 2, потом 3 и так далее. Поэтому если совсем упростить, tracert как будто специально отправляет пакеты, которым «разрешено прожить» только один шаг, потом два шага, потом три. Именно так и получается карта маршрута.

По умолчанию tracert ограничивает поиск 30 хопами. Для большинства бытовых сценариев этого более чем достаточно. Если путь до ресурса почему-то длиннее или вам нужно проверить более редкий случай, можно увеличить лимит ключом «/h». Но на практике в обычной диагностике чаще полезны не огромные TTL, а повторные проверки в разное время суток. Потому что один и тот же маршрут утром, вечером и ночью может вести себя по-разному из-за нагрузки.

Не путайте TTL в контексте трассировки и «скорость интернета». TTL не ускоряет и не замедляет соединение сам по себе. Это служебный параметр IP-пакета, который помогает ограничить жизнь пакета в сети и одновременно позволяет tracert поэтапно находить промежуточные узлы. Поэтому советы уровня «поднимите TTL и интернет станет лучше» к tracert не относятся.

Ключи для команды

Чтобы полноценно закрепить материал и понять, как работает tracert и какими значениями можно оперировать, воспользуйтесь встроенной справкой. Откройте «Командную строку», PowerShell или Windows Terminal и введите команду:

“tracert /?”

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

Вот основные ключи:

Из этого списка обычному пользователю реально чаще всего нужны всего три ключа: «/d», «/h» и «/w». Например, если сайт отвечает медленно и вы хотите быстро получить сухую картину без DNS-задержек, удобно использовать команду “tracert /d ya.ru”. Если удаленный узел находится далеко и вы подозреваете, что 30 хопов не хватает, можно попробовать “tracert /h 40 example.com”. А если ответы идут слишком медленно и вы хотите дать узлам больше времени, пригодится что-то вроде “tracert /w 7000 example.com”.

Для более глубокой диагностики стоит помнить еще про команду pathping. Она работает медленнее, но дает дополнительную информацию по задержкам и потерям на каждом участке маршрута. То есть tracert хорош для быстрого снимка пути, а pathping – когда нужно чуть подробнее разбираться с нестабильной связью. В связке с трассировкой также полезно проверять DNS, особенно если сайт открывается странно или по имени не резолвится вообще. На этот случай у нас есть и отдельная статья про DNS-серверы и их настройку.

Короткий FAQ

Почему на одном из хопов только звездочки, а дальше маршрут продолжается?

Потому что промежуточное устройство может не отвечать на ICMP-запросы или отвечать на них с низким приоритетом. Если следующие узлы и конечный сервер отвечают, это еще не признак реального обрыва. Смотреть нужно не на одну строку в отрыве от остального вывода, а на всю цепочку целиком.

 

Почему tracert показывает высокий пинг на одном узле, а дальше все нормально?

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

 

Можно ли запускать tracert из PowerShell и Windows Terminal?

Да, можно. Это все та же встроенная Windows-утилита. То есть не обязательно запускать именно классическую «Командную строку». Команды работают и в PowerShell, и в Windows Terminal.

 

Что лучше использовать первым – ping или tracert?

Обычно я советую начать с ping. Он быстрее показывает, есть ли вообще ответ и какая базовая задержка. А если уже видно, что связь нестабильна, есть таймауты или ресурс не открывается, тогда подключаем tracert и смотрим маршрут. В паре эти две команды дают гораздо больше пользы, чем по отдельности.