Linux: No route to host / Network is unreachable — triage и policy routing

Ошибки No route to host и Network is unreachable — одни из самых частых в админской практике: не открывается SSH, не ходят запросы к API, не поднимаются VPN-туннели, ломаются health-check. При этом «вроде бы интернет есть». Ниже — практичный triage (быстрая диагностика) и разбор типовых причин: от банального отсутствия маршрута в ip route до асимметричной маршрутизации, ip rule и жёсткого rp_filter, а также блокировок на уровне nftables и нюансов conntrack.

Что на самом деле означает каждая ошибка

Важно понимать, кто именно «произнёс» фразу — локальное ядро, firewall на вашей машине или промежуточный узел по пути. По смыслу сообщения можно заметно сузить круг поиска.

Network is unreachable

Чаще всего это прямой ответ от локального ядра: для указанного назначения не найден подходящий маршрут (или подходящий интерфейс недоступен). Типовые причины — отсутствующий default route, неверный маршрут до подсети, или трафик ушёл в таблицу маршрутизации без дефолта.

No route to host

Это тоже часто локальная ошибка, но с нюансом: в Linux она нередко соответствует ICMP host unreachable (или близким условиям), которые могли быть сгенерированы локально или получены от промежуточного устройства. Ещё один распространённый источник — firewall, который не «молчит таймаутом», а активно отвечает reject.

Практическая эвристика: Network is unreachable — сначала проверяйте ip route, ip rule и состояние интерфейсов. No route to host — дополнительно подозревайте nftables (reject), асимметрию и rp_filter.

Быстрый triage: минимальный чек-лист (5–10 минут)

Ниже порядок, который обычно экономит время. Идея простая: сначала подтверждаем интерфейсы и базовую маршрутизацию, затем — policy routing, затем — firewall/NAT/conntrack.

1) Зафиксируйте исходные данные

Запишите: целевой IP/порт, протокол, с какого IP/интерфейса должен идти трафик, есть ли несколько адресов на хосте, VRF, VPN, несколько провайдеров.

2) Проверка интерфейсов и адресов

ip -br link
ip -br addr
ip -s link

Если интерфейс DOWN, нет адреса, или счётчики RX/TX/ошибок выглядят подозрительно — дальнейшая маршрутизация вторична.

3) Проверка DNS (чтобы не гоняться за фантомами)

Ошибки маршрутизации легко перепутать с ситуацией, когда имя резолвится «не туда» или резолвится IPv6-адрес, а IPv6 реально не настроен.

getent ahosts example.com
resolvectl status

4) Ключевой шаг: «как ядро повезёт пакет?»

Самая полезная команда в этом сценарии — запрос к FIB: покажи маршрут к адресу, и главное — через какой интерфейс и с каким source IP.

ip route get 1.1.1.1
ip route get 1.1.1.1 from 203.0.113.10 iif lo

Смотрите на поля:

• dev — по какому интерфейсу выйдет пакет;
• via — какой next hop;
• src — какой исходный IP выбрало ядро (часто именно тут «сюрприз»);
• table — если видите не main, значит участвуют ip rule.

5) Таблица маршрутизации и policy routing

ip route show
ip -4 route show table main
ip -6 route show table main
ip rule show

Если есть несколько uplink, VPN или дополнительные адреса — почти всегда важен ip rule. Например, правило может отправлять часть трафика в отдельную таблицу, где нет default route — и вы получите Network is unreachable для конкретных источников.

6) Быстрый traceroute в правильном режиме

traceroute помогает понять, где именно появляется unreachable. Но важно выбрать режим под ваш трафик.

traceroute -n 1.1.1.1
traceroute -n -T -p 443 1.1.1.1
traceroute -n -I 1.1.1.1

Если UDP-traceroute «не идёт», а TCP/ICMP работает — это не обязательно маршрутизация. Часто это фильтрация UDP или политика сети/провайдера.

Типовые причины и как их доказать

Причина 1: нет маршрута или неверный default gateway

Классика: default route отсутствует, указывает на недостижимый next hop, или маршрут есть, но через неправильный интерфейс (например, поднялся второй uplink и метрики стали «не те»).

ip route show default
ip neigh show

