Основные причины ошибки «No route to host»

Когда приложение не может подключиться к серверу, No route to host часто ошибочно воспринимают как проблему самого сервера. На деле причина может находиться на любом участке маршрута.

1️⃣На хосте нет маршрута

Linux должен понимать, через какой интерфейс и gateway отправлять пакет. Проверить конкретный маршрут можно:

ip route get 10.10.20.15

Если подходящего маршрута нет, пакет не будет отправлен.

2️⃣ Неправильная маска или gateway

Например, сервер считает адрес назначения локальным из-за неправильной маски и пытается найти его через ARP вместо отправки на маршрутизатор.
Проверить:

ip addr
ip route

3️⃣ Проблема с ARP

Маршрут может существовать, но следующий hop не отвечает на ARP-запросы:

ip neigh

Если рядом с адресом появляется:

FAILED
INCOMPLETE

хост не смог разрешить IP в MAC.

4️⃣ Firewall возвращает ICMP unreachable

No route to host не всегда означает, что маршрута действительно нет. Firewall может отправить ICMP Destination Host Unreachable, после чего приложение получит именно такую ошибку.
Проверить правила:

sudo nft list ruleset

5️⃣ Маршрутизатор не знает путь дальше

Ваш сервер может иметь правильный default route, но следующий маршрутизатор не обязан знать, где находится сеть назначения.
Проверить путь:

traceroute -n 10.10.20.15

6️⃣ Обратный маршрут сломан

Пакет может успешно дойти до сервера, но ответ пойдет через другой маршрут или вообще не найдет пути обратно.
На сервере полезно проверить:

ip route get <IP-клиента>

Особенно часто это проявляется при нескольких интерфейсах, VRF или policy routing.

7️⃣ Маршрут есть, но интерфейс фактически не работает

Например, в таблице:

10.10.20.0/24 dev eth1

но сам eth1 находится в DOWN или физический линк не поднят.
Проверить:

ip link show eth1

Поэтому No route to host лучше читать не как «сервер недоступен», а как «на этом этапе сеть не смогла доставить пакет дальше». Сначала смотрим маршрут, затем next-hop, ARP и уже после этого разбираемся с firewall и удалённым хостом.

N.A.

Почему SSL/TLS соединения падают при смене времени

Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake.

Основная причина в том, что TLS строго проверяет время: если системные часы сервера или клиента сильно отстают или опережают реальное время, сертификаты могут считаться просроченными или ещё не действительными.

⏺Ещё одна частая причина - неправильно настроенный NTP. Без синхронизации часы расходятся, и handshake с клиентом завершается с ошибкой.

Иногда сбои связаны с expired сертификатами, которые дополнительно усугубляют проблему, особенно на новых соединениях.

Как проверить

show ntp status

Проверка синхронизации времени на сетевых устройствах.

date

Смотрим системное время на сервере.

openssl s_client -connect <host>:443

Анализ TLS handshake и проверки сертификатов.

timedatectl

Проверка часового пояса и синхронизации на Linux.

show logging | include NTP

N.A.

XDP/eBPF для QoS: приоритизация UDP-трафика в Linux

В реальном времени аудио и видео сильно чувствительны к задержкам и джиттеру.

Даже небольшие перегрузки сети могут испортить VoIP или RTP-поток.

XDP — это точка входа пакета в Linux, прямо в драйвере NIC. eBPF-программа, загруженная в XDP, может:

➖маркировать пакеты (skb->mark) для последующей обработки tc/qdisc
➖отбрасывать или редиректить трафик
➖собирать статистику по IP, портам или протоколам

В связке с tc или iptables можно реализовать приоритизацию UDP-трафика для VoIP/RTP без изменения приложений.

⏺Например: приоритизация UDP-порта 5004 (RTP) и сбор статистики

Создаём простую eBPF карту для подсчёта пакетов по IP/портам:

struct bpf_map_def SEC("maps") packet_count = {
.type = BPF_MAP_TYPE_HASH,
.key_size = sizeof(struct flow_key),
.value_size = sizeof(__u64),
.max_entries = 1024,
};

В XDP-программе проверяем порт и увеличиваем счётчик:

if (udp->dest == bpf_htons(5004)) {
__u64 *cnt, zero = 0;
cnt = bpf_map_lookup_elem(&packet_count, &key);
if (!cnt)
bpf_map_update_elem(&packet_count, &key, &zero, BPF_NOEXIST);
else
__sync_fetch_and_add(cnt, 1);

skb->mark = 46; // DSCP EF для QoS
}

Загружаем XDP на интерфейс:

ip link set dev eth0 xdp obj rtp_qos.o sec xdp

Проверяем статистику через bpftool:

bpftool map dump id <map_id>

Теперь все RTP-пакеты маркируются для максимального приоритета, а количество пакетов можно отслеживать в реальном времени.

N.A.

TCP-флаги, которые нельзя блокировать бездумно

