Таблица маршрутов: смотрим, куда реально уходит трафик

linuxvsem

Участник

сообщений 830
с июл

15 ноября, 14:22первое сообщение

На сервере две сетевые карты и поднят туннель. Половина запросов уходит одной дорогой, половина другой, и я не могу поймать закономерность. Читать вывод ip route глазами уже устал: там семь строк, и какая из них сработает для конкретного адреса, неочевидно.

Есть способ спросить у ядра прямо: вот адрес, покажи, куда пойдёт пакет?

iron_shell

Знаток

сообщений 1050
с июн

22 апреля, 17:39#2

Есть, и он однострочный.

ip route get 93.184.216.34

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

linuxvsem

Участник

сообщений 830
с июл

1 сентября, 08:56#3

О, вот этого мне и не хватало. Проверил, для внешних адресов уходит через eth1, а я думал, что через туннель.

Костя Фомин

Знаток

сообщений 1600
с апр

8 февраля, 11:13#4

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

Строка	Длина префикса	Метрика	Когда сработает
default via 10.0.0.1 dev eth0	0	100	если ничего другого не подошло
default via 10.0.5.1 dev eth1	0	50	выигрывает у первой по метрике
93.184.0.0/16 dev tun0	16	0	для своего куска бьёт обе default

dev_null_ru

Ветеран

сообщений 2560
с фев

15 июля, 14:30#5

Добавлю про грабли, на которых сидит половина тех, кто ставит туннель на сервер.

Таблица не одна. Кроме main есть local, default и всё, что накидали программы поверх. И до таблиц ядро ещё смотрит правила, там свой порядок с номерами. Туннельный клиент часто main не трогает вовсе и вешает своё правило с приоритетом ниже, и тогда ip route show показывает картину, которая к делу отношения не имеет.

ip rule show
ip route show table all

Первая команда покажет очередь правил, вторая всё содержимое всех таблиц. Если в выводе ip rule появились строки с номерами вроде 32764 и с пометкой fwmark, значит трафик делит тут работают метки на пакетах, таблица маршрутов ни при чём, и разбираться нужно уже в правилах брандмауэра.

linuxvsem

Участник

сообщений 830
с июл

22 декабря, 17:47#6

dev_null_ru: вешает своё правило с приоритетом ниже

Точно оно. Два правила с fwmark, я их в упор не видел, потому что смотрел только main.

mila_ops

Новичок

сообщений 175
с апр, второй сезон

1 мая, 08:04#7

подскажите, а на маке эти команды работают? у меня ip route ругается что нет такой команды

Денис Прошин

Знаток

сообщений 1000
с июн

8 октября, 11:21#8

На macOS другой набор. Смотреть так:

netstat -rn
route -n get 93.184.216.34

Вторая выдаст интерфейс и шлюз для конкретного адреса, ближайший родственник вашей ip route get.

byteflow

Новичок

сообщений 225
с фев, второй сезон

15 марта, 14:38#9

И под Windows тоже своё, если кому пригодится: route print покажет таблицу целиком, а Find-NetRoute -RemoteIPAddress 93.184.216.34 вернёт выбранную строку плюс адрес источника. Вторая команда живёт в PowerShell.

Костя Фомин

Знаток

сообщений 1600
с апр

22 августа, 17:55#10

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

linuxvsem

Участник

сообщений 830
с июл

1 января, 08:12#11

Собрал у себя порядок разбора, оставлю тут, чтобы не искать заново:

ip route get АДРЕС даёт ответ по конкретному адресу за секунду;
если ответ странный, следом ip rule show, вдруг делят метками;
ip route show table all показывает то, чего нет в main;
поле src в выводе говорит, каким адресом машина представится наружу.

У меня в итоге туннель забирал только свою подсеть, а весь сбор шёл мимо него через eth1. Поправил правило, теперь всё предсказуемо. Спасибо всем.