Пакеты теряются — но где именно: как локализовать участок между вами и сервером

MAATRIX

Пинг до сервера скачет, видео в звонках рассыпается, RDP подвисает — и первый порыв - открыть traceroute и найти виноватый хоп. Но необученным глазом легко указать пальцем не туда: строка с 100% Loss посередине пути почти всегда означает не потерю ваших данных, а то, что конкретный роутер не любит отвечать на ICMP. Разберём, как читать traceroute и mtr правильно и по итогам замера понять, кому писать — своему провайдеру, хостеру или в поддержку транзитной сети.

Как traceroute находит путь пакета: принцип TTL и его пределы

Traceroute (в Linux и macOS) и tracert (в Windows) не умеют напрямую спросить у сети «покажи мне список роутеров по дороге». Вместо этого они используют побочный эффект поля TTL (Time To Live) в заголовке IP-пакета.

Механика простая: утилита отправляет пакет с TTL=1. Первый же роутер на пути уменьшает TTL до 0 и не имеет права пересылать пакет дальше — вместо этого он обязан вернуть ICMP-сообщение Time Exceeded, засветив свой IP. Так утилита узнаёт первый хоп. Дальше она шлёт пакет с TTL=2, TTL=3 и так далее, пока пакет наконец не долетит до цели, которая ответит уже не Time Exceeded, а обычным ICMP Echo Reply (ping-based traceroute) или отказом порта (UDP-based).

# Linux/macOS — по умолчанию UDP-пакеты на случайный высокий порт
traceroute -n 8.8.8.8

# Windows — по умолчанию ICMP Echo
tracert -d 8.8.8.8

Флаг -n (и -d в Windows) отключает обратный DNS-резолвинг каждого IP — без него трасса выполняется в разы дольше, потому что утилита ждёт ответа DNS на каждый хоп, который часто просто не резолвится.

Здесь и начинаются ограничения метода. Traceroute показывает путь только в один момент времени — один пакет на TTL, в лучшем случае три. Он ничего не говорит о стабильности маршрута: если между замерами маршрут перестроился (а BGP делает это в любой момент из-за перегрузки, аварии или более выгодного пути у промежуточной сети), два последовательных traceroute покажут разные хопы, и по одному прогону не понять, типично это или разовая аномалия. Второе и более важное ограничение — то, чем меряет traceroute (ICMP или UDP/TCP-пробники), часто обрабатывается роутерами совсем не так, как обычный транзитный трафик. Об этом — следующий раздел, и именно тут чаще всего ошибаются при интерпретации.

Почему ICMP-потери на traceroute — это не всегда потери трафика

Ключевая вещь, которую нужно понять один раз и больше не путать: пакет Time Exceeded, который генерирует роутер в ответ на traceroute, — это не тот же трафик, который роутер обычно форвардит. Форвардинг обычного пакета — быстрая операция на выделенном сетевом процессоре (ASIC), на скорости линии. А генерация ICMP-ответа с TTL=0 — операция на управляющей плоскости (control plane), которая на многих магистральных роутерах идёт через куда более медленный общий процессор.

Практический эффект: операторы сетей сознательно ограничивают скорость генерации таких служебных ICMP-ответов (rate limiting) — чтобы шторм traceroute-запросов от миллионов пользователей интернета не положил управляющий процессор дорогого магистрального маршрутизатора. Из-за этого промежуточный хоп может:

• вообще не отвечать на ICMP TTL-exceeded по политике оператора (тогда вы видите * * * на всех замерах для этого хопа стабильно);
• отвечать с ограничением скорости, то есть терять часть именно служебных ответов, а не транзитных пакетов (тогда на этом хопе появляется частичный Loss%, который выглядит как проблема);
• отвечать с заметно большей задержкой, чем реально требуется для форвардинга пакета дальше (потому что генерация ICMP-ответа стоит в очереди с более низким приоритетом, чем сам форвардинг).

Отсюда правило: сам факт, что промежуточный хоп не отвечает или отвечает с потерями на traceroute/mtr, ничего не говорит о том, как этот же роутер обрабатывает ваш реальный трафик. Он может идеально, без единой потери, форвардить TCP-соединения через себя и при этом демонстрировать 30-50% Loss% в mtr — просто потому, что генерация диагностических ответов не в приоритете у его control plane. Единственный хоп, чьи потери имеет смысл трактовать буквально, — это последняя строка трассы, то есть сама цель: тут уже нет промежуточного оператора, который экономит на служебных ответах.

