Диагностика сетевой маршрутизации: Практическое руководство с traceroute, mtr и ip route

Проблемы с доступностью сервисов, падение скорости VPN или обрывы трафика между подсетями — типичные сценарии, с которыми ежедневно сталкиваются системные администраторы и DevOps-инженеры. Часто корень этих проблем лежит не в самом приложении, а в сетевой маршрутизации. В этой статье вы получите четкий, пошаговый алгоритм диагностики, основанный на проверенных на практике инструментах: traceroute, mtr, ip route и netstat. Вы научитесь не просто запускать команды, а интерпретировать их вывод, находить точку обрыва, анализировать таблицы маршрутизации и решать специфичные проблемы, такие как асимметричная маршрутизация после развертывания VPN или неправильный MTU, влияющий на стабильность соединения.

Когда и какие инструменты использовать для диагностики маршрутизации

Правильный выбор инструмента экономит время. Ниже — краткая шпаргалка, которая поможет сразу приступить к решению проблемы, а не к поиску нужной утилиты.

Traceroute vs MTR: в чем разница и когда что выбирать

Обе утилиты показывают путь пакетов от источника к цели, но делают это по-разному.

Traceroute делает один «снимок» пути. Это идеально для быстрой проверки доступности удаленного порта или первоначальной оценки маршрута. Например, команда traceroute -T -p 443 example.com покажет путь до HTTPS-сервиса, используя TCP-пакеты.
MTR (My TraceRoute) работает в режиме непрерывного опроса, собирая статистику по потерям пакетов и задержкам на каждом сетевом узле (хопе). Это ключевой инструмент для диагностики плавающих проблем. Если VPN-соединение периодически обрывается, запустите mtr --report example.com на несколько минут — вы сразу увидите, на каком хопе происходят потери пакетов.

Кратко: используйте traceroute для разовой проверки, а mtr — для поиска периодических сбоев и сбора статистики.

Анализ локальной таблицы маршрутизации: ip route против netstat

Прежде чем пакет покинет сервер, система решает, через какой интерфейс и шлюз его отправить. Это решение принимается на основе локальной таблицы маршрутизации.

ip route show — современная команда из пакета iproute2. Она предоставляет наиболее полную и структурированную информацию.
netstat -rn — устаревшая, но до сих пор распространенная команда. Её стоит знать, так как она может быть единственным доступным вариантом на некоторых legacy-системах.

Ключевые элементы вывода: маршрут по умолчанию (default via 192.168.1.1), маршруты к конкретным подсетям и метрика (чем она меньше, тем выше приоритет маршрута). Практический пример: после поднятия VPN-туннеля может появиться конфликтующий маршрут с более высокой метрикой, чем основной шлюз, что приведет к асимметричной маршрутизации.

Пошаговая диагностика: от симптома к причине

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

Сценарий 1: Сервис в определенной подсети недоступен

Проверка локального маршрута: Узнайте, куда система отправит пакет. ip route get 10.0.1.5 покажет используемый интерфейс и шлюз для адреса 10.0.1.5.
Проверка доступности шлюза: Убедитесь, что шлюз, указанный в маршруте, жив. ping -c 3 192.168.1.1 (или соответствующий адрес).
Поиск обрыва на пути: Запустите traceroute 10.0.1.5. Обрыв будет виден как ряд звездочек (*) или сообщение о недоступности на определенном хопе.
Проверка обратного пути: Помните, что маршрутизация может быть асимметричной. Запустите аналогичную проверку с сервера в целевой подсети к вашему хосту, если это возможно.

Сценарий 2: Падение скорости или обрывы после развертывания VPN

Этот сценарий сложнее, так как добавляются факторы шифрования, туннелирования и возможной блокировки. Используйте данные из практики: например, известно, что протокол OpenVPN блокируется в 90% случаев, а для стабильного 4K-видео требуется скорость от 50 Mbps.

Проверка утечки DNS: Это критично для безопасности и доступности. Используйте специализированные онлайн-сервисы (например, dnsleaktest.com) для проверки, не «протекают» ли ваши DNS-запросы мимо VPN-туннеля.
Диагностика MTU: Неправильный MTU — частая причина обрывов SSH-сессий и падения скорости при передаче больших файлов. Для проверки используйте ping с флагом запрета фрагментации: ping -M do -s 1472 8.8.8.8. Если пакет размером 1472 байта (1500 - 20 IP - 8 ICMP) не проходит, уменьшайте значение -s до успешного прохождения. Итоговый MTU = успешный размер + 28.
Анализ асимметричной маршрутизации: Сравните вывод traceroute с вашего клиента до сервера и обратно. Если пути отличаются, это может вызывать проблемы с stateful firewall. Используйте mtr для наблюдения за потерей пакетов в каждом направлении.
Рекомендация по протоколам: Если используете легко блокируемые протоколы (например, OpenVPN), рассмотрите переход на более устойчивые решения, такие как WireGuard или VLESS-Reality, которые сложнее обнаружить и заблокировать.

