Принцип работы и отличия от Windows
Traceroute отправляет пакеты, у которых поле TTL растёт от единицы. Первый узел уменьшает TTL до нуля и сообщает об этом отправителю, за ним так же отвечает второй, и вы собираете путь по одному узлу. Windows-версия tracert делает то же самое, но использует ICMP-запросы. В Linux и macOS по умолчанию traceroute отправляет UDP-пакеты на большие порты, обычно начиная с 33434.
Из-за этого результаты двух систем могут отличаться: одни узлы блокируют UDP на высоких портах, другие не отвечают на ICMP. Если при одном способе трассировка обрывается, стоит попробовать другой, и мы покажем, как переключаться.
Кроме того, в некоторых минимальных установках Linux программы traceroute нет: её ставят отдельным пакетом. В macOS утилита входит в состав системы.
Отдельно запомните про IPv6: в Linux достаточно ключа -6 или отдельной команды traceroute6, в macOS используется traceroute6. Для сравнения маршрутов двух протоколов выполните обе трассировки к одному имени и сопоставьте число переходов и время на них. Различия бывают значительными, потому что IPv4 и IPv6 нередко идут через разные линии.
Базовые команды и основные ключи
Самый простой запуск: traceroute example.com. Для удобства чтения почти всегда добавляют -n, чтобы не тратить время на поиск имён. Ниже основные ключи, которые работают и в Linux, и в macOS.
| Ключ | Назначение | По умолчанию |
|---|---|---|
| -n | Показывать только числовые адреса | имена запрашиваются |
| -m число | Максимальное число переходов | 30 |
| -q число | Число запросов на каждый переход | 3 |
| -w секунды | Сколько ждать ответа | несколько секунд, значение зависит от реализации |
| -I | Использовать ICMP echo вместо UDP | UDP |
| -6 | Работать по IPv6 (в macOS также есть traceroute6) | по DNS |
Ключ -w здесь принимает секунды, а не миллисекунды, как в Windows: типичная ошибка при переносе привычек. Некоторые ключи требуют прав администратора: в Linux для режима ICMP может понадобиться sudo, а в macOS ICMP-режим тоже проще запускать с правами администратора.
Для быстрой проверки достаточно ключей -n и -m: traceroute -n -m 15 example.com завершится быстрее, чем стандартный запуск. Если нужно сократить время ожидания на молчащих узлах, уменьшите значение -w до одной секунды и снизьте число запросов ключом -q до двух.
Разные протоколы зондирования
Если обычная трассировка обрывается на середине, меняйте тип пакетов, а не значения ожидания. Вот основные способы.
- Стандартный UDP: traceroute -n example.com. Подходит для быстрой проверки, но чаще всего режется фильтрами.
- ICMP: traceroute -I -n example.com. Похож на поведение tracert в Windows. Требует прав, если система их спрашивает.
- TCP SYN (Linux): traceroute -T -p 443 -n example.com. Пакеты выглядят как попытка соединения с портом 443, поэтому фильтры пропускают их чаще. Как правило, нужны права root. В macOS штатный traceroute режим TCP не поддерживает.
Если цель достигается при TCP-трассировке, но не при UDP и ICMP, значит, узлы отбрасывают именно те пакеты. Это не признак неполадки маршрута.
Правило для чтения: сравнивайте не отдельные числа, а общую картину по нескольким запускам и разным способам зондирования.
Пример вывода и как его читать
Пример (пример, адреса из блока документации):
traceroute to example.com (203.0.113.50), 30 hops max, 60 byte packets 1 192.0.2.1 0.5 ms 0.4 ms 0.4 ms 2 198.51.100.1 3.2 ms 3.0 ms 3.1 ms 3 * * * 4 203.0.113.9 11.8 ms 12.1 ms 11.9 ms 5 203.0.113.50 25.3 ms 25.0 ms 25.6 ms
Первая строка сообщает целевой адрес, лимит переходов и размер пакета. Далее идут узлы по порядку: адрес и три времени ответа. Строка из трёх звёздочек означает, что узел не ответил на три запроса подряд.
Иногда рядом с временем встречаются пометки вроде !H (узел недоступен), !N (сеть недоступна) или !X (доступ запрещён фильтром). Они означают, что промежуточное устройство прислало ICMP-сообщение об ошибке, а не ответ. Такая пометка показывает, где именно пакеты останавливаются и кто их остановил.
Иногда на одном переходе печатается несколько разных адресов: это признак балансировки нагрузки, когда пакеты идут разными путями.
Также стоит обратить внимание на размер пробных пакетов: в первой строке вывода указан размер (например, 60 байт). Его можно увеличить, задав длину пакета в конце команды, и так проверить, как маршрут справляется с крупными пакетами. Но для этой задачи удобнее tracepath, который сам ищет предел MTU.
Типичные проблемы и когда трассировка вводит в заблуждение
Прежде чем делать выводы, учтите особенности метода.
- Ответы узла на служебные запросы идут с низким приоритетом. Высокое время на одном узле при нормальных значениях после него ничего не доказывает.
- Маршрут туда и обратно может отличаться. Traceroute показывает только путь запроса, а ответы могут возвращаться иным маршрутом.
- Балансировка нагрузки способна перемешивать узлы в выводе, создавая ложную картину странного пути.
- Межсетевые экраны у цели могут не пускать пробные пакеты, и до самого конца трассировка не дойдёт при полностью рабочем узле.
Для оценки потерь во времени применяйте mtr, он повторяет зондирование многократно и показывает статистику. Для проверки MTU по пути пригодится tracepath. Трассировку допускается выполнять только к своим узлам или общедоступным адресам без чрезмерной частоты запросов. Если вы собираете данные для провайдера, сохраните вывод в файл и добавьте время запуска.