Когда на сервере несколько интерфейсов, default route, policy routing или несколько IP, вывод
ip route быстро перестаёт быть очевидным.Например:
ip route
показывает:
default via 192.168.1.1 dev eth0
10.10.0.0/16 dev eth1
Но это ещё не означает, что любой пакет к
10.10.20.5 пойдёт через eth1. На выбор могут влиять ip rule, source address, fwmark и другие параметры.ip route get 10.10.20.5
Например:
10.10.20.5 via 192.168.1.1 dev eth0 src 192.168.1.20
Здесь уже видно конкретное решение:
•
via - через какой gateway;•
dev - какой интерфейс;•
src - какой исходный IP Linux выберет для пакета.Это отличается от простого просмотра таблицы маршрутов:
ip route get рассчитывает маршрут для конкретного назначения.На сервере может быть несколько адресов:
ip route get 10.10.20.5 from 10.10.30.15
Теперь kernel рассчитывает маршрут так, будто пакет отправляется именно с
10.10.30.15.Это позволяет найти ситуации, когда приложение использует конкретный source IP и из-за этого получает другой маршрут.
Если используются
ip rule и несколько routing tables:ip rule
может быть:
0: from all lookup local
100: from 10.10.30.0/24 lookup 100
32766: from all lookup main
Тогда:
ip route get 8.8.8.8 from 10.10.30.15
и:
ip route get 8.8.8.8 from 192.168.1.20
могут вернуть совершенно разные интерфейсы.
⏺Можно проверить fwmark
Если маршрутизация зависит от марки пакета:
ip route get 8.8.8.8 mark 100
Так можно проверить, какой маршрут будет выбран для трафика с конкретной
fwmark.ip route
ip rule
и пытаются вручную восстановить логику маршрутизации.
ip route get позволяет задать конкретные условия и получить фактический результат работы routing stack:destination + source + mark → gateway + interface + source IP
Особенно полезно при диагностике asymmetric routing, нескольких uplink, VRF и Policy-Based Routing.
ip route get показывает, какое решение примет Linux, но не гарантирует, что пакет физически уйдёт именно так. После выбора маршрута ещё могут вмешаться firewall, NAT, tc, network namespace и другие механизмы обработки пакета.

