Linux: No route to host и Network is unreachable — маршрутизация, ARP и policy routing на практике

Что означают No route to host и Network is unreachable

Обе ошибки возникают на уровне сетевого стека Linux ещё до того, как приложение «успеет» что-то сделать. Чтобы не лечить симптомы, важно понимать разницу.

• Network is unreachable — ядро не смогло подобрать маршрут до целевой сети/хоста: нет подходящего маршрута, правило ip rule отправило поиск в «пустую» таблицу, интерфейс/адрес недоступны. Это почти всегда история про маршрутизацию и выбор таблицы.

• No route to host — маршрут может выглядеть «как будто есть», но доставка невозможна из-за L2/L3 причин: ARP/neighbor в FAILED/INCOMPLETE, next-hop не достижим, ядро/файрволл дропает трафик, срабатывает reverse path filtering (rp_filter), либо прилетает ICMP unreachable от промежуточного узла.

Практический подход одинаковый: быстро локализуем слой (маршрут/правила, L2-соседство, фильтры), затем подтверждаем гипотезу трассировкой и захватом трафика.

Короткая памятка: что проверять в каком порядке

Если нужно «в бой» без долгих рассуждений — следуйте порядку. Он экономит время при инцидентах.

1. Состояние интерфейсов и адресов: ip link, ip addr.

2. Маршрут «как ядро его видит»: ip route get (при необходимости с from и iif).

3. Policy routing: ip rule и таблицы ip route show table ....

4. ARP/neighbor: ip neigh (нет ли next-hop в FAILED/INCOMPLETE).

5. rp_filter и асимметрия: sysctl net.ipv4.conf.*.rp_filter.

6. Фильтрация: nft/iptables + счётчики, точечное логирование.

7. Подтверждение пакетами: traceroute и tcpdump на нужном интерфейсе.

Шаг 1. Проверяем интерфейс, адрес и шлюз: «есть куда отправлять?»

Банально, но часто причина в том, что интерфейс down, адрес не поднят, или проверка идёт «с не того» IP.

ip -br link
ip -br addr

Типовые красные флаги:

• Интерфейс в состоянии DOWN или LOWERLAYERDOWN.

• Нет адреса в нужной подсети.

• Адрес есть, но маска/префикс неверные (например, /32 вместо /24 или наоборот).

Дальше проверяем маршруты по умолчанию и специфические сети:

ip route show
ip route show table main

Если это сервер в облаке, отдельное внимание — корректности шлюза и тому, что он действительно доступен в вашей L2/L3 схеме (особенно при дополнительных IP или нескольких uplink).

Шаг 2. ip route get — самый быстрый способ понять, как ядро поведёт пакет

Команда ip route get отвечает на вопрос «куда и через какой интерфейс ядро отправит пакет». Это быстрее и точнее, чем гадать по выводу ip route.

ip route get 1.1.1.1
ip route get 203.0.113.10

Если у вас несколько адресов/интерфейсов и включён policy routing, моделируйте реальный исходный адрес:

ip route get 203.0.113.10 from 198.51.100.20

А для сценариев «маршрутизация по входящему интерфейсу» (например, на роутере/шлюзе) добавляйте iif:

ip route get 203.0.113.10 iif eth1 from 10.10.10.2

Что должно насторожить:

• RTNETLINK answers: Network is unreachable — почти всегда нет маршрута в той таблице, куда вас увёл ip rule.

• Неожиданный dev (пакет уходит не через тот интерфейс).

• Неожиданный src — частый корень проблем с обратным трафиком и rp_filter.

Шаг 3. Таблицы маршрутизации и метрики: где реально ищется маршрут

Когда появляется Network is unreachable, задача №1 — понять, в какой таблице идёт поиск и есть ли там нужный маршрут.

ip rule show
ip route show table main
ip route show table default
ip route show table local

Если в ip rule есть правила на кастомные таблицы (например, 100/200), проверяйте и их:

ip route show table 100
ip route show table 200

Частая ошибка: правило ip rule отправляет поиск в таблицу, где есть только default, но нет on-link маршрутов к локальным подсетям (или наоборот). В итоге часть направлений работает, часть — «не достижима», и это выглядит как «плавающая» проблема.

Метрики и «не тот default»

Если в системе два дефолта (две uplink-сети), решает метрика. Проверьте:

ip route show default