Для глубокой диагностики сетевых проблем в контейнерных средах, таких как Docker, рекомендуем ознакомиться с нашим практическим руководством по устранению сетевых проблем Docker, где разбираются конфликты с iptables, драйверы сетей и анализ логов.

Как читать вывод команд: расшифровка звездочек, потерь и маршрутов

Запустить команду — полдела. Главное — правильно понять, что она сообщает.

Расшифровка вывода traceroute и mtr: от звездочек до задержек

Звездочки (*): Означают, что ответ на пробный пакет не был получен. Причины: пакет потерян на этом участке, промежуточный маршрутизатор фильтрует ICMP-пакеты (или UDP/TCP, в зависимости от типа traceroute), либо превышено время ожидания.
Коды ошибок (в traceroute):
- !H — хост недоступен.
- !N — сеть недоступна.
- !P — протокол недоступен.
- !X — связь административно запрещена (например, firewall).
Колонки в MTR: Обращайте внимание на Loss% (процент потерь). Потеря 1-2% на одном из промежуточных хопов может быть нормой, но 10% и более, особенно на последних хопах, — явная проблема. Avg (средняя задержка) и разброс между Best и Worst (джиттер) критичны для VoIP и видеоконференций.

Анализ таблицы маршрутизации: на что смотреть в первую очередь

При анализе вывода ip route show или netstat -rn:

Ищите дублирующиеся маршруты: Два маршрута к одной сети/хосту с разными шлюзами или интерфейсами. Работать будет тот, у которого меньше метрика (поле metric).
Проверяйте достижимость шлюза: Маршрут default via 192.168.100.254 dev eth0 бесполезен, если адрес 192.168.100.254 не отвечает на ping.
Анализируйте метрики: Приоритет имеют маршруты с меньшей метрикой. VPN-туннель (например, dev tun0) часто добавляет маршрут с высокой метрикой, который игнорируется в пользу основного шлюза, что приводит к утечке трафика.
Особые интерфейсы: Маршруты через tun (VPN), docker0 или br- (мосты Docker) указывают на туннелированный или изолированный трафик. Убедитесь, что они не конфликтуют с физическими маршрутами.

Для работы с пользовательскими сетями в Docker и управления их маршрутизацией может быть полезно наше руководство по настройке пользовательской Docker bridge-сети.

Продвинутые сценарии: диагностика проблем с MTU и асимметричной маршрутизацией

Когда базовые проверки не выявили проблем, стоит углубиться в более сложные аспекты.

Выявление и решение проблем с MTU (Maximum Transmission Unit)

MTU — максимальный размер кадра, который может быть передан через сетевой интерфейс без фрагментации. В VPN-туннелях из-за добавления заголовков инкапсуляции эффективный MTU уменьшается.

Симптомы: SSH-сессии обрываются при активном вводе, загрузка больших файлов через VPN падает или останавливается, не работают некоторые сайты.
Диагностика: Используйте ping с запретом фрагментации, как описано выше, или специализированную утилиту tracepath -n <цель>, которая сама определит предельный MTU на пути.
Решение:
1. Уменьшить MTU на интерфейсе VPN-клиента (например, ip link set dev tun0 mtu 1400).
2. Настроить MSS Clamping на VPN-шлюзе (например, в iptables: -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360). Это «подскажет» TCP-соединениям использовать меньший размер сегмента.

Асимметричная маршрутизация, когда пакеты до цели идут одним путем, а ответные — другим, часто возникает в сетях с множественными выходами или после настройки VPN. Это может вызывать сбои в работе stateful firewall (например, Netfilter в Linux), который ожидает, что ответный трафик придет на тот же интерфейс. Диагностируется сравнением трассировок в обоих направлениях.

Верификация исправления: как убедиться, что проблема решена

После внесения изменений (настройки MTU, правки маршрутов, смены протокола VPN) необходимо убедиться в их эффективности.

Повторный запуск MTR: Запустите mtr --report <цель> на 50-100 циклов. Убедитесь, что процент потерь (Loss%) на проблемных хопах упал до приемлемого уровня (0-1%).
Проверка выбора пути: Команда ip route get <адрес_цели> должна теперь показывать правильный интерфейс и шлюз.
Тест на передачу данных: Для проверки MTU выполните передачу файла большого объема (например, wget http://speedtest.tele2.net/100MB.zip) или запустите длительную SSH-сессию с активным трафиком. Отсутствие обрывов — хороший знак.
Кратковременный мониторинг: Оставьте mtr работать в фоне на 5-10 минут, наблюдая за стабильностью задержек и отсутствием всплесков потерь.

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