mtr: статистика по каждому хопу вместо одного снимка

Traceroute даёт один снимок в момент запуска. Проблема в том, что перемежающиеся (intermittent) потери — самый частый и самый неприятный на практике случай — вообще невозможно поймать одним пакетом на хоп. Здесь на помощь приходит mtr (My TraceRoute, также встречается под именем mtr-tiny/WinMTR на Windows) — утилита, которая объединяет логику traceroute с логикой ping: она непрерывно шлёт пробники по всем хопам маршрута и накапливает статистику по потерям, задержке и джиттеру для каждого из них.

# интерактивный режим — колонки обновляются в реальном времени
mtr 8.8.8.8

# неинтерактивный отчёт на 100 пакетов, с резолвингом (-r), без DNS (-n), в широком формате (-w)
mtr -rwnc 100 8.8.8.8

                                     Packets               Pings
Host                               Loss%   Snt   Last   Avg  Best  Wrst
1. 192.168.1.1                      0.0%   100    0.4   0.5   0.3   1.2
2. 100.64.0.1                       0.0%   100    2.1   2.3   1.9   5.4
3. (waiting for reply)             15.0%   100    -     -     -     -
4. core-router.example.net          0.0%   100   12.4  12.8  11.9  18.2
5. target.example.com               0.0%   100   14.1  14.6  13.8  22.0

На Windows аналог — WinMTR (графический) или встроенный pathping: тоже сначала строит трассу как traceroute, потом гоняет пробники по каждому хопу и выдаёт процент потерь по каждому из них, только статистику собирает дольше (порядка 25 секунд на хоп).

Полезные флаги mtr: -c N — число циклов (100 для разовой проверки, 300-1000 для ловли редких потерь); -i N — интервал между пакетами в секундах; -T (и -P 443 к нему) — использовать TCP SYN на нужный порт вместо ICMP, если ICMP режется файрволом по пути, а TCP-трафик на 443 проходит; --report — вывести финальный отчёт и выйти, удобно для логов.

Главная ошибка: «хоп теряет пакеты» vs «хоп просто не отвечает на ICMP»

Самая частая ошибка при чтении вывода mtr — увидеть Loss% на промежуточной строке и сразу написать в поддержку хостера «у вас сеть роняет 40% пакетов». В подавляющем большинстве случаев это не так. Признаки, которые помогают отличить настоящую проблему от диагностического шума:

Это почти наверняка ложная потеря (rate limiting на ICMP), если:

• потери есть только на одном-двух промежуточных хопах, а на всех хопах после них потерь нет или они минимальны;
• уровень потерь на этом хопе стабилен и повторяется от замера к замеру (например, всегда около 20%);
• задержка (Avg) на этом хопе не выбивается из общей картины;
• на последней строке (цель) потерь нет вообще или они на порядок меньше.

Это стоит воспринимать всерьёз, если:

• потери на конкретном хопе накапливаются и сохраняются на всех последующих хопах вплоть до цели — если хоп №5 потерял 20%, а хоп №6 и далее показывают столько же или больше, это похоже на реальную потерю трафика, которая "тащится" дальше по маршруту;
• потери есть непосредственно на последней строке — на самой цели;
• потери сопровождаются резким и нестабильным ростом задержки и джиттера, а не просто пропуском ответов;
• симптом воспроизводится не только в mtr, но и в реальном поведении приложения — обрывы звонков, ретраи TCP, таймауты (см. разбор того, как потеря пакетов может быть не видна в обычном ping, но при этом бить по TCP-сессиям).

Проверочное правило: если хоп N теряет пакеты, а хоп N+1 и все последующие — нет, то хоп N в порядке, просто экономит на ICMP. А вот если потеря на хопе N "переносится" на все хопы после него — это сигнал, что реальный трафик действительно теряется на этом участке.

Своя сеть, транзит или сервер — как разделить зоны ответственности

Когда вы убедились, что потеря реальная (а не артефакт ICMP-лимитов), следующий шаг — понять, на чьей стороне участок. Условно маршрут делится на три зоны, и ответственность за каждую лежит на разных людях.

