Диагностика проблем маршрутизации: полный чек-лист для DevOps и системных администраторов

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

Подготовка и базовые проверки: фундамент диагностики

Диагностику всегда начинайте с элементарных условий. Пропуск этих шагов ведет к трате времени на поиск сложной причины при наличии простой, например, физического обрыва или неверного IP-адреса.

Проверка состояния и конфигурации сетевых интерфейсов

Первым делом убедитесь, что сетевая карта активна и корректно настроена. В Linux используйте ip addr show или устаревшую, но привычную ifconfig. В Windows выполните ipconfig /all в командной строке.

Обратите внимание на три ключевых момента:

Статус интерфейса: Должен быть UP или Enabled. Состояние DOWN указывает на отключение программно или аппаратно.
Назначенный IP-адрес и маска подсети: Убедитесь, что адрес соответствует ожидаемой подсети. Отсутствие адреса или наличие 169.254.x.x (APIPA) говорит о проблеме с DHCP или ручной конфигурацией.
Наличие шлюза по умолчанию: Он может отображаться в выводе команд. Если его нет, система не знает, куда отправлять пакеты за пределы своей подсети.

Пример команды для быстрой проверки основного интерфейса в Linux: ip -4 addr show eth0.

Проверка доступности шлюза по умолчанию

Если интерфейс в порядке, следующим шагом проверьте связь со шлюзом. Это ключевой элемент маршрутизации «вовне». Используйте команду ping <адрес_шлюза>.

Интерпретируйте результаты:

Успешный ping (отклик): Шлюз доступен на сетевом уровне. Проблема может быть дальше по пути.
100% потеря пакетов: Шлюз недоступен. Причины: физическая проблема (кабель, порт коммутатора), блокировка ICMP на самом шлюзе правилами фаервола, некорректный ARP.
Высокая задержка или частичная потеря пакетов: Указывает на перегрузку канала или нестабильность связи.

Если ping не проходит, переходите к проверке ARP-таблицы и физического подключения. Помните, что некоторые провайдеры или корпоративные политики безопасности могут намеренно блокировать ICMP-эхо-запросы.

Диагностика на уровне L2 и L3: ARP и таблицы маршрутизации

Когда базовая связь проверена, углубитесь в механизмы, определяющие путь пакета: разрешение адресов на канальном уровне и таблицы маршрутизации на сетевом.

Анализ ARP-таблицы: есть ли сосед в сети?

Протокол ARP (Address Resolution Protocol) преобразует IP-адреса в MAC-адреса в пределах одной подсети. Если ARP-запись для шлюза отсутствует или некорректна, пакеты не будут отправлены. В Linux просмотрите таблицу командой ip neigh show, в Windows – arp -a.

Ключевые состояния записи в Linux:

REACHABLE: Запись актуальна, связь с узлом подтверждена.
STALE: Запись устарела, но еще не удалена. При следующей отправке данных будет выполнена повторная проверка.
FAILED: Попытка разрешить адрес завершилась неудачей. Это явный признак проблемы.

Если MAC-адрес шлюза отсутствует в таблице, проверьте: находятся ли ваш хост и шлюз в одном широковещательном домене (один VLAN), не включена ли изоляция портов на коммутаторе, не блокируется ли ARP-трафик.

Глубокий разбор таблицы маршрутизации с ip route show

Таблица маршрутизации – сердце диагностики. Она определяет, через какой интерфейс и на какой адрес шлюза будут отправлены пакеты до конкретной сети. В Linux для анализа используйте ip route show или ip r s. В Windows аналог – route print.

Разберите вывод команды:

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 100
10.0.0.0/24 via 192.168.1.254 dev eth0 metric 200

Маршрут по умолчанию (default via): Самый важный. Указывает шлюз для всех сетей, не описанных явно. Если он отсутствует, выход за пределы локальной подсети невозможен.
Подключенные интерфейсы (scope link): Маршруты к сетям, непосредственно подключенным к интерфейсам системы. Пакеты до этих сетей отправляются напрямую.
Статические маршруты: Явно прописанные пути к конкретным сетям через указанный шлюз.

Ищите проблемы:

Отсутствие маршрута по умолчанию: Команда ip route show default должна вернуть запись.
Конфликт метрик: Если до одной сети ведут несколько маршрутов, используется путь с меньшей метрикой (значением metric). Неверная метрика может направить трафик по неоптимальному или неработающему пути.
Более специфичный маршрут: Система всегда выбирает самый точный (с самым длинным префиксом) маршрут. Маршрут 10.0.0.0/8 будет проигнорирован, если есть 10.0.0.0/24.

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

Трассировка маршрута: выявление узких мест и обрывов

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

