Потеря трафика в продакшене почти всегда объясняется одной из пяти причин: интерфейс выключен или остался без IP-адреса, в таблице маршрутов нет нужной записи, ядро выбрало не тот маршрут из-за метрики или правил policy routing, пакет отбросил фильтр, сбой произошёл на промежуточном узле или на обратном пути. Проверять их нужно в этом порядке, от локальной конфигурации к внешней сети.
Первые три команды занимают меньше минуты и закрывают большую часть ошибок: ip -br addr, ip route show и ip route get для адреса назначения. Если они дают корректную картину, переходите к ping, traceroute или mtr, и только после этого к tcpdump. Обратный порядок приводит к типичной тупиковой ситуации: дамп пустой, а причина в том, что маршрут по умолчанию просто не настроен.
Методика ниже рассчитана на Linux: утилиты ip, ping, traceroute, mtr и tcpdump входят в стандартные репозитории популярных дистрибутивов. В других системах синтаксис отличается, логика проверок остаётся прежней.
Почему трафик не доходит: базовые причины и первые шаги
Классификация причин помогает не распылять внимание. Сбой конфигурации на самой машине: интерфейс в состоянии DOWN, отсутствует адрес, нет записи для сети назначения. Сбой выбора маршрута: несколько default-маршрутов с разными метриками, правила ip rule, отдельные таблицы маршрутизации, VRF. Фильтрация: nftables или iptables на обоих концах, rp_filter, security groups в облаке. Сеть между хостами: потери на канале, асимметричный обратный путь, MTU. Отдельная категория, которую часто путают с маршрутизацией, это DNS и порты приложений: имя разрешается в один адрес, а сервис слушает другой.
Практический старт одинаков для любого инцидента. Выполните ip a, затем ip r, затем ip route get с адресом цели. Такой набор отделяет ошибку конфигурации от сетевой проблемы до того, как вы потратите время на анализ пакетов.
Проверка интерфейсов и IP-адресов
Состояние линков и адресов показывают команды ip link show и ip addr show, краткая форма: ip -br link и ip -br addr. В выводе важны флаги UP и LOWER_UP: первый означает, что административно интерфейс включён, второй подтверждает наличие сигнала на физическом или виртуальном уровне. Строка state DOWN или NO-CARRIER говорит о проблеме драйвера, кабеля, vlan или виртуального коммутатора, и маршрутизация здесь ни при чём.
Если адрес отсутствует, проверьте, как настроено его получение: dhclient, netplan, NetworkManager или systemd-networkd. Частая ошибка в лабораторных и облачных окружениях: адрес выдан, но с маской /32 и без шлюза по умолчанию, поэтому локальная сеть недоступна, хотя интерфейс поднят.
Счётчики интерфейсов дают быстрый ответ на вопрос, есть ли физические потери. Команда ip -s link show eth0 выводит RX и TX с колонками errors, dropped, overruns, carrier, collsns. Растущие RX errors и RX dropped указывают на проблемы канала или переполнение очереди приёма, TX dropped часто связаны с работой qdisc. Для аппаратных счётчиков используйте ethtool -S eth0: там видны ошибки уровня драйвера, которые не попадают в статистику ядра.
В контейнерах и сетевых пространствах имён проверяйте интерфейсы внутри нужного namespace: ip netns exec myns ip addr show или ip netns exec myns ip route show. Команды, выполненные на хосте, не увидят маршруты контейнера: у него своя таблица и свои адреса.
Просмотр таблицы маршрутов
Команда ip route show, краткая форма ip r, выводит решения ядра. Типичный вывод выглядит так: default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100, затем 10.20.0.0/16 via 192.168.1.1 dev eth0 metric 100, затем 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100. Поля читаются так: default обозначает маршрут по умолчанию, via задаёт next hop, dev указывает исходящий интерфейс, scope link означает прямо подключённую сеть без шлюза, metric задаёт приоритет, и меньшее значение выигрывает при нескольких кандидатах.
Отсутствие маршрута по умолчанию даёт характерный симптом: узлы своей подсети пингуются, внешние адреса недоступны. Проверить это можно командой ip route show default. Временно маршрут добавляют так: ip route add default via 192.168.1.1 dev eth0. Правки в ядре сбрасываются при перезапуске сети или перезагрузке, поэтому постоянную настройку делают средствами дистрибутива.
Когда в системе несколько таблиц, смотрите ip rule show и содержимое отдельных таблиц: ip route show table 100. Имена таблиц перечислены в файле /etc/iproute2/rt_tables. Классический сценарий: VPN добавляет правило для конкретных подсетей, и трафик уходит в туннель, хотя ожидался выход через основной шлюз.
Утилита route -n из пакета net-tools выводит те же данные в другом формате, но она устарела и на части новых дистрибутивов отсутствует по умолчанию. Ориентируйтесь на iproute2. Расширенный чек-лист по диагностике сетевых сбоев дополняет этот разбор проверками ARP и правил firewall.
Как проверить, какой маршрут выберет система: ip route get
Команда ip route get 8.8.8.8 показывает решение ядра для конкретного адреса, включая результат работы policy routing. Пример вывода: 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 0. Поля означают: via это next hop, dev это исходящий интерфейс, src это адрес источника, который ядро подставит в пакет.
Синтаксис позволяет уточнить условия выбора: ip route get 10.0.0.1 from 192.168.2.100 iif eth1 проверяет маршрут при заданном адресе источника и входном интерфейсе. Такой вариант нужен, когда трафик приходит на другой интерфейс и ответ должен уйти через исходный путь.
Два ответа стоит трактовать отдельно. Строка вида local 8.8.8.8 dev lo означает, что адрес принадлежит самой машине. Сообщение Network is unreachable говорит об отсутствии подходящего маршрута, и это уже готовая причина инцидента без дальнейших проверок.
Асимметричную маршрутизацию выявляют сравнением двух запросов: ip route get для адреса назначения и ip route get для адреса источника пакетов. Если запрос уходит через eth0, а обратный трафик по таблицам пойдёт через eth1, ответные пакеты может отбросить строгий режим rp_filter или сбить состояние в conntrack. Разбор black hole в BGP, проблем MTU в туннелях и асимметрии в облачных VPC показывает, как такие ситуации выглядят в реальных схемах.
В разных версиях iproute2 вывод немного отличается: в старых сборках в конце строки печаталось слово cache, в новых оно убрано, а при работе с VRF добавляются соответствующие поля. Сверяйтесь с man ip-route на целевой машине, если формат не совпадает с примером.
Диагностика с ping: проверка доступности и потерь
ping проверяет доступность узла на третьем уровне модели OSI. Базовая проверка: ping -c 4 8.8.8.8. Ключ -c ограничивает число пакетов, -W задаёт таймаут ожидания ответа в секундах. Привязка к интерфейсу и адресу источника выполняется ключом -I: ping -I eth0 8.8.8.8 или ping -I 192.168.1.100 8.8.8.8. Такой вариант проверяет конкретный маршрут, когда в системе несколько интерфейсов.
Интерпретация результата. Полные 0% потерь при стабильном времени отклика означают, что L3-связность есть. Потери 100% возможны в четырёх случаях: узел выключен, ICMP заблокирован фильтром, шлюз не знает маршрут до цели, обратный путь потерян. Частичные потери вместе с ростом времени отклика обычно указывают на перегруженный канал или ошибки на физике.
Полезная подсказка приходит в тексте ошибки. Сообщение Destination Host Unreachable от промежуточного адреса означает, что маршрутизатор не смог найти путь и прислал ICMP-ответ. Ответ с другого адреса, не совпадающего с целью, часто говорит о NAT или о балансировщике на пути.
Отсутствие ответа на ICMP не доказывает проблему маршрутизации: часть узлов и облачных платформ по умолчанию игнорирует эхо-запросы, при этом TCP-порты отвечают нормально. Проверку MTU удобно делать тем же инструментом: ping -M do -s 1472 8.8.8.8 отправляет пакет размером 1500 байт с учётом заголовков и запретом фрагментации. Сообщение о необходимости фрагментации указывает на проблему MTU в туннеле. ping не показывает маршрут, для этого нужны traceroute и mtr.
Трассировка маршрута: traceroute и mtr
traceroute строит путь за счёт увеличения поля TTL: первый пакет уходит с TTL 1, первый маршрутизатор отбрасывает его и сообщает о превышении времени жизни, дальше процедура повторяется. В Linux по умолчанию используются UDP-пакеты с растущим номером порта, ключ -I переключает на ICMP, ключ -T на TCP SYN, что помогает пройти фильтры, настроенные против UDP. Запуск с отключённым разрешением имён: traceroute -n 8.8.8.8.
mtr объединяет трассировку с мониторингом и показывает потери и задержки на каждом хопе в динамике. Интерактивный режим: mtr -n 8.8.8.8. Отчёт для сохранения в тикет: mtr -r -c 10 -n 8.8.8.8, где -c задаёт число циклов. Проверка конкретного TCP-порта: mtr -T -P 443 -n example.com. Разница в подходе принципиальна: traceroute даёт один срез на момент запуска, mtr усредняет серию измерений и показывает стабильность участков.
Как читать вывод traceroute и mtr
Три звёздочки в строке хопа означают, что узел не прислал ответ в отведённое время. Это не всегда проблема: маршрутизаторы часто ограничивают генерацию ICMP и отвечают только части запросов. Диагностический признак другой: если потери начинаются на определённом хопе и сохраняются на всех последующих, включая последний, проблема находится на этом участке. Если потери видны на промежуточном узле, но до цели доходит 0% потерь, речь о приоритизации служебного трафика в control plane, а не о потере пользовательских данных.
Задержки читают по скачкам. Резкий рост времени отклика на одном хопе с последующим сохранением значений говорит о перегрузке или о смене физического маршрута, например о переходе через другой континент. Скачок только на одном узле и возврат к прежним значениям дальше обычно связан с очередью на самом маршрутизаторе. Пример с потерями на пятом хопе без потерь на последнем разбирается вместе с методикой поиска петель в материале про поиск и устранение потери пакетов и сетевых петель.
Ограничение методики: часть сетей фильтрует ICMP и UDP целиком, тогда путь остаётся неполным до последнего хопа. Переключение на TCP-режим mtr -T или traceroute -T помогает в большинстве таких случаев, но не гарантирует результат.
Анализ трафика на уровне пакетов с tcpdump
tcpdump нужен, когда ping и трассировка не дают однозначного ответа, а сервис недоступен. Базовый захват: tcpdump -i eth0 -nn host 10.0.0.1 and port 80. Ключ -nn отключает разрешение имён и портов, что ускоряет вывод и убирает лишние DNS-запросы. Опция -i any слушает все интерфейсы, -c 50 ограничивает количество пакетов, -w /tmp/dump.pcap сохраняет дамп для анализа в Wireshark.
Чтение флагов TCP даёт ответ о точке сбоя. Если в дампе нет исходящего SYN, хотя приложение инициировало соединение, ищите причину на локальной стороне: приложение слушает другой адрес, трафик ушёл в туннель, сработало правило iptables или nftables. Если SYN есть, а SYN-ACK нет, пакет потерялся в сети, отброшен фильтром на получателе или порт закрыт с политикой drop. Немедленный RST говорит о закрытом порте или о reject-правиле на удалённой стороне. Ответный ICMP с формулировкой port unreachable или admin prohibited прямо называет причину и адрес фильтра.
Строки ARP в дампе показывают проблемы второго уровня: повторяющиеся записи ARP, Request who-has 192.168.1.1 tell 192.168.1.100 без ответа означают, что шлюз недоступен на уровне L2, и маршрутизация тут не поможет. Проверку ARP, MTU и правил nftables удобно вести по материалу про диагностику Linux-маршрутизатора командами ip, ping, traceroute и nft.
Ключевые фильтры tcpdump для диагностики маршрутизации
Готовые выражения для частых задач: tcpdump -i eth0 icmp для проверки служебных сообщений, tcpdump -i eth0 -nn 'tcp port 443' для конкретного сервиса, tcpdump -i eth0 -nn 'host 192.168.1.1 and host 10.0.0.1' для разговора двух узлов. Операторы and, or и not комбинируются свободно, скобки в оболочке нужно экранировать. Флаг -e добавляет MAC-адреса, -vv повышает детализацию разбора заголовков.
Для работы tcpdump нужны права root или capability CAP_NET_RAW. В контейнере утилита видит только собственное сетевое пространство имён, поэтому захват на хосте не покажет трафик пода. Запуск требует либо привилегированного контейнера, либо явного добавления capability. Длительный захват на нагруженном интерфейсе без фильтров приводит к потере пакетов самим tcpdump: ограничивайте дамп условиями и используйте -c или -w с ротацией файлов.
Подводные камни: версии ПО, окружения и типичные ошибки
Диагностика искажается из-за различий в инструментах и окружении. Версии iproute2 меняют формат вывода: поле cache в ip route get убрано, набор полей при работе с VRF расширен. Реализации traceroute различаются протоколом по умолчанию: в Linux это UDP, в Windows ICMP, часть сборок busybox не поддерживает TCP-режим. Опции -T и -u в mtr доступны не во всех версиях, а ключ -M do утилиты ping из iputils ведёт себя иначе, чем -D в BSD-версиях.
Контейнеры и сетевые пространства имён изолируют стек полностью. Перед проверкой определите, где вы находитесь: ip netns identify $$ покажет имя namespace для текущего процесса, lsns -t net перечислит существующие сетевые пространства. Внутри пода Kubernetes набор утилит ограничен, а маршруты задаёт CNI-плагин, поэтому ip route show внутри контейнера показывает не то же, что на узле.
Фильтрация и трансляция адресов часто блокируют только ICMP, пропуская TCP. Из этого следует правило: отсутствие ответа на ping при работающем порте 443 не означает потерю маршрута. Облачные security groups, локальные правила nftables и NAT-устройства на пути способны менять адрес источника, из-за чего ответ уходит не туда.
Асимметричная маршрутизация вместе с rp_filter приводит к отбросу ответных пакетов. Параметр net.ipv4.conf.all.rp_filter принимает значения 0 (проверка выключена), 1 (строгий режим) и 2 (свободный режим). Поведение ядра при проверке маршрута к источнику зависит от версии ядра, поэтому перед изменением параметров фиксируйте текущие значения. Проблемы MTU проявляются в туннелях: небольшие пакеты проходят, крупные исчезают, а в дампе видны ICMP-сообщения о необходимости фрагментации.
Ещё одна категория ошибок связана с логами. Переполнение таблицы conntrack ядро пишет в dmesg строкой nf_conntrack: table full, dropping packet, а сбросы интерфейса фиксируются в journalctl -k. Проверять логи полезно до того, как менять конфигурацию продакшена.
Пошаговый алгоритм диагностики маршрутизации
Последовательность ниже подходит для разбора инцидента на Linux-сервере. На каждом шаге фиксируйте вывод команд: это ускорит разбор, если проблему придётся передавать коллегам.
- Проверьте интерфейсы и адреса: ip -br link и ip -br addr. Интерфейс в состоянии DOWN или без IP означает локальную проблему: поднимите линк командой ip link set eth0 up, проверьте получение адреса по DHCP или конфигурацию дистрибутива.
- Посмотрите таблицу маршрутов: ip route show. Если нужной сети или default-маршрута нет, добавьте запись или исправьте постоянную конфигурацию. Убедитесь, что метрики не отдают приоритет ненужному маршруту.
- Определите фактический выбор маршрута: ip route get с адресом цели. Проверьте поля dev, src и via. Неожиданный интерфейс или адрес источника означает, что сработало правило policy routing: смотрите ip rule show и нужную таблицу.
- Проверьте доступность: ping -c 4 с адресом цели. 100% потерь переводит разбор на следующий шаг, но помните про возможную блокировку ICMP.
- Трассируйте путь: mtr -r -c 10 -n с адресом цели. Найдите хоп, с которого начинаются устойчивые потери или резкий рост задержки.
- Захватите трафик: tcpdump -i с нужным интерфейсом, фильтр host и port. Смотрите наличие SYN, SYN-ACK, RST и ICMP-сообщений, чтобы понять, где рвётся диалог.
- Проверьте фильтрацию и трансляцию: правила nftables или iptables, политики на обоих концах, настройки security groups и состояние conntrack.
- Учтите особенности окружения: сетевое пространство имён, контейнер, VRF, MTU туннеля и версии утилит. Ошибки выбора интерфейса или источника исправляйте изменением маршрута, а не добавлением обходных правил.
Прикладной уровень стоит проверять отдельно: часть отказов выглядит как сетевой сбой, а на деле связана с балансировкой, заголовками или маршрутами внутри приложения. Разбор таких случаев с curl, логами Nginx и трассировкой в service mesh собран в статье про диагностику маршрутизации в веб-приложениях и микросервисах.
Диагностика маршрутизации в контексте INCY
Когда часть трафика на рабочей станции или сервере направляется через защищённый канал средствами приложения INCY, проверку начинают не с ядра, а с правил самого приложения. Маршрутизация в INCY определяет, какой трафик идёт через защищённый канал, а какой напрямую, поэтому ошибка в списке или профиле выглядит как «сайт не открывается», хотя таблица маршрутов ядра корректна.
Порядок проверки простой. Сначала убедитесь, что выбран подходящий профиль: «Глобальный», «Умный» или «Только по списку». Для большинства сценариев подходит «Умный»: локальные сервисы работают на полной скорости, зарубежные идут через канал. Затем откройте Настройки, раздел «Маршрутизация», подраздел «Белый список» и проверьте, какие домены и адреса в него внесены. Белый список задаёт перечень доменов или IP, которые идут через защищённый канал либо, в зависимости от настройки, напрямую.
Правила добавляются по домену, IP-адресу или приложению, а сети удобно указывать в формате CIDR: это пригодится для корпоративных VPN и локальных подсетей. Готовые наборы доменов импортируются по URL, поддерживаются стандартные форматы списков, а собственные подборки публикуются в репозитории incy-dev. Официальное описание разделов и шагов настройки приведено в документации по настройке маршрутизации INCY.
Типичная ошибка: нужный домен попал в исключения и потому идёт напрямую. Проверяйте это на примере: YouTube должен идти через канал, ВКонтакте напрямую, локальная сеть напрямую. Если ожидаемый ресурс не открывается, сверьте его статус в списках до того, как переходить к ip route get и tcpdump.