Трассировка пути: traceroute, tracert и mtr
Трассировка — самый часто прикладываемый к заявкам и самый часто неправильно прочитанный вывод в сетевой эксплуатации. Звёздочки в середине принимают за аварию, всплеск времени на одном узле — за перегрузку магистрали, а расхождение адресов в соседних пробах — за «прыгающий маршрут». В этом уроке разберём механизм до последнего пакета и научимся читать вывод так, как его читает инженер, а не как его читает встревоженный клиент.
«Клиент прикладывает к заявке трассировку: на седьмом переходе три звёздочки, на восьмом время 90 мс вместо обычных 20. Пишет: „у вас проблема на седьмом хопе, там всё теряется, и дальше растёт задержка“. Просит устранить. При этом сервис у него работает, и до конечного узла трассировка доходит с нормальным временем.»
В этой картине нет ни одной неисправности. Но чтобы ответить клиенту убедительно, а не отпиской, нужно точно понимать, что порождает каждую строку вывода.
- Откуда утилита вообще узнаёт адреса чужих маршрутизаторов, если она их ни о чём не спрашивает?
- Если узел отвечает звёздочкой, но следующий за ним отвечает нормально — как пакет прошёл через «молчащий» узел?
- Почему у одного перехода в трёх пробах могут быть три разных адреса?
- Разберёшь механизм по шагам: почему растущий счётчик переходов превращается в карту пути
- Поймёшь, чем отличаются три реализации — классическая на UDP, ICMP в Windows и TCP-режим
- Объяснишь по стандарту, почему видно именно ту сторону узла, которая обращена к тебе
- Научишься различать пять причин звёздочек, из которых четыре — не авария
- Перестанешь путать «всплеск времени на переходе» и «задержка выросла до конца трассы»
- Увидишь, как несколько равнозначных путей ломают наивное чтение вывода и что с этим делать
- Узнаешь, почему часть узлов внутри туннеля не видна и когда они внезапно появляются
- Освоишь непрерывное измерение и правило «главная строка — последняя»
- Сообщения об ошибке порождают устройства на пути — сегодня мы построим на этом целый инструмент.
- Служебные ответы формирует процессор устройства, и он ограничен по скорости. Это объяснит и звёздочки, и всплески времени.
- TTL в ответе оценивал длину обратного пути. Сегодня тот же счётчик станет управляющим параметром, а не наблюдаемым.
1. Механизм: счётчик переходов как измерительный инструмент
В заголовке IP есть поле TTL — счётчик, который каждый маршрутизатор обязан уменьшить на единицу. Когда счётчик достигает нуля, пакет отбрасывается. И здесь вступает требование RFC 1812 (раздел 5.2.7.3): «When a router discards a datagram because the TTL field has reached zero, it MUST send an ICMP Time Exceeded message» — маршрутизатор обязан сообщить об этом отправителю.
Из этой обязанности и вырастает трассировка. Идея настолько простая, что кажется трюком:
Трассировка ничего ни у кого не спрашивает. Она намеренно «убивает» пробы на нужном расстоянии и собирает адреса из обязательных сообщений об ошибке.
Отсюда следует важное свойство, которое надо усвоить сразу: каждая строка вывода порождена процессором соответствующего узла, а не его микросхемой пересылки. Всё, что мы обсуждали про ограничение скорости служебных ответов в прошлом уроке, действует здесь в полной мере — и объясняет большую часть «странностей» вывода.
2. Три реализации traceroute: UDP, ICMP и TCP
Механизм счётчика один, а вот чем именно посылать пробу — вопрос реализации, и от него зависит, дойдёт ли она вообще.
| Режим | Чем зондирует | Как узнаёт, что дошёл до цели | Где применять |
|---|---|---|---|
| Классический UDP (Unix по умолчанию) | UDP на «маловероятный» порт, начиная с 33434, по одному на пробу | Цель отвечает «порт недостижим» | Внутри своей сети, где фильтров нет |
ICMP (tracert в Windows, -I в Unix) |
Эхо-запрос | Цель отвечает эхо-ответом | Когда UDP отсекается, а эхо разрешено |
TCP (-T) |
Начало соединения на порт сервиса, по умолчанию 80 | Цель отвечает подтверждением или отказом | Через межсетевые экраны, где живёт только рабочий трафик |
Документация Linux описывает классический режим прямо: «Probe packets are udp datagrams with so-called „unlikely“ destination ports. The „unlikely“ port of the first probe is 33434, then for each next probe it is incremented by one» (man traceroute). Там же зафиксированы значения по умолчанию: три пробы на переход, максимум 30 переходов, ожидание ответа 5 секунд.
Практический вывод, который экономит часы: если трасса «умирает» на середине в интернете, прежде чем эскалировать — повтори её в режиме TCP на нужный порт. Очень часто путь целиком рабочий, а отсекаются именно пробы. TCP-проба повторяет путь настоящего трафика, и это единственный режим, который отвечает на вопрос «а мой сервис туда дойдёт».
3. Какой адрес узла ты видишь и почему это важно
Инженеры часто спорят, «вход» или «выход» показывает трассировка. Спор решается одной цитатой. RFC 1812, раздел 4.3.2.4:
«Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted.»
То есть адресом источника обязан быть адрес интерфейса, через который уходит само служебное сообщение. А уходит оно назад, к отправителю пробы — как правило, через тот же стык, по которому проба пришла. Отсюда и наблюдаемая картина: мы видим ту сторону узла, которая обращена к нам.
Практических следствий два. Первое: по трассировке нельзя достроить топологию «наружу» — ты видишь только ближние к себе интерфейсы. Второе: если у оператора настроена маршрутизация, при которой ответ уходит другим интерфейсом, адреса в трассировке перестанут соответствовать твоим ожиданиям — и это не ошибка, а другая, тоже законная конфигурация.
4. Пять причин звёздочек, и только одна из них — авария
Звёздочка означает ровно одно: в отведённое время ответа на пробу не пришло. Причин у этого пять.
- Узел не генерирует служебные сообщения. Осознанная настройка на многих магистральных маршрутизаторах: сообщения об истечении времени жизни отключены, чтобы не тратить процессор. Транзит при этом идёт идеально.
- Ответ ограничен по скорости. RFC 1812 разрешает маршрутизатору ограничивать частоту порождения служебных сообщений. При трёх пробах в секунду часть ответов просто не выпускается.
- Служебные сообщения отфильтрованы по дороге назад. Узел ответил, но ответ не дошёл до тебя — где-то на обратном пути стоит фильтр.
- Проба не дошла до узла. Отсекается сам зондирующий трафик: UDP на странный порт или эхо. Лечится сменой режима на TCP.
- Настоящая потеря связности. Только в этом случае звёздочки идут до самого конца вывода, и конечный узел тоже не отвечает.
Смотри на последнюю строку. Если конечный узел ответил — путь рабочий, и всё, что выше, это особенности поведения промежуточных узлов, а не неисправность. Звёздочки в середине при живой последней строке диагностической ценности не имеют.
5. Время в строке: что оно на самом деле измеряет
Время в строке трассировки складывается из трёх слагаемых: путь пробы до узла, время формирования ответа процессором этого узла, путь ответа обратно. Второе слагаемое — самое капризное: служебные ответы обрабатываются по остаточному принципу, поэтому занятый процессор легко даёт всплеск в десятки миллисекунд.
Отсюда простое различение, которое надо довести до автоматизма:
Всплеск на одном переходе
Время выросло на узле N, а на N+1 и дальше снова нормальное. Значит транзит через узел N быстрый, а медленно он отвечает сам. Реагировать не на что.
Ступенька до конца трассы
Время выросло на узле N и осталось высоким на всех последующих. Значит задержку добавил участок перед узлом N. Вот это — предмет разбора.
Второй случай тоже не всегда авария: ступенька в 60–80 мс между континентами — это физика, скорость света в стекле. Задержку надо сравнивать не с нулём, а с историческим значением по этому же направлению.
6. Несколько равнозначных путей: почему адреса «прыгают»
В сетях операторов между двумя точками почти всегда есть несколько равнозначных маршрутов, и трафик распределяется между ними. Распределение делается по потокам: устройство считает хеш от набора полей заголовка — адресов и портов — и все пакеты одного потока идут одним путём. Так сохраняется порядок пакетов.
А теперь вспомним, что классическая трассировка меняет порт назначения на каждой пробе. С точки зрения балансировщика это разные потоки, и они законно уходят разными путями. Результат в выводе: три пробы одного перехода показывают разные адреса.
Использовать режим, сохраняющий признаки потока постоянными между пробами, — например, TCP-режим с фиксированным портом назначения либо специализированные утилиты, которые умеют перебирать пути осознанно. И не пытаться склеить «прыгающие» адреса в один маршрут: их там несколько, и это нормальная, а не аварийная конфигурация.
7. Почему часть узлов не видна: туннели
Если оператор передаёт трафик через транспортную технологию с метками, промежуточные устройства внутри такого туннеля работают с меткой, а не с заголовком IP. Существует два поведения. При первом счётчик переходов IP внутри туннеля не уменьшается — и весь туннель выглядит как один переход, а десяток реальных устройств не виден вовсе. При втором счётчик прозрачно переносится в метку, и внутренние узлы появляются в выводе, иногда с пометкой о метке.
Практический вывод: число строк в трассировке не равно числу устройств на пути. Сравнивать трассировки «было — стало» по количеству переходов бессмысленно, если между замерами оператор поменял режим прозрачности туннеля.
8. mtr: непрерывное измерение вместо одного снимка
Обычная трассировка — это один снимок с тремя пробами на переход. Для поиска редких
и плавающих потерь этого мало: три пробы не отличат 2% потерь от 0%. Непрерывный
режим (утилита mtr и её аналоги) шлёт пробы постоянно и показывает
накопленную статистику по каждому переходу.
mtr -rwzbc 200 198.51.100.10
# -r отчётом, а не интерактивно
# -c число циклов
# -b показывать и адрес, и имя
# -w широкий формат выводаЧитается такой отчёт по одному правилу, и оно противоположно интуиции: смотри снизу вверх. Потери на промежуточном переходе, которые не повторяются на следующих, порождены ограничением служебных ответов. Реальная потеря обязана проявиться на всех переходах ниже: если пакет потерян на седьмом узле, до восьмого он тоже не дошёл.
«Потери 4% фиксируются начиная с перехода 7 и сохраняются на всех последующих переходах вплоть до конечного узла, замер 500 проб, повторено трижды в разное время суток» — это доказательство. «На седьмом хопе звёздочки» — это не доказательство, и грамотный смежник вернёт такую заявку.
9. Мини-лаба: попробуй прямо сейчас
Шаг 1. Снять базовую трассировку и сверить с прошлым уроком.
Linux/macOS: traceroute 1.1.1.1
Windows: tracert 1.1.1.1Ожидаемый результат: от 5 до 15 строк. Сравни число переходов с оценкой, которую ты получил из TTL в первом уроке. Совпадения по числу может не быть — это и есть асимметрия путей, наглядно.
Шаг 2. Сравнить три режима на одной цели.
traceroute 1.1.1.1 # классический UDP
traceroute -I 1.1.1.1 # ICMP
sudo traceroute -T -p 443 1.1.1.1 # TCP на порт HTTPSОжидаемый результат: наборы отвечающих узлов различаются. Чаще всего именно TCP-режим доходит дальше остальных. Запиши, на каком переходе каждый режим начал молчать, — это карта фильтрации на пути.
Шаг 3. Увидеть распределение по путям.
traceroute -q 6 8.8.8.8 # шесть проб на переход вместо трёхОжидаемый результат: на одном-двух переходах в середине появятся два и более разных адреса в одной строке. Это равнозначные маршруты, а не «прыгающий маршрут».
Шаг 4. Отличить всплеск от ступеньки.
Найди в своей трассировке переход, где время заметно больше соседних, и посмотри на следующие строки. Ожидаемый результат: в большинстве случаев время вернётся к прежнему уровню — значит это медленный ответ узла, а не задержка на участке.
10. Задачи самопроверки
1. Трассировка доходит до цели за 12 переходов, но переходы 5, 6 и 7 — сплошные звёздочки. Клиент требует «починить пятый хоп». Что ответить?
Что путь исправен: доказательством служит ответ конечного узла и нормальное время до него. Звёздочки означают, что три промежуточных узла не порождают служебные сообщения — это либо их настройка, либо ограничение частоты, разрешённое RFC 1812, либо фильтрация этих сообщений на обратном пути. Пересылка транзита и генерация служебных ответов — разные функции: устройство может исправно делать первое и не делать второе. Ремонтировать здесь нечего.
2. В отчёте непрерывного измерения на переходе 4 потери 30%, а на переходах 5–10 потерь нет. Где неисправность?
Нигде. Если бы пакеты действительно терялись на четвёртом узле, они не дошли бы до пятого и последующих — потери обязаны наследоваться вниз по трассе. Раз ниже потерь нет, значит терялись не пакеты, а служебные ответы четвёртого узла: его процессор ограничивает их частоту. Правило чтения: смотри на последнюю строку и на непрерывность потерь.
3. Почему нельзя судить о качестве канала по времени в средних строках трассировки?
Потому что это время включает обработку в процессоре промежуточного узла, а он обслуживает служебные запросы по остаточному принципу. К пересылке транзитного трафика это отношения не имеет. Кроме того, измеряется полный путь туда и обратно, причём обратный путь от каждого узла — свой. Качество канала измеряется сквозь участок: к конечному узлу, длинной серией, с разбором разброса.
4. Ты видишь в трассировке адрес 10.x.x.x внутри сети оператора. Это ошибка настройки?
Нет. Операторы часто нумеруют внутренние стыки частными адресами, и служебные сообщения законно приходят с них. Обратная связь до такого адреса из интернета невозможна, поэтому пингануть этот узел ты не сможешь — и это не признак неисправности. Для разбора нужен встречный замер со стороны оператора.
5. Прямая трассировка показывает 9 переходов, встречная от цели к тебе — 14. Кто-то ошибся?
Никто. Маршрутизация в IP односторонняя: пути туда и обратно выбираются независимо и вполне могут проходить через разных операторов. Именно поэтому при разборе аварии всегда нужны два замера с обеих сторон — по одному прямому выводу нельзя судить, где теряется трафик на обратной дороге.
6. Классическая трассировка обрывается на переходе 6, а TCP-режим на порт 443 доходит до цели. Что это говорит о пути?
Что путь для рабочего трафика полностью исправен, а на шестом переходе или дальше отсекаются пробы классического режима — UDP на нестандартные порты. Это обычная политика межсетевого экрана. Вывод для заявки: сервис доступен, проблема измерения, а не связности. Полезно приложить оба вывода — они вместе доказывают тезис.
11. Словарик урока
| Термин | English | Что означает |
|---|---|---|
| Переход | Hop | Один маршрутизатор на пути пакета |
| Истечение времени жизни | Time Exceeded | Тип 11 в IPv4, тип 3 в IPv6 |
| Проба | Probe | Пакет, отправленный с намеренно малым счётчиком переходов |
| Равнозначные маршруты | ECMP, Equal-Cost Multi-Path | Несколько путей одинаковой стоимости, трафик делится по потокам |
| Асимметрия путей | Path asymmetry | Дорога туда и обратно не совпадает |
| Порт недостижим | Port Unreachable | Тип 3 код 3: признак того, что проба дошла до цели |
| Прозрачность счётчика | TTL propagation | Переносится ли счётчик IP в метку туннеля |
| Непрерывная трассировка | mtr, My Traceroute | Постоянные пробы со сводной статистикой по переходам |
12. Главное
- Каждая строка вывода — чужое сообщение об ошибке. Его порождает процессор узла, а не микросхема пересылки, — со всеми вытекающими ограничениями.
- Главная строка — последняя. Ответила цель — путь рабочий, что бы ни творилось выше.
- Звёздочки в середине в четырёх случаях из пяти означают «всё в порядке». Авария — это звёздочки до конца вывода.
- Потери обязаны наследоваться вниз по трассе. Потери на одном переходе, которых нет ниже, — это ограничение служебных ответов, а не потеря пакетов.
- Виден адрес интерфейса, через который уходит ответ — по требованию RFC 1812. Обычно это сторона узла, обращённая к тебе.
- Разные адреса в одной строке — это равнозначные маршруты, а не прыгающий путь.
- Обратный путь трассировка не показывает. Для разбора аварии нужен встречный замер.
- Не доходит классический режим — пробуй TCP на порт сервиса. Он повторяет путь настоящего трафика.
13. Мост к следующему уроку
Теперь мы умеем отвечать на вопросы «доходит ли» и «где». Остался третий, самый коварный: а какого размера пакет доходит. Есть целый класс аварий, при которых и пинг, и трассировка выглядят идеально, а сервис не работает: мелкие пакеты проходят, крупные молча исчезают. В следующем уроке разберём MTU, накладные расходы туннелей, механизм определения размера на пути и то, почему безобидная на вид фильтрация служебных сообщений превращается в неуловимую «чёрную дыру».
14. Источники
- RFC 1812, разделы 4.3.2.4 (адрес источника служебного сообщения), 4.3.2.8 (ограничение частоты, включая эхо-ответы), 5.2.7.3 (обязанность сообщить об исчерпании времени жизни)
- RFC 792 — Time Exceeded (тип 11, код 0) и Destination Unreachable (тип 3, код 3 «порт недостижим»)
- RFC 4443 — соответствующие типы для IPv6: Time Exceeded тип 3, Destination Unreachable тип 1
- man traceroute(8) —
порт первой пробы 33434 и его приращение, режимы
-Iи-T(порт по умолчанию 80), три пробы на переход, 30 переходов, ожидание 5 секунд, значение звёздочки, пометки!H,!N,!X