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

Проблемы с доступностью сервисов, падение скорости VPN или обрывы трафика между подсетями — типичные сценарии, с которыми ежедневно сталкиваются системные администраторы и DevOps-инженеры. Часто корень этих проблем лежит не в самом приложении, а в сетевой маршрутизации. Статья решает конкретные сетевые неполадки, включая сложные случаи в гибридных облаках, BGP-сетях и контейнерных средах:

• VPN обрывается или медленно работает
• Сервис в подсети недоступен
• SSH-сессии нестабильны
• Непонятно, куда уходит трафик
• Проблемы маршрутизации в Kubernetes (Calico, Cilium)
• Black hole маршрутизаторы в BGP-сетях
• Асимметричная маршрутизация в гибридных облачных средах

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

Памятка: 5 шагов при любой проблеме с маршрутизацией

1. Определите цель: Уточните IP-адрес или домен проблемного сервиса.
2. Проверьте локальный маршрут: Выполните ip route get <цель>.
3. Найдите узкое место: Запустите mtr --report <цель> для сбора статистики по потерям и задержкам.
4. Проверьте обратный путь: По возможности, выполните трассировку с целевого хоста обратно.
5. Верифицируйте исправление: После изменений повторите шаги 2-4 и проведите нагрузочный тест.

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

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

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.
2. Проверка доступности шлюза: Убедитесь, что шлюз, указанный в маршруте, жив. ping -c 3 192.168.1.1 (или соответствующий адрес).
3. Поиск обрыва на пути: Запустите traceroute 10.0.1.5. Обрыв будет виден как ряд звездочек (*) или сообщение о недоступности на определенном хопе.
4. Проверка обратного пути: Помните, что маршрутизация может быть асимметричной. Запустите аналогичную проверку с сервера в целевой подсети к вашему хосту, если это возможно.

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

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

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

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

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

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

Как читать вывод 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:

1. Ищите дублирующиеся маршруты: Два маршрута к одной сети/хосту с разными шлюзами или интерфейсами. Работать будет тот, у которого меньше метрика (поле metric).
2. Проверяйте достижимость шлюза: Маршрут default via 192.168.100.254 dev eth0 бесполезен, если адрес 192.168.100.254 не отвечает на ping.
3. Анализируйте метрики: Приоритет имеют маршруты с меньшей метрикой. VPN-туннель (например, dev tun0) часто добавляет маршрут с высокой метрикой, который игнорируется в пользу основного шлюза, что приводит к утечке трафика.
4. Особые интерфейсы: Маршруты через 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), который ожидает, что ответный трафик придет на тот же интерфейс. Диагностируется сравнением трассировок в обоих направлениях.

Сложные кейсы и типовые ошибки конфигурации для опытных администраторов

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

Диагностика асимметричной маршрутизации в гибридном облаке (AWS VPC + On-premise через IPSec)

При интеграции локальной сети с облаком VPC через IPSec VPN часто возникают проблемы с асимметричной маршрутизацией и MTU.

• Проблема: Трафик из VPC в локальную сеть идет через VPN-туннель, а ответный трафик возвращается через прямой интернет-канал (из-за более приоритетного default route в локальной сети).
• Диагностика: Сравните traceroute из инстанса в VPC к локальному серверу и обратно. Используйте ip route get на обеих сторонах, чтобы увидеть выбранные интерфейсы.
• Решение: Настройка Policy-Based Routing (PBR) на локальном шлюзе, чтобы трафик от локальных серверов к подсетям VPC направлялся через VPN-туннель. Используйте iproute2 с таблицами маршрутизации и правилами.

Как найти black hole маршрутизатор в BGP-сети

Black hole (черная дыра) — маршрутизатор, который принимает трафик, но не пересылает его дальше, не уведомляя отправителя.

• Признаки: В выводе mtr видна 100% потеря пакетов на определенном хопе, при этом последующие хопы могут быть недоступны. Пинг до IP этого хопа может работать, но трафик через него — нет.
• Диагностика: Используйте traceroute с разными протоколами (ICMP, UDP, TCP) до одного адреса. Если хоп отвечает на ICMP echo-request, но фильтрует трассировочные пакеты других типов, это может указывать на конфигурацию ACL или политику маршрутизации.
• Что проверить: На маршрутизаторе-кандидате проверьте таблицу BGP (show ip bgp на Cisco), наличие маршрута к целевой сети и состояние интерфейсов.

Анализ проблем маршрутизации в Kubernetes (Calico/Cilium)

В контейнерных сетях Kubernetes маршрутизация часто реализуется через overlay-сети (VXLAN, IP-in-IP) или L3-маршрутизацию (BGP).

• Проблема: Pod в одном узле не может связаться с Pod в другом узле.
• Диагностика:
  1. Проверьте маршруты на хостах: ip route show. Для Calico/Cilium с BGP должны быть маршруты к подсетям Pod других узлов через IP этих узлов.
  2. Выполните трассировку с IP Pod-источника до IP Pod-цели. Используйте kubectl debug для запуска отладочного контейнера с сетевыми утилитами.
  3. Проверьте политики сети (NetworkPolicy), которые могут блокировать трафик.
• Типовая ошибка: Отсутствие маршрута на одном из узлов из-за сбоя демона BGP (bird) или проблемы с аннотациями узла.

Таблица типовых значений MTU для разных сред

Типовые ошибки конфигурации и их признаки в выводе команд

• Дублирование default gateway: В выводе ip route show видны два или более маршрута default via ... с разными шлюзами. Работает маршрут с меньшей метрикой, что может привести к непредсказуемой маршрутизации.
• Фильтрация ICMP vs реальная потеря пакетов: В mtr постоянные звездочки (*) на одном хопе при нулевых потерях на следующих хопах часто указывают на фильтрацию ICMP-пакетов (например, iptables -A INPUT -p icmp -j DROP) на этом маршрутизаторе, а не на реальную потерю данных.
• Неправильный reverse path filtering (rp_filter): В логах ядра (dmesg | grep martian) появляются сообщения типа "martian source ...". Это означает, что пакет пришел на интерфейс, который не является предпочтительным для обратного пути к источнику. Лечится настройкой sysctl -w net.ipv4.conf.all.rp_filter=0 (или 2 для loose mode) или исправлением таблиц маршрутизации.
• Признаки асимметричной маршрутизации для stateful firewall: В логах iptables/nftables (journalctl -k -g DROP) появляются записи о сбросе пакетов с состоянием INVALID, так как firewall не нашел соответствующего соединения в таблице состояний для интерфейса, на который пришел ответный трафик.

Скрипт для автоматического подбора оптимального MTU

#!/bin/bash
# Автоматический подбор MTU для указанного хоста
TARGET_HOST="8.8.8.8"

for SIZE in {1472..500..-8}; do
    echo -n "Testing MTU $((SIZE + 28)): "
    if ping -M do -c 2 -s $SIZE $TARGET_HOST &> /dev/null; then
        echo "SUCCESS"
        echo "Optimal MTU for path to $TARGET_HOST is $((SIZE + 28))"
        break
    else
        echo "FAILED"
    fi
done

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

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

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

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