Фильтровать TCP-флаги кажется удобным способом усилить firewall: разрешить только «нормальные» пакеты и всё остальное отбросить.
Но некоторые флаги участвуют не только в установлении соединения, и их бездумная блокировка может ломать уже работающие TCP-сессии.

⏺SYN - установка соединения

Без SYN новый TCP-сеанс просто не начнётся:

Client → SYN → Server
Client ← SYN/ACK ← Server
Client → ACK → Server

Если firewall отбрасывает входящие SYN, сервер не сможет принимать новые TCP-соединения.

⏺ACK - подтверждение данных

ACK встречается практически во всём нормальном TCP-трафике после установки соединения.
Например:

Client → PSH, ACK
Server → ACK

Правило вида:

iptables -A INPUT -p tcp ! --tcp-flags ACK ACK -j DROP

может выглядеть логично, но нельзя просто считать отсутствие ACK признаком атаки: SYN-пакет нового соединения как раз приходит без ACK.
Поэтому обычно проверяют состояние соединения через conntrack, а не только наличие флага.

⏺RST - аварийное закрытие

RST сообщает другой стороне, что TCP-соединение больше не существует.
Например, приложение не слушает порт:

Client → SYN → Server
Client ← RST ← Server

Если firewall блокирует RST без понимания контекста, клиент может вместо быстрого отказа получить долгий timeout.
RST также используется для завершения некоторых некорректных или уже несуществующих соединений.

⏺FIN - нормальное закрытие

FIN означает: «я больше не буду отправлять данные».

Client → FIN, ACK
Server → ACK
Server → FIN, ACK
Client → ACK

Блокировка FIN может превращать нормальное закрытие соединения в зависание до срабатывания timeout.

⏺Что делать вместо фильтрации отдельных флагов

Для stateful firewall обычно правильнее разрешать уже установленные соединения:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

А новые подключения контролировать отдельно:

iptables -A INPUT -p tcp --dport 22 \
    -m conntrack --ctstate NEW -j ACCEPT

То есть проверять не просто «какие TCP-флаги приехали», а в каком состоянии находится соединение.

Особенно опасны универсальные правила вроде:

-p tcp --tcp-flags ALL NONE -j DROP
-p tcp --tcp-flags ALL ALL -j DROP

Они действительно могут отсеивать часть мусорного трафика, но сами по себе не являются полноценной защитой TCP.

N.A.

Почему новые соединения идут по старому маршруту

После изменения маршрута можно увидеть странную ситуацию: ip route уже показывает новый путь, но существующее TCP-соединение продолжает работать через старый.
Это нормально.

⏺Маршрут не пересчитывается как отдельное решение для каждого TCP-сеанса
Когда приложение открывает соединение, ядро выбирает маршрут для этого потока. Дальше пакеты существующего соединения обрабатываются с учётом уже созданного состояния.
Поэтому изменение:

ip route replace default via 192.168.1.1

не означает, что все уже установленные TCP-соединения мгновенно начнут использовать новый gateway.

⏺Особенно заметен conntrack

На firewall или NAT устройство хранит состояние соединения:
conntrack -L
Там может находиться запись ESTABLISHED, по которой последующие пакеты распознаются как часть уже существующего потока.
Это особенно важно при NAT: кроме маршрута существует ещё состояние трансляции адресов и портов.
⏺Новые соединения уже могут пойти иначе
После изменения маршрута:

ip route get 8.8.8.8

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

⏺Почему это важно при переключении каналов
При аварийном переключении WAN недостаточно просто заменить default route.
Старые TCP-сессии могут продолжать использовать прежнее состояние, а NAT/Firewall может дополнительно удерживать их до таймаута.

Из-за этого после failover часто наблюдается:

новые подключения → работают
старые подключения → timeout

И это не обязательно означает, что новый маршрут настроен неправильно.

Проверять нужно сразу несколько вещей:

ip route get <destination>
sudo conntrack -L
ss -nt

N.A.

Как проверить, что BGP-маршрут анонсируется, но не используется

Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.

Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.

1️⃣Проверяем, что маршрут вообще пришёл по BGP

Сначала убеждаемся, что апстрим реально его отдал.

Cisco:

show ip bgp <prefix>

Важно смотреть:
• есть ли несколько путей
• какой помечен как *> (best)

Если маршрута нет, дальше можно не копать.

2️⃣Сравниваем BGP vs routing table

Маршрут может быть в BGP, но не установлен в основную таблицу.

show ip route <prefix>

Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции.

Смотрим атрибуты best path

Часто маршрут есть, но проигрывает по атрибутам.

show ip bgp <prefix>

Обращаем внимание на:
⏺Local Preference (самая частая причина)
⏺AS_PATH (длиннее — хуже)
⏺MED
⏺Weight (Cisco)

Даже разница в LocalPref 100 vs 200 полностью меняет путь.

4️⃣Проверяем policy: route-map / filter