Если gateway в одной L2-сети должен быть доступен, но ARP/ND не резолвится — это уже не «routing», а соседство L2/L3: VLAN, фильтрация у провайдера, неправильная маска, дубликат IP.

Причина 2: policy routing (ip rule) отправляет трафик в «пустую» таблицу

Частый источник «плавающих» ошибок, когда с одного IP всё работает, а с другого — Network is unreachable. Сценарий: на сервере несколько публичных IP, и вы ожидаете, что ответы на входящие соединения будут уходить через «своего» провайдера/IP. Для этого добавляют отдельные таблицы и правила.

Проверка:

ip rule show
ip route show table 100
ip route get 8.8.8.8 from 203.0.113.10

Признаки проблемы:

• ip route get ... from X показывает table 100, а в table 100 нет default route;
• в таблице есть default, но через неверный gateway;
• маршрут есть, но выбран «не тот» src, и дальше ломается rp_filter или удалённая сторона отвечает unreachable.

Причина 3: асимметричная маршрутизация и rp_filter

rp_filter (Reverse Path Filtering) — механизм ядра, который проверяет: «если пакет пришёл на интерфейс A с исходником X, то обратный маршрут к X должен тоже идти через A». Если нет — пакет может быть отброшен. Это полезно против спуфинга, но на серверах с несколькими маршрутами/туннелями часто ломает легитимный трафик.

Проверка текущих значений:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter

Режимы обычно такие: 0 — выключен, 1 — strict, 2 — loose. В multi-homing и policy routing чаще нужен 2 (loose) или точечная настройка на конкретных интерфейсах.

Как доказать влияние rp_filter:

• по tcpdump видно входящие пакеты, но приложение их «не видит»;
• при временном переключении rp_filter на 2 симптом исчезает;
• ip route get для обратного направления показывает другой интерфейс, чем реально пришёл пакет.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Причина 4: nftables режет или активно reject-ит трафик

Если firewall делает reject (например, reject with icmpx type host-unreachable), клиенты часто видят именно No route to host, хотя маршрут на самом деле есть.

Быстрая диагностика:

nft list ruleset
nft list chain inet filter input
nft list chain inet filter output
nft list chain inet filter forward

Смотрите:

• есть ли явные reject по нужному порту/протоколу;
• растут ли счётчики правил (packets/bytes) при попытке подключения;
• не забывайте про output: иногда режут исходящие, и это выглядит как «маршруты не работают».

Если у вас NAT, отдельно проверьте цепочки для postrouting/prerouting и приоритеты. Для практики по сложным сценариям SNAT с несколькими адресами пригодится материал про управление SNAT для нескольких IP в nftables.

Причина 5: conntrack и «залипшие» состояния

Когда NAT/фаервол stateful, ситуация «я разрешил правило, но всё равно не работает» иногда упирается в состояние соединения. Например, вы меняли правила, поменяли маршрут, переключили SNAT, а в conntrack остались старые записи, и пакеты продолжают сопоставляться с прежними параметрами.

Проверка:

conntrack -S
conntrack -L | head

Полезно отфильтровать по IP (если утилита поддерживает) и посмотреть, что происходит с конкретным направлением. В инцидентах после миграций/смены маршрутов иногда помогает точечное удаление записей — аккуратно, чтобы не снести всё состояние на проде.

Причина 6: IPv6 «включился сам», а маршрутов или фильтрации нет

Современные системы и приложения любят IPv6: резолвер возвращает AAAA, клиент пытается подключиться по IPv6, а у сервера нет дефолтного маршрута IPv6 или firewall режет ICMPv6/ND. Результат — Network is unreachable или странные таймауты.

ip -6 route show
ip -6 addr
ip route get 2001:4860:4860::8888

Если IPv6 нужен — настройте его корректно и не режьте ICMPv6 «просто потому что ICMP». Если IPv6 не нужен — отключайте осознанно на уровне сервиса/приложения. В качестве расширения темы IPv6 и маршрутизации может быть полезна статья про SLAAC/DHCPv6 и базовую IPv6-маршрутизацию.

Диагностика «как в жизни»: пример с двумя провайдерами

