traceroute и mtr: как искать узкое место в маршруте

Сайт отвечает медленно, хотя ping показывает нормальные 20–40 мс: проблема не в доступности узла, а где-то на пути пакетов. traceroute показывает сам маршрут, а mtr превращает разовую трассировку в непрерывное измерение и помогает отделить реальные потери от особенностей фильтрации ICMP.

Как работают traceroute и mtr

Оба инструмента используют поле TTL в заголовке IP. Первый пакет уходит с TTL=1, на первом маршрутизаторе TTL истекает, и тот возвращает сообщение ICMP Time Exceeded. Затем TTL увеличивается на единицу, и так до получателя. В Linux traceroute по умолчанию отправляет UDP-датаграммы на высокие порты, а ключи -I и -T переключают его на ICMP Echo и TCP SYN соответственно. Для TCP полезно указать реальный порт сервиса, например 443: такой пакет чаще проходит через межсетевые экраны.

mtr объединяет трассировку и ping: он постоянно опрашивает все обнаруженные хопы и накапливает статистику. По умолчанию mtr тоже использует ICMP, но умеет UDP и TCP. Для сырых сокетов обычно нужны права root, поэтому запускайте его через sudo. Главная ценность mtr — не один снимок, а распределение задержек и потерь за десятки или сотни циклов.

traceroute -n -T -p 443 example.com
sudo mtr -rwzc 50 example.com
sudo mtr -T -P 443 -rwzc 50 example.com
tracepath -n example.com

Ключи mtr читаются так: -r — отчёт вместо интерактивного экрана, -w — широкий вывод, -z — показать номера автономных систем, -c — число циклов. tracepath полезен, когда нужно проверить ещё и MTU на пути и нет прав root.

Как читать потери и задержки

Частая ошибка — считать любую потерю на промежуточном хопе аварией. Маршрутизаторы часто ограничивают ответы ICMP и отдают их с низким приоритетом. Признак реальной проблемы другой: потери начинаются на конкретном хопе и сохраняются на всех последующих, вплоть до получателя. Если на пятом хопе 40% потерь, а дальше ноль, это rate limiting маршрутизатора, а не проблема соединения.

Задержка важна в сравнении с соседними хопами: рост с 15 до 120 мс, который держится дальше, указывает на перегруженный участок. Высокий StDev и большой разброс между лучшим и худшим временем означают джиттер, особенно мешающий голосовой связи и видеоконференциям. Помните про асимметрию: обратный путь может идти иначе, и проблемы там видны только при трассировке с противоположной стороны.

Несколько IP-адресов у одного хопа — это не ошибка, а балансировка нагрузки. Разные пробы могут попадать на разные устройства, поэтому потери и задержки у них отличаются. Для диагностики запускайте больше циклов и смотрите на устойчивую картину, а не на одну строку.

Разбор типичных сценариев

Проблема в первом хопе. Если потери начинаются на шлюзе, проверьте Wi-Fi и локальную сеть: ip -s link show wlan0 покажет ошибки и дропы, iw dev wlan0 link — состояние радиоканала. Помогают смена канала, отказ от перегруженного 2,4 ГГц и проверка кабеля.

Проблема у провайдера. Потери стартуют на третьем-четвёртом хопе и держатся до конца. Сохраните отчёт mtr с датой и временем, укажите направление трафика и повторите замер с другого подключения: нужна доказательная картина за несколько минут, а не один «пинг».

Проблема на стороне сервиса. Все промежуточные хопы чистые, а последний теряет пакеты. Проверьте TCP-портом: если mtr -T -P 443 показывает потери, а ICMP-вариант — нет, дело может быть в фильтре или перегрузке сервиса, а не в маршруте.

Плавающая проблема. Запускайте тест на 200 циклов и сопоставляйте всплески с временем. Для MTU используйте tracepath: он покажет, где перестают проходить крупные пакеты. Проверка ping -M do -s 1472 до шлюза и внешнего узла покажет, не режет ли путь пакеты из-за туннеля или PPPoE.

ping -c 20 -i 0.2 192.168.1.1
ip -s link show wlan0
sudo mtr -rwzc 200 -i 1 example.com
ping -M do -s 1472 -c 3 example.com

Отчёт и повторяемость

Провайдеру или администратору сервиса нужен воспроизводимый отчёт. Запускайте mtr с --no-dns и сохраняйте вывод в файл вместе с временем замера. Полезно приложить ip route get до проблемного адреса: он покажет, через какой интерфейс и шлюз реально уходит трафик. При нескольких маршрутах или туннельных интерфейсах это сразу объясняет странные результаты.

sudo mtr -rwzc 100 --no-dns example.com
sudo mtr -rwzc 100 --no-dns 203.0.113.10
date -u +%Y-%m-%dT%H:%M:%SZ
ip route get 203.0.113.10

Сравнивайте замеры с двух точек: из своей сети и с внешнего сервера. Если из дома потери есть, а с сервера в дата-центре нет, проблема почти наверняка на локальном или провайдерском участке. Обратная трассировка покажет, совпадает ли путь туда и обратно.

sudo tcpdump -ni any host 203.0.113.10
sudo mtr -rwzc 60 --no-dns example.com

Ограничения и ошибки толкования

Трассировка не измеряет пропускную способность. Она также не видит внутреннюю структуру операторской сети: MPLS-метки, туннели и коммутаторы скрыты, поэтому «дырка» между хопами может быть нормальной. Геолокация IP приблизительна, а anycast-адреса вообще могут обслуживаться в другом городе, чем показывает база.

Не отправляйте сотни проб в чужую сеть без необходимости: это создаёт нагрузку и может быть воспринято как сканирование. Для рабочей диагностики достаточно одного-двух пакетов в секунду. И помните, что фильтрация ICMP — обычная практика, а не доказательство поломки.

traceroute -I -n example.com
traceroute -T -p 80 -n example.com
sudo mtr -u -rwzc 30 example.com
ss -tin dst 203.0.113.10

Чек-лист диагностики

• Зафиксируйте время, источник, имя и IP-адрес получателя.
• Сравните ICMP, UDP и TCP-пробы на реальный порт сервиса.
• Проверьте первый хоп, ошибки интерфейса и качество Wi-Fi.
• Ищите потери, которые начинаются на хопе и сохраняются дальше.
• Запустите не менее 100 циклов mtr, а для плавающих сбоев — больше.
• Проверьте MTU и путь до шлюза, особенно при туннелях.
• Сделайте замер с другой сети и, по возможности, в обратном направлении.
• Сохраните отчёт и сопоставьте его с метриками приложения.

Итог

traceroute отвечает на вопрос «каким путём идут пакеты», а mtr — «где этот путь стабильно портится». Рабочая схема проста: сначала TCP-трассировка до нужного порта, затем длинный отчёт mtr, проверка первого хопа, MTU и обратного направления. Не принимайте одиночную потерю на промежуточном маршрутизаторе за аварию и всегда отделяйте фильтрацию ICMP от реальной деградации.