Сервис на одном хосте не может подключиться к сервису в другой подсети, при этом ping до шлюза проходит. Как диагностировать проблему с таблицей маршрутизации?

Короткий ответ

Нужно проверить таблицу маршрутизации командой ip route и убедиться, что есть маршрут (явный или через default gateway) до целевой подсети, а также проверить, что шлюз, через который должен идти трафик, сам знает маршрут до назначения и не блокирует трафик правилами файрвола.

Как это работает подробнее

Каждый пакет, отправляемый на адрес вне локальной подсети, ядро направляет согласно таблице маршрутизации, выбирая наиболее специфичный подходящий маршрут (longest prefix match); если подходящего маршрута нет и нет default gateway (0.0.0.0/0), пакет не будет отправлен вообще; если маршрут до шлюза есть, но сам шлюз не имеет обратного маршрута к отправителю или блокирует трафик, пакеты уходят, но ответы не возвращаются, что выглядит как зависшее соединение, а не явная ошибка.

Пример кода

commands.shКопировать

ip route
ip route get 10.20.30.5
traceroute 10.20.30.5

Что использовать на практике

• Практика. диагностику ведут пошагово: ip route get <целевой IP> покажет, какой маршрут и интерфейс ядро выберет для конкретного адреса; traceroute покажет, где именно трафик перестаёт продвигаться; также стоит проверить правила iptables/nftables на хосте и на промежуточных узлах (NAT, файрволы), поскольку маршрут может существовать, но трафик всё равно блокируется политикой безопасности.

Подводные камни

• Риск. Частая ошибка — ограничиваться проверкой ping только до ближайшего шлюза и делать вывод 'сеть в порядке', не проверив маршрут именно до целевой подсети и не учитывая, что ICMP может проходить, а TCP-трафик — блокироваться отдельным правилом файрвола.