Неправильная метрика может не дать явного Network is unreachable, но приведёт к уходу трафика «не туда», асимметрии и последующим проблемам с фильтрацией и neighbor.

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

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

Подробнее

Шаг 4. Policy routing (ip rule): когда маршруты есть, но выбирается «не та» таблица

Policy routing — это когда выбор таблицы маршрутизации зависит от источника, fwmark, входящего интерфейса и т.д. Мощно и опасно: одна лишняя строчка в ip rule превращает «всё работало» в «Network is unreachable».

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

ip rule show

Дальше — проверяем «реальный» поиск маршрута под нужным src:

ip route get 8.8.8.8 from 198.51.100.20

Типовой кейс: у сервера два IP на разных интерфейсах, а ответы уходят через другой uplink. Клиент видит таймауты, а на сервере периодически всплывает No route to host при попытке установить соединение или ответить с «не того» адреса.

Если у вас как раз несколько внешних адресов, полезно также посмотреть практику контроля исходящих SNAT/маршрутов в статье SNAT и контроль исходящего IP в nftables при нескольких адресах.

Практический шаблон: отдельная таблица для каждого исходного IP

Ниже пример логики (адаптируйте адреса/шлюзы под себя):

ip route add default via 198.51.100.1 dev eth0 table 100
ip route add 198.51.100.0/24 dev eth0 table 100
ip rule add from 198.51.100.20/32 lookup 100 priority 1000

Ключевой момент: в таблице должны быть не только default-маршрут, но и on-link маршрут к подсети, где находится gateway. Без этого next-hop легко становится «недостижимым», и вы ловите ошибки, похожие на отсутствие маршрута.

Шаг 5. ARP и neighbor table: когда L3 маршрут есть, но next-hop недоступен

Если ip route get показывает корректный маршрут, а соединение всё равно падает с No route to host или таймаутами — смотрим соседей.

ip neigh show
ip neigh show dev eth0

Быстрая интерпретация состояний:

• REACHABLE или STALE — чаще всего нормально.

• INCOMPLETE — ARP-запросы уходят, ответа нет (VLAN/свитч/порт/фильтрация, неверная подсеть, проблемы у соседнего узла).

• FAILED — сосед недоступен, ядро перестало пытаться.

Точечно проверьте именно next-hop (шлюз из маршрута):

ip route show default
ip neigh show to 198.51.100.1

Для быстрой «перезагрузки» записи соседа:

ip neigh del 198.51.100.1 dev eth0

Если после удаления снова INCOMPLETE, это не «кэш», а реальная проблема доставки ARP.

ARP и несколько IP на одном L2: когда отвечает не тот интерфейс

Если на сервере несколько интерфейсов в одной L2-зоне или несколько подсетей поверх одного L2, ARP легко становится источником хаоса: соседние узлы «учатся» не тем MAC, ответы уходят через другой интерфейс, появляются странные периодические обрывы.

В таких случаях смотрят в сторону arp_filter, arp_ignore, arp_announce. Но до подкрутки sysctl убедитесь, что схема действительно требует такой адресации: часто проще развести сети (VLAN/VRF) или привести конфигурацию к однозначной.

Шаг 6. Reverse path filtering (rp_filter): частая причина «плавающих» проблем при multi-homing

rp_filter (reverse path filtering) — защита от спуфинга: ядро проверяет, что «обратный маршрут» к источнику пакета совпадает с тем интерфейсом, на который пакет пришёл. При асимметричной маршрутизации это ломает легитимный трафик.

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

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

Значения обычно такие:

• 0 — выключено.

• 1 — strict (жёстко, часто ломает policy routing и multi-uplink).

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

Если у вас policy routing по source IP или два uplink’а, strict-режим rp_filter=1 — один из первых подозреваемых. Но выключать защиту полностью стоит только осознанно и вместе с внятной фильтрацией на границе.

Временное изменение (до перезагрузки):

sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Дальше перепроверьте ip route get ... from ... и реальный трафик через tcpdump, чтобы убедиться, что проблема действительно была в RPF.

Шаг 7. traceroute: где именно «пропадает» маршрут

traceroute полезен, когда нужно понять: пакет не выходит с хоста или теряется дальше. На серверах часто удобно:

traceroute -n 203.0.113.10
traceroute -n -T -p 443 203.0.113.10

Нюанс: классический UDP traceroute может быть фильтрован, а TCP traceroute на порт сервиса (например, 443) часто показывает более приближенную к продакшену картину.

