Для быстрой диагностики маршрутизации на Linux-сервере используйте последовательность из пяти шагов: проверьте интерфейсы и адреса, найдите маршрут до нужного IP, проверьте policy routing, протестируйте шлюз и удаленный узел, затем сравните результат с доступностью TCP-порта. Базовый набор команд: ip addr, ip route, ip rule, ip route get, ping, traceroute или tracepath, ss.
Сначала определите масштаб сбоя. Если ядро отвечает Network is unreachable, проблема чаще всего находится в локальной таблице маршрутов, policy routing или состоянии интерфейса. Если шлюз доступен, а удаленный IP не отвечает, проверяйте промежуточные маршрутизаторы, обратный путь, firewall, MTU и сам удаленный узел. Если IP открывается, а имя нет, ищите причину в DNS.
Наличие строки в таблице маршрутов не доказывает, что пакет достигнет цели. Маршрут описывает решение локального ядра: через какой интерфейс и next hop отправить пакет. Фактический результат нужно подтвердить проверкой доступности, трассировкой и тестом нужного порта.
Как быстро найти проблему маршрутизации на сервере
Первый проход должен занимать несколько минут и давать ответы на конкретные вопросы: подключен ли сервер к нужной сети, есть ли маршрут, какое правило выбирается, доступен ли gateway и принимает ли удаленный сервис соединения.
Минимальный набор команд для первого прохода
ip -br addrпоказывает адреса интерфейсов в компактном виде.ip link showпомогает проверить состояние интерфейсов и флагUP.ip route show table allвыводит маршруты во всех таблицах.ip rule showпоказывает правила policy routing и их приоритеты.ip route get 203.0.113.10показывает маршрут, интерфейс, gateway и исходный адрес для конкретной цели.ping -c 4 192.0.2.1проверяет доступность шлюза.ping -c 4 203.0.113.10проверяет ICMP-доступность удаленного IP.traceroute -n 203.0.113.10илиtracepath 203.0.113.10показывает путь с промежуточными узлами.ss -lntupпоказывает локальные TCP- и UDP-сокеты и процессы, которые их обслуживают.
Для TCP-порта используйте, например, nc -vz 203.0.113.10 443 или curl -v http://203.0.113.10:8080/. Проверяйте именно тот протокол и порт, который нужен приложению. Успешный ping подтверждает обмен ICMP-пакетами, но не открытый HTTPS, SSH или другой сервис.
Какие результаты считать подозрительными
- У интерфейса нет нужного IPv4- или IPv6-адреса.
- Интерфейс находится в состоянии
DOWNили не имеет ожидаемого флагаLOWER_UP. - В таблице отсутствует маршрут
default, хотя сервер должен обращаться к другим сетям. - Маршрут указывает на интерфейс, которого нет, или на gateway за пределами локальной подсети.
ip route getвыбирает неожиданный source address, VPN-интерфейс или другую таблицу.- Ядро отвечает
Network is unreachable. - Шлюз не отвечает, а в
ip neighпоявляется состояниеFAILEDилиINCOMPLETE. - TCP-проверка возвращает
Connection refused, хотя маршрут работает. Это обычно означает, что узел доступен, но порт закрыт или приложение не слушает адрес. - TCP-проверка завершается тайм-аутом. Причина может находиться в firewall, ACL, обратном маршруте, MTU или удаленном сервисе.
Сообщение No route to host требует контекста. Его может сформировать локальная система при отсутствии маршрута, промежуточный маршрутизатор через ICMP-ответ или firewall, который явно отклоняет трафик.
Проверка интерфейсов, адресов и шлюза
Маршрутизация начинается с локального состояния. Ядро не сможет корректно отправить пакет, если адрес назначен не тому интерфейсу, маска сети указана неверно или gateway недоступен на канальном уровне.
Проверка адреса и состояния сетевого интерфейса
ip link show
ip addr show
ip -br addrВ выводе проверьте имя интерфейса, его состояние и назначенные адреса. Для Ethernet обычно нужны состояния UP и LOWER_UP. Флаг UP означает, что интерфейс включен в ядре, а LOWER_UP указывает на наличие физического или виртуального линка.
Сверьте префикс. Адрес 192.0.2.15/24 относится к сети 192.0.2.0/24. При ошибочном префиксе /16 сервер может считать удаленный адрес локальным и пытаться найти его через ARP, не отправляя пакет gateway.
На multi-homing-сервере проверьте все интерфейсы. Два default route могут быть нормальной частью настройки, но выбранный маршрут должен соответствовать source address и политике сети. Не удаляйте один из маршрутов вслепую на удаленной машине, иначе можно потерять SSH-доступ.
Проверка default gateway и соседнего узла
ip route show default
ip route
ping -c 4 192.0.2.1
ip neigh showПример нормального default route:
default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.15 metric 100Здесь 192.0.2.1 это gateway, eth0 это интерфейс, а 192.0.2.15 это предпочтительный исходный адрес. Команда ping до шлюза проверяет базовую связность внутри локального сегмента.
Если шлюз не отвечает, проверьте соседнюю таблицу:
ip neigh show dev eth0Состояние REACHABLE говорит, что MAC-адрес соседнего узла известен и недавно подтвержден. INCOMPLETE означает, что разрешение IPv4-адреса через ARP еще не завершилось. FAILED указывает на отсутствие ответа. Для IPv6 аналогичный механизм работает через NDP.
Недоступность gateway бывает связана с неправильной маской, VLAN, bridge, security group, фильтрацией ARP или NDP и ошибкой виртуального сетевого подключения. До проверки удаленного IP сначала добейтесь стабильной связи со шлюзом.
Общий алгоритм поиска сетевых сбоев с проверкой интерфейсов, ARP и трассировкой собран в полном чеклисте диагностики маршрутизации.
Как проверить таблицу маршрутов через ip route
Команда ip route работает с маршрутами ядра Linux. Она показывает, какие сети считаются локальными, через какой next hop отправляется трафик и какой маршрут используется по умолчанию.
Чтение вывода ip route
ip route showПример:
default via 192.0.2.1 dev eth0 proto static metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.15
10.10.0.0/16 via 192.0.2.254 dev eth0 metric 50defaultиспользуется, когда более точного маршрута нет.viaзадает gateway, через который отправляется пакет.devзадает интерфейс.srcпоказывает предпочтительный исходный адрес.metricпомогает выбрать маршрут при наличии нескольких вариантов одинаковой специфичности.proto kernelобычно обозначает маршрут, добавленный ядром после назначения адреса.scope linkуказывает, что сеть доступна непосредственно через интерфейс.
Маршрут 10.10.0.0/16 via 192.0.2.254 dev eth0 направляет трафик к сети 10.10.0.0/16 через gateway 192.0.2.254. Gateway должен быть достижим через подключенную сеть. Если next hop находится за пределами connected-сети, ядро может отклонить маршрут или не сможет разрешить его канальный адрес.
Проверка маршрута до конкретного адреса через ip route get
ip route get 10.10.20.30
ip route get 10.10.20.30 from 192.0.2.15Пример результата:
10.10.20.30 via 192.0.2.254 dev eth0 src 192.0.2.15Эта команда полезнее простого чтения таблицы, когда на сервере несколько интерфейсов, VPN или правил policy routing. Она показывает решение ядра для конкретной цели. Сравните вывод с разными source address:
ip route get 10.10.20.30 from 192.0.2.15
ip route get 10.10.20.30 from 198.51.100.15Если результаты различаются, проверьте, соответствует ли выбор интерфейса архитектуре сети. Неожиданный source address часто приводит к тому, что удаленная сторона отправляет ответ другим маршрутом или отбрасывает пакет по ACL.
Типичные ошибки в таблице маршрутов
- Нет маршрута. Добавьте маршрут только после проверки нужной подсети и gateway.
- Неверный prefix. Ошибка в маске меняет границы локальной сети и способ поиска next hop.
- Конкурирующие маршруты. Сначала выбирается более специфичный prefix, затем учитывается metric.
- Неверная metric. Менее предпочтительный канал может использоваться вместо основного.
- Остаточный маршрут VPN. После отключения туннеля запись может направлять трафик в неактивный интерфейс.
- Ошибочный default route. Весь трафик к неизвестным сетям уходит через неправильный uplink.
Временный маршрут, добавленный командой ip route add, обычно исчезает после перезагрузки или перезапуска сетевого менеджера. Постоянные изменения вносите через штатный NetworkManager, systemd-networkd или конфигурацию, принятую в конкретном дистрибутиве.
Проверка policy routing через ip rule
Обычная команда ip route часто показывает только таблицу main. Policy routing может направить пакет в пользовательскую таблицу по адресу источника, входному интерфейсу, метке firewall или другому условию.
Как читать ip rule и связанные таблицы
ip rule show
ip route show table allТипичный базовый вывод содержит таблицы local, main и default:
0: from all lookup local
32764: from 192.0.2.0/24 lookup 100
32766: from all lookup main
32767: from all lookup defaultПравила обрабатываются по приоритету: меньшее числовое значение проверяется раньше. Если правило выбирает таблицу 100, изучите ее отдельно:
ip route show table 100Запись с lookup main не гарантирует, что до нее дойдет обработка. Раннее правило может вернуть маршрут из другой таблицы или завершить поиск отказом.
Проверка маршрута с разными адресами источника
ip route get 203.0.113.10 from 192.0.2.15
ip route get 203.0.113.10 from 198.51.100.15Сравнивайте gateway, интерфейс и source address. Для сервера с двумя uplink один источник может идти через корпоративный канал, другой через VPN или резервного провайдера. Если обратный маршрут не согласован, соединение становится односторонним: запрос уходит, ответ приходит на другой интерфейс или отбрасывается stateful firewall.
Для глубокой диагностики асимметрии полезен материал об асимметричной маршрутизации и policy routing.
Признаки конфликта VPN, Docker или сетевых namespace
VPN-клиенты, Docker и оркестраторы добавляют интерфейсы, маршруты, правила и сетевые пространства имен. После запуска туннеля маршрут к одной подсети может начать использовать tun0 или wg0. Контейнерный маршрут может существовать в namespace хоста, но отсутствовать внутри контейнера.
ip link show
ip route show table all
ip rule show
ip netns list
ip netns exec <namespace> ip routeДля проверки контейнера смотрите его собственные адреса и маршруты. Команда, выполненная на хосте, не всегда описывает путь процесса внутри namespace.
Проверка фактического пути пакета: ping и traceroute
ping отвечает на вопрос о доступности по ICMP. traceroute помогает увидеть, через какие узлы пакет проходит при увеличении TTL. Эти проверки дополняют таблицу маршрутов и не заменяют друг друга.
Что показывает ping и чего он не доказывает
ping -c 4 127.0.0.1
ping -c 4 192.0.2.1
ping -c 4 10.10.20.30
ping -c 4 example.internalПроверяйте путь последовательно: loopback, собственный gateway, адрес в соседней сети, удаленный IP и имя хоста. Потеря уже на loopback указывает на локальную проблему, отсутствие ответа от gateway направляет проверку к интерфейсу, VLAN, ARP или NDP.
ICMP может фильтроваться на сервере, маршрутизаторе или удаленном узле. Поэтому отсутствие ответа не доказывает отсутствие маршрута. Для TCP-проверки используйте:
nc -vz 10.10.20.30 443
curl -v http://10.10.20.30:8080/traceroute для диагностики сети
traceroute -n 10.10.20.30
tracepath 10.10.20.30
traceroute -T -p 443 -n 10.10.20.30Обычный traceroute может использовать UDP или ICMP в зависимости от реализации и параметров. Вариант -T отправляет TCP-пробы, что полезно при фильтрации UDP или ICMP. tracepath дополнительно помогает обнаружить изменения MTU по пути.
Звездочки означают отсутствие ответа на конкретную пробу. Промежуточный маршрутизатор может фильтровать сообщения TTL exceeded и при этом передавать трафик дальше. Если следующие узлы отвечают, один ряд звездочек не доказывает отказ именно этого маршрутизатора.
Как читать результат трассировки
Сопоставляйте строки с логическими участками: локальный сервер, gateway, корпоративная или провайдерская сеть, удаленная сеть, destination. Первый стабильный участок, после которого начинаются потери, задает направление дальнейшей проверки. Повторите тест несколько раз и сравните результат с другой точки, потому что разные пробы могут идти по разным маршрутам.
Трассировка из одного направления не показывает обратный путь. При асимметричной маршрутизации запрос и ответ проходят через разные устройства. Для потерь, петель и проблем MTU полезны traceroute, mtr и tcpdump в комплексной диагностике.
Как отличить маршрутизацию от DNS, firewall и проблемы сервиса
Один и тот же симптом, например тайм-аут, возникает на разных уровнях. Проверяйте IP, имя, порт и фильтры отдельно. Это сокращает число необоснованных изменений в таблицах маршрутов.
Проверка DNS отдельно от маршрутизации
getent hosts example.internal
dig example.internal
nslookup example.internal
ping -c 4 203.0.113.10Если имя не разрешается, а доступ по IP работает, проблема находится в DNS, search domain, split-horizon-зоне или доступности DNS-сервера. Сравните IP, который возвращает DNS, с ожидаемым адресом. Имя может указывать на другой балансировщик или внутренний адрес.
Проверка TCP-порта и процесса через ss
ss -lntup
ss -ntp
ss -lntp '( sport = :443 )'LISTENозначает, что локальный процесс ожидает подключения.SYN-SENTпоказывает, что клиент отправил SYN и ждет ответа.SYN-RECVозначает, что сервер получил SYN и отправил ответ, но рукопожатие не завершено.ESTABLISHEDподтверждает установленное TCP-соединение.
Connection refused обычно приходит от доступного узла, где порт закрыт или процесс не слушает нужный адрес. Тайм-аут означает, что ответ не пришел вовремя. Проверяйте bind-адрес: процесс, слушающий только 127.0.0.1, не принимает соединения через внешний интерфейс.
Проверка firewall на сервере и по пути
nft list ruleset
iptables -L -n -v
ufw status verbose
firewall-cmd --list-allВыберите команды, соответствующие установленному firewall. Смотрите counters правил и логи отклонений. Пакет может блокироваться на сервере, gateway, балансировщике, VPN-шлюзе или удаленном узле. Security groups и ACL облачной сети проверяются отдельно от локальной таблицы маршрутов.
Если маршрут корректен, gateway отвечает, а TCP-пакеты не получают ответа, временно разрешайте только нужный источник и порт по принятой процедуре контроля изменений. После теста верните ограничение или оформите постоянное правило.
Проверка удаленного узла
Сравните результат с нескольких источников. Если сервис доступен из одной сети и недоступен с конкретного сервера, ищите различие в маршруте, source address, ACL, firewall или DNS. Если сервис недоступен отовсюду, проверьте его состояние, listening address и сетевую конфигурацию.
Для размещения тестового сервера или временной диагностической площадки можно использовать облачную инфраструктуру Timeweb Cloud, если это соответствует требованиям проекта и политике безопасности.
Диагностика типовых симптомов и ошибок
Network is unreachable и No route to host
Network is unreachable часто формируется локальным ядром, когда для целевого адреса не найден подходящий маршрут. Выполните:
ip route get 203.0.113.10
ip rule show
ip route show table allПроверьте default route, connected-сеть, пользовательские таблицы и правила с меньшим приоритетом. Если маршрут есть, но приложение получает No route to host, проверьте gateway, firewall и ICMP-ошибки от промежуточного устройства.
Тайм-аут при доступном шлюзе
Рабочий gateway подтверждает связь с локальным сегментом. Он не подтверждает маршрут до удаленной сети. Запустите traceroute или tracepath, проверьте обратный маршрут и фильтры. Причина может находиться в ACL, MTU, удаленном firewall или отключенном сервисе.
Если TCP SYN уходит, но SYN-ACK не возвращается, используйте tcpdump при наличии доступа к серверу или сетевому узлу:
tcpdump -ni eth0 host 203.0.113.10 and port 443Пакеты проходят только в одну сторону
Односторонний доступ указывает на отсутствие обратного маршрута, policy routing, асимметрию или фильтрацию ответного трафика. Сравните таблицы маршрутов на обеих сторонах, исходный адрес и правила ip rule. В multi-homing-среде проверьте, что ответ возвращается через ожидаемый интерфейс.
При наличии stateful firewall асимметричный путь может выглядеть как случайная потеря соединений. Подробный разбор такой ситуации приведен в руководстве по traceroute, mtr и ip route.
- Проблема только через VPN: проверьте маршрут в туннель, MTU, правила с source address и доступность подсети на удаленной стороне.
- Проблема только в контейнере: проверьте маршрут и DNS внутри его network namespace.
- Доступ по IP есть, по имени нет: проверяйте DNS.
- Ping проходит, порт не открывается: проверяйте процесс, bind-адрес и firewall.
- Connection refused: узел отвечает, но нужный порт закрыт либо приложение не слушает ожидаемый адрес.
- Timeout: ищите фильтрацию, отсутствие обратного пути, MTU или отказ удаленного узла.
Итоговый чеклист и безопасное исправление
Чеклист команд перед изменениями
ip -br addrip link showip route show table allip rule showip route get <целевой-IP>ip route get <целевой-IP> from <source-IP>ip neigh showping -c 4 <gateway>ping -c 4 <целевой-IP>traceroute -n <целевой-IP>илиtracepath <целевой-IP>getent hosts <имя>и проверка DNS по IPss -lntupи тест нужного порта черезncилиcurl- Проверка counters и логов firewall
Сохраните вывод до изменений. Зафиксируйте время проверки, исходный IP, целевой IP, порт, интерфейс, gateway и результат каждой команды. Такая запись позволяет сравнить состояние после исправления и быстро передать сетевой команде точные данные.
Порядок исправления маршрута на удаленном сервере
Сначала убедитесь, что доступна консоль провайдера или резервный канал управления. Затем добавьте временный маршрут с минимальной областью действия и проверьте целевой адрес. Пример изменения должен соответствовать реальной сети:
ip route add 10.10.20.0/24 via 192.0.2.254 dev eth0После добавления выполните ip route get, проверьте gateway, удаленный IP и нужный TCP-порт. Меняйте одну настройку за раз. Постоянную запись создавайте через штатный менеджер сети дистрибутива, затем проверьте маршрут после перезапуска сетевого сервиса и перезагрузки в согласованное окно.
Когда передавать проблему сетевой команде или провайдеру
Передавайте инцидент, если первый стабильный участок потери находится за пределами сервера, отсутствует обратный маршрут на чужой стороне, требуется изменить ACL или проблема повторяется из нескольких независимых источников.
В отчет включите время и направление проверки, исходный и целевой IP, порт, вывод ip route get, ip rule, traceroute, ping, результат DNS-проверки, состояние локального firewall и сравнение с другим источником. Укажите первый стабильный узел, после которого начинается отказ, и повторяется ли проблема при TCP-, ICMP- и UDP-проверках.
Рабочая последовательность выглядит так: интерфейс, адрес, gateway, выбранный маршрут, policy routing, фактический путь, DNS, firewall, порт и удаленный сервис. Такой порядок помогает быстро локализовать сбой и не менять сетевую конфигурацию без подтвержденной причины.