Сервер имеет два публичных адреса/шлюза: один для основного трафика, второй для отдельного сервиса. Входящие приходят на IP2, но ответы уходят через default (IP1). Клиент видит странное: часть запросов падает, иногда No route to host, иногда SYN ушёл, но ответа нет.

Что делать по шагам:

1. Убедиться, что для источника IP2 есть отдельная таблица с default route через шлюз провайдера2.
2. Проверить ip rule по from IP2 и приоритеты правил.
3. Проверить rp_filter на интерфейсе, куда приходит IP2: strict часто ломает асимметрию.
4. Посмотреть nftables: нет ли reject на вход или выход.
5. Проверить conntrack: нет ли записей, которые продолжают старую логику SNAT/route.

Команда, которая обычно «показывает правду»:

ip route get 198.51.100.20 from 203.0.113.20

Если ответ показывает «не тот» dev или «не тот» via — проблема в policy routing, а не в приложении.

Полезные команды, когда быстрый triage не сработал

tcpdump: увидеть, где пропадает пакет

tcpdump -ni any host 198.51.100.20
tcpdump -ni eth0 tcp and host 198.51.100.20 and port 443

Минимальная цель: понять, выходит ли пакет вообще, и приходит ли ответ. Это быстро отделяет «маршрутизация/фаервол на сервере» от «проблема по пути/на удалённой стороне».

ip monitor: отловить неожиданные изменения

ip monitor all

Полезно, когда маршруты «прыгают» из-за NetworkManager, netplan, DHCP-клиента, скриптов VPN или облачных агентов.

Практическая политика исправлений: что менять и как не сломать прод

Ошибки достижимости часто чинятся правкой маршрутов, правил и firewall, но важно делать это безопасно.

1) Сначала диагностика, потом изменения

Снимите вывод ip -br addr, ip route, ip rule, nft list ruleset, conntrack -S. Это упрощает откат и разбор «что именно изменилось».

2) Policy routing: следите за полнотой таблиц

Если используете несколько таблиц, убедитесь, что в каждой таблице, куда ведут правила, есть как минимум:

• маршрут к локальной подсети и достижимому шлюзу;
• default route (если ожидается выход в интернет);
• правильный выбор src (иногда нужен src в маршруте или дополнительные правила).

3) rp_filter: не отключайте вслепую

При multi-homing, policy routing, GRE/IPIP/WireGuard часто достаточно включить loose-режим на конкретном интерфейсе, сохранив stricter-политику на остальных. Полное отключение тоже возможно, но только если вы понимаете риск спуфинга и у вас есть компенсирующие меры (например, фильтрация у провайдера или на периметре).

4) nftables: избегайте «загадочных reject» без наблюдаемости

Если используете reject, добавляйте понятные логи с лимитированием, чтобы в следующий раз не гадать по косвенным симптомам. И держите в голове: блокировки на output очень похожи на «маршруты не работают», хотя это просто egress-политика.

5) conntrack: чистите точечно

Сначала докажите проблему по conntrack, а не «на всякий случай очистим всё». Полная очистка таблицы почти гарантированно уронит активные соединения.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Мини-шпаргалка по симптомам

• Сразу Network is unreachable на локальной машине: ip route get, ip route, ip rule, интерфейсы UP/DOWN.

• No route to host при попытке TCP: проверьте nftables на reject, traceroute -T, также rp_filter при асимметрии.

• Пингуется, но TCP не работает: traceroute TCP, nftables input/output, conntrack (переполнен или «залип»), MTU/PMTUD (если «только большие ответы»).

• Работает с одного IP, не работает с другого: ip route get ... from X, ip rule, таблицы маршрутов, rp_filter.

Заключение

Ошибки No route to host и Network is unreachable почти всегда лечатся быстро, если идти от маршрута к политике: сначала проверяем ip route и ip route get, затем ip rule и таблицы, после — rp_filter, nftables и только потом углубляемся в conntrack и трассировку. Такой порядок минимизирует «шаманство», сохраняет прод и даёт воспроизводимый план действий для дежурств и постмортемов.

Если вы регулярно поднимаете серверы под проекты и вам важно предсказуемо управлять маршрутами, несколькими IP и firewall, удобнее делать это на VDS: полный контроль над сетью, правилами и диагностикой — без сюрпризов.