Про то, почему маршрут вообще может идти не туда, куда подсказывает география, и почему это само по себе не проблема, — отдельный разбор в статье про маршрутизацию против географии. Здесь же важно другое: middle-хопы в mtr часто принадлежат сетям, с которыми у вас нет никакого договора и о проблеме можно сообщить только опосредованно — через своего провайдера или через провайдера сервера, у которых уже есть коммерческие отношения с этим транзитным оператором. Прямого «билета в поддержку» у стороннего пирингового узла для рядового пользователя обычно нет.

Отдельно про домашнюю сеть: прежде чем винить интернет, исключите Wi-Fi. Нестабильный сигнал, помехи от соседних сетей на том же канале, перегруженный роутер с десятками устройств — всё это создаёт потери и джиттер, которые выглядят один в один как проблема в глубине сети, но не покидают пределы вашей квартиры. Быстрая проверка — подключиться кабелем в обход Wi-Fi и повторить замер.

План действий: mtr с двух сторон, симметрия и куда писать о проблеме

Самая надёжная диагностика — не один traceroute с вашей стороны, а параллельный запуск mtr с обоих концов одновременно: с клиента до сервера и с сервера до клиента (если у вас есть на него SSH-доступ). Путь туда и обратно в интернете формируется независимо — маршрутизаторы каждой сети выбирают следующий хоп по своим правилам, и путь «туда» совершенно не обязан совпадать с путём «обратно». Подробно, почему так происходит и чем это может быть опасно (в первую очередь для stateful firewall и балансировщиков), разобрано в статье про асимметричный маршрут.

Практический план:

1. Зафиксируйте симптом в конкретных цифрах. Не «интернет плохой», а «пинг до сервера X.X.X.X скачет с 20 до 300 мс каждые несколько минут» или «в видеозвонках пакеты теряются с 19:00 до 21:00 по будням». Без конкретики поддержка любой стороны попросит именно это, и вы потеряете день на переписку.

1. Запустите mtr -rwnc 300 (или больше) одновременно с двух сторон. С клиента — до сервера, с сервера — до клиентского IP (для динамического IP из дома можно взять любой стабильный адрес того же провайдера как ориентир). Держите оба замера параллельно хотя бы 10-15 минут, а лучше — захватите время, когда симптом обычно проявляется.

1. Сравните симметрию. Если оба направления показывают чистую трассу без потерь, а проблема тем не менее есть — скорее всего, дело не в сети, а в приложении, самом сервере (перегрузка CPU, недостаток буферов на сетевой карте) либо в MTU/фрагментации. Если потери воспроизводятся стабильно в одном направлении на одном участке — у вас есть конкретный хоп и направление, с которыми идти в поддержку.

1. Определите зону по таблице из предыдущего раздела и пишите именно туда: проблема в первых хопах — своему интернет-провайдеру (или чинить Wi-Fi самому); проблема в середине трассы, на транзитном участке — своему провайдеру и/или в поддержку хостинга сервера, у которых есть контакты с апстримами и возможность эскалировать проблему через NOC транзитного оператора; проблема на последних хопах или на самом сервере — напрямую в hosting support. В любом случае прикладывайте оба mtr-отчёта текстом (не скриншотом) и точное время симптома.

1. Держите замеры под рукой, а не полагайтесь на память. Логируйте вывод в файл (mtr --report --report-cycles 300 target > mtr-log.txt) и повторяйте через равные интервалы, если проблема периодическая — так у вас на руках будет не «мне показалось», а воспроизводимая история.

Отдельно предупреждение: если вы тестируете через VPN, вся картина искажается. Traceroute и mtr увидят в первую очередь путь до VPN-сервера, а не до реальной цели, число хопов и задержка изменятся закономерно и не будут отражать «настоящий» маршрут вашего трафика без туннеля. Прежде чем локализовывать потери, отключите VPN и повторите замер напрямую — либо, если VPN отключить нельзя, явно разделяйте два участка: сначала меряйте до самого VPN-сервера, потом — из-за VPN-сервера до конечной цели. Подробный разбор того, что в traceroute через туннель нормально, а что нет, есть в статье про traceroute и ping через VPN.

Частые вопросы