Классическая трассировка: traceroute/tracert

Инструмент traceroute (Linux) или tracert (Windows) показывает цепочку маршрутизаторов (хопов) до цели. Принцип работы основан на увеличении значения TTL (Time To Live) в IP-пакете.

Для быстрого запуска без разрешения DNS-имен используйте ключ -n: traceroute -n 8.8.8.8.

В выводе для каждого хопа отображаются три замера времени. Звездочки (*) вместо времени означают, что пакет на этом хопе был потерян или ответ не пришел за таймаут. Если звездочки начинаются с определенного хопа и продолжаются до конца, это указывает на точку обрыва или маршрутизатор, который не возвращает ICMP-пакеты «Time Exceeded».

Динамическая диагностика с mtr: анализ потерь и задержек

В отличие от однократного снимка traceroute, mtr (My TraceRoute) непременно отправляет пакеты и предоставляет статистику в реальном времени. Это незаменимо для диагностики плавающих, нестабильных проблем.

Запустите отчет: mtr --report-wide 8.8.8.8. Ключ --report завершит работу после заданного числа циклов.

Анализируйте колонки отчета:

Loss%: Процент потерь пакетов на каждом хопе. Высокий процент (например, более 10-20%) на конкретном хопе указывает на проблемный участок сети.
Avg, Best, Wrst: Средняя, лучшая и худшая задержка. Резкий скачок средней задержки между двумя последовательными хопами сигнализирует о перегруженном канале или неоптимальном пути.

Для Windows используйте аналог – WinMTR. Если трассировка обрывается сразу после вашего шлюза, следующей точкой проверки должны стать правила межсетевого экрана.

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

Межсетевые экраны и служебные протоколы: невидимый барьер

Частой и неочевидной причиной сбоев является блокировка сетевого трафика правилами фаервола, причем не только пользовательского, но и служебного.

Проверка правил, блокирующих ICMP (ping, traceroute)

Если ping или traceroute не работают, а базовые сетевые проверки пройдены, проверьте правила фильтрации. В Linux с iptables выполните: iptables -L -n --line-numbers | grep -i icmp. Ищите правила с действиями DROP или REJECT для протокола icmp или конкретных типов, таких как echo-request (ping) и time-exceeded (используется traceroute).

Для временной диагностики в контролируемой среде можно добавить разрешающее правило, но обязательно удалите его после: iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT.

В современных системах с nftables используйте nft list ruleset. В Windows проверьте входящие и исходящие правила в «Брандмауэре Защитника Windows» для профиля «Общий доступ» и «Доменный».

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

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

Проверьте:

Открыты ли необходимые порты: Например, OSPF использует протокол 89 (IP), BGP – TCP-порт 179.
Достижимость соседей: Убедитесь, что IP-адреса, указанные в конфигурации соседей, доступны (ping).
Наличие сессий: Используйте CLI маршрутизатора (например, для FRRouting: show ip ospf neighbor, show ip bgp summary).

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

Алгоритм действий и минимизация простоя

Объедините все шаги в единый алгоритм для системного применения в инцидент-менеджменте.

Локализация: Определите, проблема на одном хосте или затрагивает группу устройств. Проверьте связь между узлами в одной подсети.
Базовые проверки: Выполните последовательно: состояние интерфейса (ip addr show), ping шлюза, анализ ARP-таблицы (ip neigh show).
Анализ маршрутизации: Изучите таблицу маршрутизации (ip route show), проверьте наличие и корректность маршрута по умолчанию.
Трассировка пути: Если проблема с удаленным хостом, запустите mtr --report <цель> для сбора статистики по потерям и задержкам.
Проверка фаервола: Если трафик не выходит за пределы хоста или не принимается, проверьте правила iptables/nftables или Windows Firewall, уделяя внимание ICMP и служебным портам.
Документирование и откат: Фиксируйте все изменения. Если проблема устранена временным правилом, запланируйте его постоянную и безопасную замену или удаление.

Рекомендации для production-среды:

Используйте тестовые окна для изменений.
Имейте готовый план отката конфигурации.
Для сложных распределенных систем рассмотрите использование облачных решений, таких как Timeweb Cloud, которые предоставляют встроенные инструменты мониторинга сети и логирования.
Автоматизируйте рутинные проверки с помощью скриптов.

Системный подход, описанный в этом чек-листе, позволяет последовательно исключать возможные причины, минимизируя время простоя и снижая риск ошибок. Сохраните эту статью как шпаргалку для быстрого реагирования на сетевые инциденты. Для решения специфичных задач, например, диагностики маршрутизации в веб-приложениях, вам может пригодиться наше руководство по инструментам для DevOps, а для работы в Windows – полный справочник по командам route и netsh.