Шаг 8. tcpdump: подтверждаем гипотезу пакетами

Когда непонятно, проблема в ARP, маршруте или firewall, смотрим пакеты на нужном интерфейсе.

Проверка ARP к шлюзу:

tcpdump -ni eth0 arp and host 198.51.100.1

Проверка, уходит ли трафик к цели и приходят ли ответы:

tcpdump -ni eth0 host 203.0.113.10
tcpdump -ni eth0 tcp and host 203.0.113.10 and port 443

Типовая интерпретация:

• Есть исходящие SYN, но нет SYN-ACK — ответ не возвращается (маршрут у той стороны/асимметрия), либо фильтрация по пути, либо вы отправляете «не с того» IP.

• Нет даже исходящих пакетов — проблема локальная (маршрутизация/правила, firewall OUTPUT, интерфейс, neighbor).

• ARP-запросы есть, ARP-ответов нет — фокус на L2, VLAN, anti-spoofing/port security, неправильный gateway.

Если у вас поверх всего этого ещё и VPN-стыки между площадками, удобно сверять маршруты и асимметрию по конфигурации туннеля; см. site-to-site на WireGuard: маршруты и диагностика.

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

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

Подробнее

Типовые сценарии и быстрые решения

1) Нет default route или он в «не той» таблице

Симптом: Network is unreachable на любые внешние адреса.

ip route show default
ip rule show

Решение: добавить или исправить default в нужной таблице и убедиться, что правило ip rule реально ведёт туда, где этот default есть.

2) Policy routing есть, но забыли on-link маршрут к подсети gateway

Симптом: маршрут по умолчанию в таблице присутствует, но next-hop «не резолвится» на L2, появляются unreachable/таймауты.

Решение: в policy-таблице добавить маршрут к подсети интерфейса (или host-route к самому gateway), затем перепроверить ip route get.

3) rp_filter режет входящий трафик при асимметрии

Симптом: часть соединений проходит, часть нет; при смене исходного IP всё «магически» меняется; в логах firewall пусто.

Решение: перевести rp_filter в loose (2) на нужных интерфейсах или пересобрать policy routing так, чтобы обратный маршрут совпадал.

4) Neighbor table в FAILED или INCOMPLETE

Симптом: до шлюза/соседа не достучаться, в tcpdump нет ARP-ответов.

Решение: проверить L2 (VLAN/порт), правильность адресации/маски, антиспуфинг у провайдера/виртуализации, отсутствие конфликтов IP/MAC. На время диагностики сбросить запись: ip neigh del ... и посмотреть повтор.

Чек-лист для фикса и постмортема

• Зафиксируйте выводы: ip -br addr, ip rule, ip route show table main и все кастомные таблицы.

• Сохраните пример ip route get ... from ... для «правильного» и «ломающегося» случая.

• Если виноват rp_filter — задокументируйте, почему допустима асимметрия и чем она компенсируется (фильтрация, anti-spoofing на границе).

• Если виноват ARP/neighbor — проверьте дубли IP, корректность VRRP/keepalived, настройки bridge/OVS, облачные правила фильтрации.

Мини-лаборатория: как воспроизвести и научиться читать симптомы

Чтобы уверенно диагностировать такие ошибки на проде, полезно один раз «пощупать руками» в тестовой среде.

• Сделайте два интерфейса с разными uplink и настройте policy routing по source.

• Включите rp_filter=1 и посмотрите, как ломается входящий трафик при асимметрии.

• Намеренно сломайте ARP (неправильная маска или шлюз) и посмотрите на ip neigh и tcpdump с фильтром по ARP.

После этого фразы No route to host и Network is unreachable перестанут быть «магией» и станут указателями на конкретный слой проблемы.

Итоги

Ошибки No route to host и Network is unreachable в Linux чаще всего сводятся к трём зонам: (1) маршруты и ip rule (policy routing), (2) L2-соседство и ARP/neighbor table, (3) фильтрация и reverse path filtering (rp_filter). Самые полезные инструменты для быстрого ответа «что происходит» — ip route get, ip rule, ip neigh, traceroute и tcpdump. С ними вы не угадываете, а проверяете.

Если вы поднимаете такие схемы на сервере с несколькими IP/сетями, удобнее делать это на VDS, где вы полностью контролируете сетевую конфигурацию и можете аккуратно воспроизвести кейс в тесте перед продом.