Маршрут может быть принят, но «искажён» политикой.

show run | section route-map
show ip bgp neighbors <IP> received-routes

Иногда route-map не режет маршрут, но меняет LocalPref или MED.

5️⃣Проверяем CEF / FIB

Бывает, BGP и RIB ок, а в forwarding таблице другое.

show ip cef <prefix>

Если next-hop не тот, что ожидается — проблема на этапе установки в FIB.

N.A.

DROP и REJECT делают одно и то же?

Нет. Оба блокируют трафик, но клиент получает совершенно разный результат.

⏺DROP просто выбрасывает пакет:

iptables -A INPUT -p tcp --dport 22 -j DROP

Клиент отправляет SYN, но в ответ ничего не приходит:

client → SYN → server
client ← ... ← timeout

TCP будет повторять попытки, пока не истечёт timeout.

⏺REJECT блокирует соединение и отправляет ответ:

iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset

Теперь клиент получает RST и сразу понимает: соединение отвергнуто.

client → SYN → server
client ← RST ← server

Поэтому поведение приложения будет разным:
DROP → «сервер молчит»
REJECT → «сервер отказал»

Это важно и для диагностики. Если всё дропать, ошибка часто выглядит как timeout, хотя проблема на самом деле в firewall.

Для ICMP-трафика REJECT может отправить ICMP unreachable вместо TCP RST.

И ещё момент: DROP не делает систему «более защищённой» автоматически. Он просто не сообщает отправителю, что пакет был отвергнут.

N.A.

OSPF Full означает, что маршрут уже появился?

Нет.

Состояние Full говорит только о том, что два OSPF-соседа синхронизировали LSDB.

Например:

R1 ─── R2
     Full

Но это ещё не гарантирует, что конкретный prefix попадёт в routing table.

Проверяем соседство:

show ip ospf neighbor

Видим:

Neighbor   State
10.0.0.2   FULL

Теперь проверяем маршрут:

show ip route 10.10.10.0

И его может не быть.
Почему?

OSPF сначала получает информацию о топологии, а потом SPF и другие проверки решают, какие маршруты установить в RIB.

Например, prefix может быть в LSDB:

show ip ospf database

но не установиться в таблицу из-за:

⏺недоступного next-hop ⏺невалидного LSA ⏺лучшего маршрута из другого источника ⏺особенностей area / route type ⏺фильтрации или policy

Поэтому при проблеме нельзя останавливаться на:

OSPF = FULL

Нужно проверить всю цепочку:

Neighbor → LSDB → SPF → RIB

N.A.

ARP vs NDP: почему IPv6 не использует broadcast

IPv4 и IPv6 должны узнать MAC-адрес соседа. Кажется, что механизм должен быть одинаковым.

Но в IPv4:

ARP Request → broadcast → ff:ff:ff:ff:ff:ff

В IPv6 ARP вообще нет.
Для этого используется NDP поверх ICMPv6.

Когда узлу нужен MAC соседа, он отправляет Neighbor Solicitation на специальный multicast-адрес, связанный с IPv6-адресом назначения:

ip -6 neigh

Можно увидеть:

fe80::20c:29ff:fe12:3456 dev eth0 lladdr 00:0c:29:12:34:56 REACHABLE

Главное отличие:

ARP  → broadcast
NDP  → multicast

Поэтому IPv6 не должен будить весь L2-сегмент ради поиска одного соседа.

И это не просто замена ARP на другой пакет. NDP также используется для:

⏺обнаружения соседей ⏺проверки доступности ⏺определения router’ов ⏺автоматической настройки адресов

N.A.

Почему jumbo frames включили, а производительность не выросла

Jumbo frames это MTU 9000 вместо стандартных 1500. Меньше заголовков на байт данных, меньше прерываний CPU. В теории быстрее, на практике часто никакого эффекта.

⏺Самая частая причина: один интерфейс или коммутатор на пути со стандартным MTU.

Пакеты фрагментируются или дропаются, выигрыша нет. Jumbo frames работают только если все устройства end-to-end настроены одинаково.

Проверяем что путь реально поддерживает 9000:

ping -M do -s 8972 <IP>

8972 это 9000 минус 28 байт заголовков. Если пакет прошёл, путь чистый.

⏺Вторая причина: приложение шлёт маленькими чанками. Jumbo frames помогают только когда есть что класть в большой пакет. Мелкие запросы останутся мелкими пакетами независимо от MTU.

⏺Третья: узкое место вообще не в сетевом стеке. Jumbo frames снижают CPU overhead от обработки пакетов, но если bottleneck в диске или логике приложения, результата не будет.

mpstat -I ALL 1
ethtool -S eth0 | grep rx_packets

⚡️Реально помогает в узких сценариях: iSCSI, NFS, HPC, высоконагруженные линки между серверами в одном датацентре. В смешанном трафике через разные устройства эффект минимальный.

N.A