Traceroute — как мы видим путь пакета

Когда вы запускаете traceroute github.com, на экране построчно появляется путь пакета через интернет: ваш роутер, провайдер, магистрали, AS GitHub. Каждая строка — один прыжок (hop). За этой простой картинкой — очень интересный трюк со старым полем TTL в IPv4-заголовке.

В этом уроке разберём, как именно traceroute узнаёт промежуточные роутеры, почему некоторые хопы показывают * * *, чем отличаются UDP/TCP/ICMP probes, и что такое mtr. После урока вы будете читать вывод traceroute как профессионал — видеть, где проблема, где загруженность, где блок ICMP.

Знать traceroute обязательно для DE — это первый инструмент диагностики «почему мой сервис недоступен», и его правильное чтение экономит часы дебага.

TTL — счётчик хопов

В IPv4-заголовке есть поле TTL (Time To Live) — 8 бит, число от 0 до 255. Изначально задумывалось как «время жизни в секундах», но на практике превратилось в счётчик хопов.

Правило:

1. Отправитель ставит TTL в начальное значение (обычно 64 на Linux, 128 на Windows, 255 на Cisco).
2. Каждый роутер на пути уменьшает TTL на 1 прежде чем переслать пакет дальше.
3. Если роутер уменьшает TTL и получает 0 — пакет дропается, и роутер шлёт обратно ICMP Time Exceeded.

Это защита от routing loops: если пакет случайно зациклился (роутер A шлёт на B, B на A), TTL быстро дойдёт до 0 и пакет умрёт. Без TTL бесконечная петля забила бы сеть.

Идея traceroute — использовать TTL как зонд

Traceroute эксплуатирует это поведение:

1. Шлём пакет с TTL = 1.
2. Первый роутер уменьшает до 0, дропает пакет, шлёт ICMP Time Exceeded со своего IP.
3. Мы видим src IP в ICMP — это первый хоп.
4. Шлём пакет с TTL = 2.
5. Первый роутер уменьшает до 1, передаёт дальше. Второй роутер уменьшает до 0, шлёт ICMP.
6. Мы видим второй хоп.
7. И так далее, увеличивая TTL пока не достигнем цели.

Реализация — цикл: TTL = 1, 2, 3, … 30. На каждом TTL обычно шлётся 3 пакета (поэтому в выводе три времени на строку — три RTT).

Вывод traceroute — разбор

$ traceroute -n github.com
traceroute to github.com (140.82.121.4), 30 hops max, 60 byte packets
 1  192.168.1.1   1.234 ms  1.456 ms  1.678 ms
 2  10.0.0.1      5.678 ms  5.789 ms  5.890 ms
 3  87.123.45.6   12.345 ms  12.456 ms  12.567 ms
 4  87.123.45.7   13.567 ms  13.678 ms  13.789 ms
 5  * * *
 6  185.62.74.18  45.678 ms  45.789 ms  45.890 ms
 7  140.82.114.1  46.123 ms  46.234 ms  46.345 ms
 8  140.82.121.4  46.567 ms  46.678 ms  46.789 ms

Чтение:

• traceroute to github.com (140.82.121.4), 30 hops max, 60 byte packets — разрешили DNS, начинаем.
• Hop 1: 192.168.1.1 — ваш домашний роутер. RTT ~1-2 мс — это локалка.
• Hop 2: 10.0.0.1 — gateway провайдера, RTT 5 мс (последняя миля).
• Hop 3-4: магистральные роутеры в стране провайдера. RTT 12-13 мс.
• Hop 5: * * * — три probe-пакета не получили ответа. Не обязательно проблема — этот роутер просто не отвечает на ICMP Time Exceeded (либо настроен скрывать себя, либо rate-limit ICMP).
• Hop 6-8: дальние роутеры до GitHub, RTT 45-47 мс. Внутри AS GitHub.

Особенности:

• -n отключает DNS-резолв. Иначе на каждый hop делается reverse DNS lookup (50.10.0.10.in-addr.arpa -> hostname), что медленно и не всегда полезно.
• Три времени на строку — три probe. Если они сильно отличаются (1мс / 50мс / 1мс) — разная нагрузка или путь.
• * * * — молчит роутер. Часто не значит «сломано». Часто значит «фильтрует ICMP».

ICMP, UDP, TCP probes — три варианта traceroute

Технически traceroute может слать probe-пакеты трёх типов:

1. UDP (классический Unix traceroute). Шлёт UDP-пакет на высокий порт (33434, 33435, …). Промежуточные роутеры отвечают ICMP TimeExceeded. Цель, получив UDP на закрытый порт, отвечает ICMP Port Unreachable — traceroute понимает «дошли».

2. ICMP (Windows tracert, Linux traceroute -I). Шлёт ICMP Echo Request (как ping). Промежуточные отвечают ICMP TimeExceeded. Цель отвечает ICMP Echo Reply.

3. TCP (traceroute -T). Шлёт TCP SYN на указанный порт. Промежуточные отвечают ICMP TimeExceeded. Цель отвечает TCP SYN-ACK или RST. Часто проходит лучше, потому что firewalls фильтруют UDP/ICMP, но пропускают TCP-syn на популярные порты (80, 443).

В реальной диагностике:

• Если traceroute github.com показывает * * * уже с 3-го хопа — попробуйте traceroute -I github.com (ICMP) или traceroute -T -p 443 github.com (TCP к 443).
• Если TCP traceroute доходит до цели, а UDP нет — проблема в правилах firewalls на UDP.

# Linux:
traceroute -I github.com         # ICMP
traceroute -T -p 443 github.com  # TCP к 443
traceroute -U github.com         # UDP (как default)

# macOS:
sudo traceroute -I github.com
sudo traceroute -P TCP -p 443 github.com

# Windows:
tracert github.com               # ICMP, всегда
# Для TCP/UDP -- использовать pathping или сторонние утилиты

Почему * * *

Звёздочки в traceroute — частое явление. Не значит что что-то сломано. Причины:

1. Роутер не отвечает на ICMP Time Exceeded. Некоторые роутеры (особенно core-роутеры) скрывают себя — не отвечают вообще.
2. Rate-limiting ICMP. Роутер видит много ICMP-запросов, дропает излишки. Перезапустите trace — может пройти.
3. Firewall на пути. Блокирует ICMP TimeExceeded на одном из направлений.
4. Asymmetric routing. Probe идёт через одни роутеры, ответ — через другие. На промежуточных хопах ответ может потеряться.
5. Просто потеря пакета. Сеть загружена, пакет дропнулся.

Что делать:

# Запустить с большим количеством probe на хоп:
traceroute -q 5 github.com   # 5 probes вместо 3
# Если хоть один пройдёт -- увидим IP

# Сменить тип probe:
traceroute -I github.com     # ICMP вместо UDP
traceroute -T -p 80 github.com   # TCP к 80

# Использовать mtr для постоянного мониторинга:
mtr github.com
# (об mtr ниже)

Если * * * ТОЛЬКО на одном хопе, дальше всё ok — это просто «тихий» роутер, не проблема. Если * * * на 3-4 хопах подряд И traceroute доходит до цели — может быть блок ICMP в каком-то сегменте. Если * * * на всех хопах после определённого — настоящая проблема со связностью.

mtr — traceroute + ping в одном

mtr (My TraceRoute) — интерактивный инструмент, постоянно делающий traceroute и показывающий статистику. Лучший инструмент для длительного мониторинга пути.

mtr github.com
# вывод в реальном времени, обновляется каждую секунду:
#
#                            My traceroute  [v0.95]
# laptop (192.168.1.42)                                  Last 100 / 100 pkts
# Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
# 1. 192.168.1.1                     0.0%    100    1.2   1.3   1.0   2.1   0.2
# 2. 10.0.0.1                        0.0%    100    5.6   5.8   5.1   8.2   0.4
# 3. 87.123.45.6                     2.0%    100   12.3  12.5  11.8  14.1   0.3
# 4. 87.123.45.7                     0.0%    100   13.5  13.6  13.0  14.8   0.3
# 5. ???                           100.0%    100    0.0   0.0   0.0   0.0   0.0
# 6. 185.62.74.18                    0.0%    100   45.6  45.8  44.5  47.2   0.5
# 7. 140.82.121.4                    0.0%    100   46.5  46.7  45.5  48.0   0.4

Что mtr показывает:

• Loss% — процент потерь на этом хопе. Если 100% — хоп не отвечает (см. выше про * * *).
• Snt — сколько пакетов отправлено.
• Last/Avg/Best/Wrst — последний/средний/лучший/худший RTT.
• StDev — стандартное отклонение RTT (волатильность).

Важный нюанс: loss на промежуточном хопе НЕ обязательно значит проблему сети. Часто это ICMP rate-limit на конкретном роутере. Смотрите на конечный loss до цели:

• Если на цели 0% потерь — путь нормальный, промежуточные потери — косметика.
• Если на цели много потерь и они начинаются с какого-то конкретного хопа — ищите проблему там.

# mtr с дополнительными опциями:
mtr -n github.com               # без DNS, быстрее
mtr -r -c 100 github.com        # report mode -- 100 циклов и вышел
mtr -T -P 443 github.com        # TCP probes на 443

# В Windows есть аналог -- pathping:
pathping github.com

Чтение traceroute — кейсы

Кейс 1: всё хорошо.

1  192.168.1.1   1ms
2  10.0.0.1      5ms
3  87.123.45.6  12ms
4  87.123.45.7  13ms
5  185.62.74.18 45ms
6  140.82.121.4 46ms

Растущий RTT, никаких звёзд. Хорошо.

Кейс 2: проблема на одном хопе.

1  192.168.1.1   1ms
2  10.0.0.1      5ms
3  87.123.45.6  150ms (!!! резкий скачок)
4  87.123.45.7  151ms
5  185.62.74.18 152ms
6  140.82.121.4 153ms

Резкий рост RTT на hop 3 (с 5 до 150 мс). Дальше RTT не растёт — значит проблема между hop 2 и hop 3. Возможно, перегруженный канал, или физическая трасса (трансатлантический кабель).

Кейс 3: хоп тихий, но дальше всё ok.

1  192.168.1.1   1ms
2  10.0.0.1      5ms
3  * * *
4  87.123.45.7   13ms
5  185.62.74.18  45ms
6  140.82.121.4  46ms

Hop 3 не отвечает (ICMP block), но traceroute дошёл до цели. Это не проблема — просто фильтр ICMP на hop 3.

Кейс 4: цикл маршрута.

1  192.168.1.1   1ms
2  10.0.0.1      5ms
3  87.123.45.6  12ms
4  87.123.45.7  13ms
5  10.0.0.1      5ms (!!! пакет вернулся)
6  87.123.45.6  12ms
7  87.123.45.7  13ms
8  10.0.0.1      5ms

Пакет ходит по кругу 2-3-4-2-3-4. Это routing loop. TTL спасёт от вечного цикла, но связности нет. Нужно исправлять конфиг роутеров.

Geographic latency — сколько должно быть

Скорость света в оптоволокне — ~200,000 км/с. То есть:

• Внутри города (10-50 км) — RTT 1-5 мс.
• Внутри страны (1000-3000 км) — RTT 20-40 мс.
• Через океан (10,000 км) — RTT 80-150 мс.
• Через два океана (20,000 км) — RTT 200-300 мс.

Когда видите RTT 150 мс на трассе из Москвы в Москву — что-то странно. Возможно, трафик идёт через США или Европу (например, ваш ISP без peering с конечным хостом и идёт через магистраль).

Это полезно для диагностики:

• RTT в 1.5x от теоретически минимального — норма.
• RTT в 3-5x — стоит разобраться.
• RTT в 10x — точно что-то не так.

Попробуй сам

# 1. Простой traceroute:
traceroute -n google.com

# 2. Установить и запустить mtr (требует root):
sudo apt install mtr-tiny      # Debian/Ubuntu
brew install mtr               # macOS
sudo mtr github.com

# 3. Сравнить разные типы probe:
traceroute -I google.com           # ICMP
traceroute -T -p 443 google.com    # TCP

# 4. Узнать собственный TTL по дефолту:
ping -c 1 127.0.0.1 | grep ttl
# 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.043 ms
# ttl=64 -- значит initial TTL вашей машины 64 (Linux)
# 128 -- Windows
# 255 -- Cisco / BSD

# 5. Trace на разные географические направления:
traceroute -n -T -p 443 google.com         # обычно близко
traceroute -n -T -p 443 ya.ru               # российский
traceroute -n -T -p 443 baidu.com           # китайский (через RU/EU/US)
# Поразитесь, насколько разные пути и RTT

# 6. С большим количеством probe (для несбойных результатов):
traceroute -q 10 google.com

# 7. С увеличенным timeout (для медленных каналов):
traceroute -w 5 google.com    # 5 секунд ожидания на probe

# 8. Wireshark/tcpdump параллельно с traceroute:
sudo tcpdump -i any -n 'icmp' -c 30   # увидите ICMP Time Exceeded ответы

Очень рекомендую сравнить три trace из пункта 5 — увидите, как через разные регионы трафик идёт по совершенно разным магистралям.