Traceroute показывает путь к цели с помощью пакетов с растущим TTL. Он не измеряет пропускную способность и не гарантирует отображение каждого маршрутизатора. Звёздочка означает отсутствие диагностического ответа, а не автоматическую потерю пользовательского трафика.
1. Откуда взялась трассировка и что она измеряет
Что измеряет трассировка и чего она не наблюдает
Представьте три разных вопроса: «куда направляет пакет моя таблица маршрутизации», «какие узлы ответили на диагностические пробы» и «почему приложение тормозит». ip route, traceroute и измерение работы приложения отвечают на разные вопросы. Трассировка не читает таблицы всех провайдерских маршрутизаторов и не видит каждый физический кабель. Она создаёт контролируемые IP-пакеты и по ответам восстанавливает часть наблюдаемого пути.
Исторически такой механизм дал возможность исследовать сеть без административного доступа к каждому промежуточному устройству. Ключевой приём — намеренно ограничивать число маршрутизируемых переходов. Реализации утилиты затем разошлись: Unix-варианты использовали UDP-пробы, Windows — ICMP Echo, появились TCP-пробы и методы, учитывающие балансировку. Поэтому одинаковое имя назначения ещё не делает два запуска одинаковым экспериментом.
Для честного сравнения фиксируйте адрес назначения, семейство IPv4/IPv6, тип пробы, порт, исходный адрес, сеть доступа, время и параметры ожидания. Запуск с домашнего Wi-Fi и запуск с сервера в ЦОД могут одновременно быть правильными, но проверяют разные маршруты. Даже два имени одного сайта могут вести к разным узлам CDN.
Определите, что нужно проверить: недоступность, задержку, потери или смену маршрута. Запишите hostname, время, сеть и приложение. Маршрут до другого домена не объясняет проблему нужного сервиса.
Цель диагностики и исходные условия
Допустим, запрос к portal.example.com перестаёт отвечать после подключения VPN. Нужно понять, какой интерфейс выбран и достигается ли конечный адрес. Запишите время, сеть, DNS-резолвер, A/AAAA и наличие прокси. Трассировка до доменного имени может сегодня попасть в другой адрес CDN; для сравнения фиксируйте семейство IP и конкретный IP.
Проверьте обычный запрос приложения до и после. Если браузер получает HTTP500, это уже ответ сервера; изменение маршрута не является автоматическим объяснением внутренней ошибки. Если DNS не разрешает имя, начните с DNS — трассировка по имени не отделит этот отказ без дополнительного теста по IP.
2. Windows, Linux, macOS и разные типы проб
Сопоставляем команды, а не только их названия
| Система и реализация | Обычная проба IPv4 | Когда трассировка понимает, что дошла | Как отключить вывод имён | Важное отличие |
|---|---|---|---|---|
| Windows tracert | ICMP Echo Request | Ответ Echo Reply от цели | -d | -w задаёт ожидание в миллисекундах |
| Debian/Ubuntu, пакет traceroute | UDP на высокие порты | Обычно ICMP Port Unreachable от цели | -n | -I выбирает ICMP, -T — TCP; ожидание в секундах |
| Linux traceroute с TCP | TCP SYN на заданный порт | Ответ конечного TCP endpoint, например SYN/ACK или RST | -n | Ответ не означает полноценную HTTP-сессию |
| macOS, системный BSD-подобный traceroute | Обычно UDP | Обычно ICMP Port Unreachable | -n | Набор ключей смотрят в локальном man traceroute; Linux -T не переносится автоматически |
| BusyBox traceroute | Зависит от сборки и доступных возможностей | По реализации и выбранному протоколу | Обычно -n | Не все ключи полноценного пакета присутствуют |
TCP/443 нужен для сравнения с направлением HTTPS, но он не полностью повторяет браузер: размеры пакетов, продолжительность соединения, SNI, TLS и HTTP отсутствуют или отличаются. Firewall может разрешить SYN и позже запретить приложение. И наоборот, HTTPS через корпоративный прокси может работать, хотя прямая трассировка с рабочего ПК не доходит.
Перед запуском на необычной системе проверьте реализацию:
command -v traceroute
traceroute --version 2>/dev/null
man traceroute--version не универсален: ошибка на BSD или урезанной системе сама по себе не говорит о поломке. Для macOS первичная база реализации публикуется в Apple network_cmds.
В Windows используется tracert, в Linux/macOS — traceroute или tracepath. Выполните DNS- и IP-вариант, чтобы отделить разрешение имени.
Resolve-DnsName example.com
tracert -d example.com
tracert example.comКлюч -d ускоряет вывод, отключая обратные DNS-запросы.
Полные команды для Windows, Debian и macOS
В Windows откройте обычную CMD и ограничьте максимальную длину и ожидание:
tracert -4 -d -h 20 -w 1000 portal.example.com
tracert -6 -d -h 20 -w 1000 portal.example.com-4/-6 выбирают семейство, -d отключает PTR, -h ограничивает хопы, -w задаёт миллисекунды ожидания ответа. Для IPv6 цель должна иметь AAAA и рабочий IPv6-путь; ошибка его отсутствия не доказывает дефект IPv4.
На Debian/Ubuntu установите пакет из штатного репозитория, а затем используйте Linux-реализацию:
sudo apt update
sudo apt install traceroute
traceroute -4 -n -m 20 -w 1 -q 3 portal.example.comВ macOS встроенный traceroute имеет BSD-параметры: сверяйте man traceroute. Linux TCP-ключ -T нельзя автоматически переносить на Mac. -n в Unix соответствует отключению DNS-имён в выводе, а -w 1 означает секунды. Ошибка единиц делает «одинаковые» тесты несопоставимыми.
3. Механика TTL, Hop Limit и обратного ответа
Один пакет не проходит все строки вывода
Для первой строки отправляется проба с TTL=1. Первый маршрутизатор уменьшает TTL и, когда дальнейшая пересылка невозможна, может вернуть ICMP Time Exceeded. Для второй строки отправляется новая проба с TTL=2. Она переживает первый переход и истекает на следующем. Продолжая увеличивать TTL, утилита получает ответы от более далёких устройств. При трёх пробах на строку это три отдельных измерения, а не один пакет с тремя отметками времени.
Условный путь клиент → R1 → R2 → сервер:
Проба A: TTL=1 → R1; обратно приходит Time Exceeded от R1.
Проба B: TTL=2 → R1 → R2; обратно приходит Time Exceeded от R2.
Проба C: TTL=3 → R1 → R2 → сервер; приходит конечный ответ.TTL первоначально описывался как ограничение времени жизни, но для трассировки важен практически наблюдаемый счётчик маршрутизируемых переходов. В IPv6 аналог называется Hop Limit. Обычный L2-коммутатор не становится отдельной строкой только потому, что физически стоит на пути. Туннель, MPLS и обработка TTL могут скрывать часть внутренней топологии. Основные правила заданы в RFC 791 и RFC 1812.
У промежуточного ответа есть второй маршрут — обратно к клиенту. Он может идти через другие устройства и другого провайдера. Трассировка показывает источник полученного ответа, но не раскрывает полностью обратный путь. Следовательно, задержка ответа на строке включает прямой путь до ответившего узла, обработку и обратную доставку.
Каждый маршрутизатор уменьшает TTL. При нуле он обычно возвращает ICMP Time Exceeded, и инструмент записывает адрес и round-trip time. Некоторые устройства не отвечают, но продолжают пересылать трафик.
Что именно измеряет TTL
Начальная проба имеет TTL=1. Первый маршрутизатор уменьшает его до нуля, отбрасывает эту диагностическую пробу и обычно возвращает ICMP Time Exceeded. Проба с TTL=2 достигает второго маршрутизатора. Так строится последовательность. В IPv6 аналогичный смысл имеет Hop Limit.
RTT — время туда и обратно до источника ответа, включая обработку и обратный путь. Это не задержка отдельного физического кабеля между строками. Коммутаторы второго уровня TTL обычно не уменьшают, поэтому их нет отдельными хопами. VPN, MPLS и политика propagation TTL могут скрывать часть внутреннего пути. Traceroute не является полной схемой оборудования и не измеряет полосу пропускания.
4. RTT и подробный разбор вывода
Разбираем учебный вывод по смыслу
1 1 ms 1 ms 2 ms 192.168.10.1
2 5 ms * 6 ms 198.51.100.1
3 85 ms 92 ms 88 ms 198.51.100.2
4 12 ms 13 ms 12 ms 203.0.113.10Адреса внешних узлов здесь из диапазонов для документации. Числа — отдельные RTT проб. У второго узла одна проба не дала ответа в отведённое время, остальные ответили. У третьего большие RTT, но четвёртый отвечает за 12–13 мс. Такое сочетание совместимо с задержкой создания диагностических ответов третьим узлом; утверждать, что «на третьем переходе канал тормозит на 80 мс», нельзя.
RTT не является задержкой физического линка между соседними строками. Вычитание RTT(4)-RTT(3) здесь даст отрицательное число, что не означает обратное течение времени: измерения относятся к разным пробам и разным обработчикам ответов. Даже положительная разница не даёт точную задержку линка без дополнительных условий.
Имя рядом с IP обычно получено обратным DNS-запросом. Оно может быть старым, маркетинговым или указывать интерфейс, а не географическое положение. Строка с msk в имени не доказывает прохождение через Москву. Для измерения без ожидания DNS используйте числовой вывод, а имена анализируйте отдельно.
Три числа на строке — отдельные пробы, а не минимум, среднее и максимум. Разброс может показать очередь, но одна высокая цифра не доказывает постоянную проблему. Повторите тест.
Разбор вывода по строкам
1 1 ms 1 ms 2 ms 192.168.10.1
2 12 ms 11 ms 14 ms 198.51.100.1
3 * * * Request timed out.
4 25 ms 24 ms 26 ms 203.0.113.10
5 29 ms 28 ms 31 ms 203.0.113.20Адреса внешних узлов здесь документационные. Три значения — три самостоятельные пробы, не Best/Avg/Worst. Узел №3 не ответил диагностике, но следующие ответы показывают продолжение маршрута. Разность 25−12=13 мс нельзя считать точным временем линии между №2 и №4: обратные пути и обработка ответов отличаются. Для вывода о деградации нужна серия и результат цели, а не одиночная высокая цифра.
5. Звёздочки, тайм-ауты и сообщения ICMP
Звёздочка — это отсутствие наблюдения, а не готовый диагноз
Утилита знает только, что не получила подходящий ответ до тайм-аута. Проба могла быть потеряна на прямом пути; маршрутизатор мог не создавать ответ; ответ мог потеряться на обратном пути; firewall мог его отфильтровать; ответ мог прийти поздно. По одной звёздочке эти варианты не различить.
Если после * * * появляются дальнейшие узлы и отвечает цель, какая-то часть проб проходит сквозь «молчаливый» участок. Это опровергает вывод «маршрут оборвался именно там» для всего трафика. Если строки заканчиваются звёздочками до лимита переходов, установлено отсутствие ответов, но не точное место отказа приложения.
Для IPv4 сообщения Time Exceeded и Destination Unreachable имеют разные типы и коды. ICMPv6 использует свою нумерацию. Не переносите номера кодов между семействами. Механика ответов описана в RFC 792 и RFC 4443. Обозначения !H, !N, !X в Unix-утилите — её текстовое представление конкретных ответов; строка Windows может сообщать проблему иначе.
Одна или три звёздочки означают тайм-аут диагностической пробы. Если следующие хопы и цель отвечают нормально, этот узел просто фильтрует или ограничивает ICMP. Проблема вероятнее, когда ухудшение продолжается до цели.
Когда звёздочки действительно требуют продолжения проверки
Если вся трасса после некоторого хопа содержит звёздочки, проверьте само приложение и другой тип проб. Это может быть обрыв, фильтрация ICMP, смена пути или достижение firewall, который продолжает пропускать TCP. Если HTTPS работает, заключение «интернет сломан на последнем видимом узле» ошибочно.
Linux traceroute может показать !H, !N, !X: недоступность хоста, сети или административный запрет. Сохраните код и адрес источника ответа. Он указывает, кто сообщил об отказе, но не всегда кто является первопричиной. Проверьте route/ACL на управляемой границе, прежде чем менять конфигурацию чужого узла.
6. ECMP, туннели, anycast и асимметрия
Почему один сайт даёт разные пути
Балансировка ECMP часто выбирает путь по набору полей потока: исходный и целевой IP, протокол и порты. Если традиционный UDP-traceroute меняет порт каждой пробы, он может отправить соседние пробы по разным веткам. В результате напечатанная последовательность адресов не всегда соответствует одному непрерывному пути реального TCP-соединения.
Добавляются изменения маршрутов во время измерения, anycast и CDN. DNS мог вернуть иной адрес; даже при одном IP anycast может привести к другому узлу из другой сети. VPN меняет исходную сеть, а proxy может перенести фактическое HTTPS-соединение на другую машину.
Для исследования балансировки существуют методы, сохраняющие идентификаторы потока, например Paris traceroute. Они уменьшают определённые артефакты, но не обещают увидеть все скрытые устройства или доказать физическую трассу кабеля. Для обычной заявки важнее не смешивать несопоставимые запуски и сохранить тип пробы вместе с выводом.
Разные пробы могут идти по ECMP-маршрутам, а обратный путь часто отличается. Поэтому смена адреса в одной строке допустима. Сравнивайте серию тестов и данные с другой стороны, если она доступна.
ECMP и обратный путь
Балансировщики могут хешировать адреса, порты и протокол. UDP traceroute традиционно меняет порт назначения, поэтому соседние пробы способны попасть на разные ECMP-ветки. Получится строка с разными отвечающими IP без реального «скачущего кабеля». Приложение с постоянным TCP flow может идти иначе.
Встречная трассировка от сервера к клиенту исследует отдельный обратный путь; она не получается простым чтением исходной таблицы снизу вверх. При NAT встречная цель может быть публичным шлюзом, а не самим ПК. Укажите это в отчёте. При необходимости исследуйте flow-стабильным инструментом и показателями сети, а не приписывайте все колебания конкретному провайдеру.
7. Переходим от трёх проб к статистике
Единичный RTT и статистика за минуту — разные измерения
Три ответа одной строки не дают процент потерь за рабочий час. Pathping и MTR повторяют измерения, чтобы накопить статистику. Но статистика по промежуточному узлу всё равно относится к его диагностическим ответам: она не автоматически становится статистикой потерь пересылаемых пакетов.
Сравнивайте повторяющиеся изменения конечного узла с симптомом приложения. Если промежуточный узел теряет 60% ответов, а цель даёт 0% потерь, это не 60% потерь пользовательского трафика на том линке. Если потери устойчиво видны на цели, есть основание продолжить исследование прямого и обратного направления. Более подробный разбор — в статье WinMTR.
В Windows pathping сначала строит маршрут, затем длительно опрашивает узлы. Его результат также требует правила «потери должны продолжаться ниже по пути».
pathping -n example.com
ping -n 100 example.comPathping и MTR: статистика с ограниченным объёмом
pathping -4 -n -h 20 -q 100 -p 250 portal.example.comPathping сначала получает маршрут, затем накапливает ответы; результат не появляется немедленно. Его счётчики характеризуют диагностические ответы выбранных узлов. Потери в строке link также требуют проверки конечной цели и особенностей ICMP.
На Linux, после установки mtr-tiny из репозитория:
mtr -4 -n -r -w -c 100 -i 1 portal.example.com-r создаёт итоговый отчёт, -c 100 ограничивает число циклов, -i 1 задаёт умеренный интервал. Не оставляйте неограниченную диагностику на загруженном production-узле без причины. Первичная документация MTR.
8. Сравниваем UDP, ICMP и TCP практически
Как поставить сравнительный опыт с ICMP, UDP и TCP
Используйте один разрешённый IP своего сервиса, одинаковое семейство и короткие ограниченные измерения. На Linux с полноценным пакетом traceroute можно сравнить три метода:
# Только свой согласованный адрес; учебный IP замените.
traceroute -4 -n -m 20 -w 2 -q 3 203.0.113.10
sudo traceroute -4 -I -n -m 20 -w 2 -q 3 203.0.113.10
sudo traceroute -4 -T -p 443 -n -m 20 -w 2 -q 3 203.0.113.10sudo требуется лишь если выбранная реализация и права не позволяют создать нужные пробы. Не назначайте утилите привилегии без политики компании. Если TCP доходит, а UDP прекращается, это совместимо с различной фильтрацией, но ещё не доказывает исправность HTTPS. Сравнение повторите несколько раз и дополните проверкой сервиса.
На Windows штатный tracert не превращается в TCP-traceroute добавлением номера порта. Test-NetConnection -Port 443 проверяет TCP-доступность; -TraceRoute выполняет отдельную трассировку. Это разные режимы, и они не складываются в одну команду с обеими возможностями.
Traceroute на разных ОС использует ICMP или UDP; приложение может работать по TCP/UDP на другом порту. Дополните тест Test-NetConnection, curl или специализированным мониторингом.
Test-NetConnection example.com -Port 443
curl.exe -o NUL -s -w "connect=%{time_connect} total=%{time_total}\n" https://example.com/ICMP, UDP и TCP — отдельные эксперименты
В Linux compare-тесты выполняют после проверки разрешённых целей и необходимости повышенных прав:
traceroute -4 -n -m 20 -w 1 -q 3 portal.example.com
sudo traceroute -4 -n -I -m 20 -w 1 portal.example.com
sudo traceroute -4 -n -T -p 443 -m 20 -w 1 portal.example.comПервая команда использует традиционные UDP-пробы, вторая ICMP, третья TCP SYN к 443. Различие показывает, что правила обработки протоколов отличаются; TCP traceroute не проверяет HTTP-авторизацию или передачу большого файла. Для Test-NetConnection параметры -Port и -TraceRoute принадлежат разным наборам: их нужно вызывать отдельно.
Test-NetConnection portal.example.com -TraceRoute -InformationLevel Detailed
Test-NetConnection portal.example.com -Port 443 -InformationLevel DetailedMicrosoft — наборы параметров Test-NetConnection, Linux traceroute — параметры и типы проб.
9. Связываем трассировку с отказом приложения
Когда трассировка успешна, а страница зависает
Маленькая проба может проходить, а большие пакеты — нет из-за MTU, туннеля или отсутствующих сообщений о необходимости уменьшить размер. Возможны и чисто прикладные причины: DNS не для того имени, TLS-проверка, proxy, backend и ожидание БД. Поэтому «дошла последняя строка» означает достижение цели данным методом, а не успешное открытие сайта.
Сопоставьте трассировку с временем TCP-соединения, TLS и ответа приложения. У TCP RST от цели есть диагностическая ценность: конечный TCP-узел ответил, хотя порт может быть закрыт. SYN/ACK показывает начало согласования TCP, но не право пользователя работать с сервисом. ICMP Echo Reply показывает ответ на Echo, но ничего не говорит о конкретном TCP-порту.
Сделайте второй опыт из другой согласованной сети. Если сервис доступен оттуда, выясняйте различия маршрута, DNS, исходного адреса и ACL. Не подменяйте этот вывод утверждением о виновности конкретного провайдера.
Первый хоп — ваш шлюз, затем обычно сеть провайдера, транзит и сеть назначения. WHOIS и reverse DNS дают подсказку, но не точное физическое место. Не публикуйте внутренние имена оборудования.
Проверка выбранного интерфейса и маршрута
В Linux сначала определите IP, затем подставьте его в ip route get. В Windows сравните InterfaceAlias и SourceAddress в Test-NetConnection с разрешённым VPN-интерфейсом.
getent ahostsv4 portal.example.com
ip route get 203.0.113.20203.0.113.20 — пример, не рабочий сервер. В результате via, dev и src показывают выбранный next hop, интерфейс и исходный адрес. Если используется policy routing, проверьте ip rule show и соответствующие таблицы, не удаляя их. Имя маршрутизатора из PTR и геолокация IP дают только подсказки; нельзя определить физическое место неисправности по названию вроде msk-core без данных оператора.
10. Доказываем вывод и выбираем следующий тест
Как сформулировать технический вывод без гадания
Полезный вывод: «На одном IPv4-адресе ICMP-tracert прекращает получать ответы после третьего узла, TCP/443 устанавливается, HTTPS отвечает; отказ ICMP не воспроизводит жалобу на приложение». Бесполезный: «Третий роутер плохой, на нём звёзды». Ещё один корректный вывод: «Потери конечных ICMP-проб повторяются на кабеле в три интервала, но обратный путь и TCP не проверены».
Передайте исходный вывод, инструмент и его реализацию, параметры, временной интервал, целевой IP и результат прикладного теста. Не ограничивайтесь картинкой без последней строки. Самая ценная часть диагностики — отделить наблюдаемое от предположения и выбрать следующий опыт, который различит оставшиеся причины.
Для эскалации приложите два-три теста в момент сбоя и baseline, целевой адрес, время и прикладной симптом. После изменения повторите тот же маршрут. Решение оценивают по работе приложения и достижению цели.
Отчёт и критерии завершения
Запишите полный командный вызов, версию инструмента, время, исходный/целевой адрес, протокол, семейство IP и симптом приложения. Приложите baseline и тест в сбой, сохранив конечную строку. Разделите наблюдение «нет ответов с TTL4» и гипотезу «возможно, фильтрация ICMP». Укажите альтернативные объяснения, которые ещё не исключены.
После изменения ACL/маршрута повторите тот же тест и прикладной запрос. Приёмка — нормальная работа нужного сервиса и отсутствие исходного симптома в сопоставимом окне. Диагностика не требует выключать весь firewall или сбрасывать таблицу маршрутов. Если правила всё-таки менялись в отдельном согласованном окне, возвращайте точное прежнее правило, а не заводские настройки сети.
Источники: Microsoft Learn — tracert, Microsoft Learn — pathping.