Помогите разобраться с маршрутизацией

Когда сервер просто пытается установить соединение (не указав с какого адреса идти), то адрес выбирается исходя из маршрутов в main и только из этих маршрутов. У вас в main только default или ещё что?

Хотя может я не правильно понял проблему. Как у вас сервер напрямую отправялет пакет на клиента в обход кинетика?

Есть 2 ситуации: Если на сервере нет vlan 100 с IP 192.168.100.3 то пакет адресованный 192.168.101.1 от 192.168.100.10 идет через кинетик и приходит к 101.1 и таким же маршрутом идет назад. Если на сервере поднять интерфейс ens3.100 c IP 192.168.100.3, то у сервера в таблице arp появляется запись 192.168.100.10 и пакет он отправит напрямую к 100.10 минуя кинетик.

Изначально только default.

Честно не распарсил, но в небо, ip rule add to 192.168.100.0/24 table isp2

Я не понял. Вы создаёте интерфейс ens3.100 с 192.168.100.3/24, но почему-то пакеты для 192.168.100.10/? должны ходить не через этот интерфес?

Я хочу, что бы сервер вернул пакет по тому же маршруту, что и пришел пакет, а не отправлял его более прямым маршрутом.

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

Я и написал, что все не распарсил, но если продолжать костылестроением ip rule add to 192.168.100.3 table main
Это правило должно быть по приоритету выше чем написанное мной выше.

Тогда к PBR нужно добавлять маркировку пакетов через MARK+CONNMARK, а таблицу маршрутизации выбирать по ip rule fwmark. Задача типовая, гуглится, но много действий и сложнее, чем просто маршрутизация.

Да ладно, а как же

ip ru add to

?

Прописал ip rule add to 192.168.100.3 table main Затем ip rule add to 192.168.100.0/24 table isp2 Но 192.168.100.10 я не пингую. При этом с сервера до хоста 192.168.100.253 все нормально идет через кинетик. [code] traceroute to 192.168.100.253 (192.168.100.253), 30 hops max, 60 byte packets 1 border.home (192.168.101.254) 0.832 ms 0.529 ms 0.332 ms 2 nas.home (192.168.100.253) 0.738 ms 0.641 ms 0.484 ms root@ns:~# traceroute 192.168.100.10 traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets 1 border.home (192.168.101.254) 2.448 ms 2.183 ms 2.088 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 *^C root@ns:~# [/code] У всех хостов из 100 подсети шлюз 192.168.100.254.

[code] root@ns:~# ip ru 0: from all lookup local 1000: from all to 192.168.100.3 lookup main 32764: from all to 192.168.100.0/24 lookup isp2 32765: from all to 192.168.100.3 lookup main 32766: from all lookup main 32767: from all lookup default root@ns:~# ip route flush cache root@ns:~# traceroute 192.168.100.10 traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets 1 border.home (192.168.101.254) 0.808 ms 0.670 ms 0.439 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 *^C root@ns:~# traceroute 192.168.100.253 traceroute to 192.168.100.253 (192.168.100.253), 30 hops max, 60 byte packets 1 border.home (192.168.101.254) 1.018 ms 0.745 ms 0.657 ms 2 nas.home (192.168.100.253) 0.994 ms 0.905 ms 0.786 ms root@ns:~# [/code]

Поправьте разметку.

anc, он уже не сможет поправить, вы же ответили на его сообщение.

Автор, по умолчанию используется маркдаун разметка.

net.ipv4.conf.all.rp_filter тут не поможет ?

@anc, он уже не сможет поправить, вы же ответили на его сообщение.

Я в курсе, но ничто не мешает запостить ещё раз с нормальной разметкой. То что ТС умеет пользоваться разметкой это видно из ОП, просто видимо погорячился :)

Нет.

«ru» «add» «to» бесполезны для гугленья. Если вы желаете расписывать полностью все правила, реализующие прохождение ответных пакетов через тот же интерфес, что и входящих пакетов, то действуйте, но пишите ТС, а не мне. Мне такую кучу строк писать лень, подобная задача решалась неоднократно, можно найти.

Я имел в виду следующее. Ваша фраза в корне неверна:

Когда сервер просто пытается установить соединение (не указав с какого адреса идти), то адрес выбирается исходя из маршрутов в main и только из этих маршрутов.

Вот пруф.

Посмотрим , через что мы роутим по дефолту… Через обычный шлюз.

root@tamil [~/syncthing-cli] # ip ro get 1.1.1.1
1.1.1.1 via 10.0.2.2 dev enp0s3 src 10.0.2.15 uid 0 
    cache 

Ок, добавим правило типа to X на таблицу 500, и запретим там все, и попробуем попинговать целевой хост..

root@tamil [~/syncthing-cli] # ip ru add to 1.1.1.1 tab 500

root@tamil [~/syncthing-cli] # ip ro add  prohibit default tab 500

root@tamil [~/syncthing-cli] # ping 1.1.1.1 -c1
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.

Упс, пинги не прошли. Уберем ip rule и попробуем опять.

root@tamil [~/syncthing-cli] # ip ru del to 1.1.1.1 tab 500

root@tamil [~/syncthing-cli] # ping 1.1.1.1 -c1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=66.5 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 66.585/66.585/66.585/0.000 ms

Итак, вывод – командой ip ru можно рулить маршрутизацией, т.е. направлять пакеты в отдельную таблицу маршрутизации. А вы говорите, что только main используется.

то адрес выбирается исходя из маршрутов в main

Здесь речь идёт про адрес, с которого идти, то есть src-ip адрес пакета.

Я не понял ваш пример. Вы мне должны были показать, что ping пошёл с ip-адреса 7.8.9.10, допустим, а не с 10.0.2.15. И, даже не ping, который сам формирует пакет, а что-то типа ssh или wget или dig.

А вы вобще не показали src-адреса исходящих пакетов. И, если будете показывать что-то с src-адресами, покажите, что в iptables/nftables нет NAT-правил и версию ядра.

P.S. Надеюсь, вы понимаете что печатая «ip ru» в делаете ваш пост менее заметным для поиска через гугл?

Прописал ip rule add to 192.168.100.3 table main Затем ip rule add to 192.168.100.0/24 table isp2 Но 192.168.100.10 я не пингую. При этом с сервера до хоста 192.168.100.253 все нормально идет через кинетик.

root@ns:~# traceroute 192.168.100.253
traceroute to 192.168.100.253 (192.168.100.253), 30 hops max, 60 byte packets 
1 border.home (192.168.101.254) 0.832 ms 0.529 ms 0.332 ms 
2 nas.home (192.168.100.253) 0.738 ms 0.641 ms 0.484 ms 
root@ns:~# traceroute 192.168.100.10 
traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets 
1 border.home (192.168.101.254) 2.448 ms 2.183 ms 2.088 ms 
2 * * * 
3 * * * 
4 * * * 
5 * * * 
6 * * * 
7 *^C 
root@ns:~# 

У всех хостов из 100 подсети шлюз 192.168.100.254.

root@ns:~# ip ru 
0: from all lookup local 
1000: from all to 192.168.100.3 lookup main 
32764: from all to 192.168.100.0/24 lookup isp2 
32765: from all to 192.168.100.3 lookup main 
32766: from all lookup main 
32767: from all lookup default 
root@ns:~# ip route flush cache 
root@ns:~# traceroute 192.168.100.10 
traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets 
1 border.home (192.168.101.254) 0.808 ms 0.670 ms 0.439 ms 
2 * * * 
3 * * * 
4 * * * 
5 * * * 
6 * * * 
7 *^C 
root@ns:~# traceroute 192.168.100.253 
traceroute to 192.168.100.253 (192.168.100.253), 30 hops max, 60 byte packets 
1 border.home (192.168.101.254) 1.018 ms 0.745 ms 0.657 ms 
2 nas.home (192.168.100.253) 0.994 ms 0.905 ms 0.786 ms 
root@ns:~# 

Разметку сообщения поправил. Первый пост тоже LORCODE и он нормально отобразился.
to bdfy: rp_filter отключить? Сейчас он включен.
Нашел такую статью https://www.opennet.ru/tips/2009_policy_route_linux.shtml долго вкуривал, но так и не смог адаптировать те решения под свою задачу. У меня gateway у сервера один, можно ему и в 100 подсети шлюз указать, но это не зачем.

Здесь речь идёт про адрес, с которого идти, то есть src-ip адрес пакета.

Мхм, в ip rule он не задается, а только матчится (проверяется на соответствие чтоб направить в соотв. таблицу). Задаваться он может:

• в приложении, которые выплевывает пакет
• в iptables(SNAT)
• если на исходящем интерфейсе 1 ip, то берется он
• если на исходящем интерфейсе более 1 ip, тогда берется ip src, который указан в ip route ... src в соотв. таблице маршрутизации. Больше способов нет!

P.S. Надеюсь, вы понимаете что печатая «ip ru» в делаете ваш пост менее заметным для поиска через гугл?

Тем, кто не осилил ip-route(8) и ip-rule(8), Гугл не поможет.

Вы мне должны были показать, что ping пошёл с ip-адреса 7.8.9.10,

я демонстрировал работу ip rule add to, т.е. проверка матчинга по ip dst host, при этом ip src host не матчится вообще – Опровергая вашу ремарку, что при попытки инициировать коннект локально работает только таблица main.

И, даже не ping, который сам формирует пакет, а что-то типа ssh или wget или dig.

Все утилиты, если автор предусмотрел, умеют формировать src ip. Например curl --interface XXX

А вы вобще не показали src-адреса исходящих пакетов. И, если будете показывать что-то с src-адресами, покажите, что в iptables/nftables нет NAT-правил и версию ядра.

Это была обычная дефолтная виртуалка Ubuntu 18.04 в Virtualbox, без файрволов/таблиц маршрутизации.

пожалуйста в студию:

ip a
ip ru
ip ro
ip ro show tab isp2

ОК, если с такой конфой ты будешь пинговать сервер->192.168.100.10 , то оно должно пойти через таблицу isp2, т.е. через шлюз 192.168.101.254 при этом выберется src ip который висит на ens3 , то есть 192.168.101.1 Можешь проверить tcpdump-ом.

Должно работать. Если нет, то варианты :

• оставить как есть, но добавить iptables -t nat -A POSTROUTING -o ens3 -d 192.168.100.10 -j SNAT --to 192.168.101.1
• убрать default из isp2, заменить на prohibit default, и 192.168.100.10 via 192.168.101.254 src 192.168.101.1 , то есть явно задать только этот IP
• вообще убрать isp2 & очистить ip ru, сделать просто запись в главной таблице: 192.168.100.10 via 192.168.101.254 src 192.168.101.1

Добавил

iptables -t nat -A POSTROUTING -o ens3 -d 192.168.100.10 -j SNAT --to 192.168.101.1

Не могу понять вот этого поведения

root@ns:~# ping 192.168.100.10
PING 192.168.100.10 (192.168.100.10) 56(84) bytes of data.
^C
--- 192.168.100.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 28ms

root@ns:~# ping 192.168.100.253
PING 192.168.100.253 (192.168.100.253) 56(84) bytes of data.
64 bytes from 192.168.100.253: icmp_seq=1 ttl=63 time=0.800 ms
64 bytes from 192.168.100.253: icmp_seq=2 ttl=63 time=0.819 ms
^C
--- 192.168.100.253 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.800/0.809/0.819/0.030 ms
root@ns:~# ping 192.168.100.254
PING 192.168.100.254 (192.168.100.254) 56(84) bytes of data.
64 bytes from 192.168.100.254: icmp_seq=1 ttl=64 time=0.687 ms
64 bytes from 192.168.100.254: icmp_seq=2 ttl=64 time=0.648 ms
^C
--- 192.168.100.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 23ms
rtt min/avg/max/mdev = 0.648/0.667/0.687/0.032 ms
root@ns:~#

хз. tcpdump в руки, в том числе на всех задействованных сторонах.

Не могу понять вот этого поведения

конечно, для него явно задано - через доп. шлюз. А остальные из той же сети (вангую) - напрямую по ARP.

Откуда эта информация:

если на исходящем интерфейсе 1 ip, то берется он

Вы сами придумали, что я утверждал, что:

локально работает только таблица main.

Я утверждал, что только таблица main работает для выбора src-адреса, про выбор маршрута я не писал. И играя с ip rule можно легко получить пакеты с src-адресом, не соответствующим интерфейсу, через который они уходят.

Все утилиты, если автор предусмотрел, умеют формировать src ip.

Ни одна утилита не умеет влиять на поведение библиотек, допустим libresolv. Для смены маршрутизации чего-то развесистого лучше отдельный сетевой namespace и выбор нужного src ip автоматически по записям в таблице маршрутизации.

Объясните, что вы пытаетесь сделать — создали отдельный vlan ens3.100@ens3 с 192.168.100.3/24, но пускаете пакеты для 192.168.100.0/24 мимо него (таблица isp2)?

Что означает «пригнать влан»?

И какое устройство и вас терминирует vlan'ы с другой стороны?

Опечатался, from а не to
ip rule add from 192.168.100.3 table main

На сервере создал отдельный vlan ens3.100@ens3 с 192.168.100.3/24, помимо этого на сервере есть ещё вланы ens3.102, ens3.103(это tagged vlan) и ens3 192.168.101.1 это acces vlan. Дело в том, что когда я создаю vlan ens3.100@ens3 с 192.168.100.3/24 на сервере и с компа 192.168.100.10/24 обращаюсь к хосту из влана ens3.102, ens3.103, то у меня пакет идет через кинетик, т.к. он шлюз для 192.168.100.10(на кинетике настроены маршруты, что для сетей 192.168.102.0/24 и 192.168.103.0/24 маршрутизатор 192.168.101.1/24). В свою очередь 192.168.101.1 оказывается в одной подсети со 192.168.100.10/24, т.к. подняли vlan ens3.100@ens3 с 192.168.100.3/24 и ответ он отправляет напрямую к 192.168.100.10/24 минуя кинетик. Вланы терминируются на кинетике.

Итак, на начальный пост этого топика проблема была в том, что в одной подсети (vlan'е) 192.168.100.0/24 два шлюза, один в интернет, другой в 192.168.102.0/23.

Вам не хочется прописывать на каждом из компов 192.168.100.0/24 два маршрута — один в default через 192.168.100.254 (кинетик), другой в сеть 192.168.102.0/23 через 192.168.100.3 (сервер).

Я правильно понял? А то здесь уже советуют совсем разное, похоже полностью не понимая что происходит.

Да, вы меня верно поняли. Я не хочу на каждом хосте из 192.168.100.0/24 прописывать маршруты.

Ну тогда, исходно вы всё правильно делали, просто не хватило маршрутов в isp2. Как-то так:

ip rule add from 192.168.101.0/24 table isp2
ip rule add from 192.168.102.0/23 table isp2
ip route 192.168.101.0/24 dev ens3 src 192.168.101.1 table isp2
ip route 192.168.102.0/24 dev ens3.102 src 192.168.102.254 table isp2
ip route 192.168.103.0/24 dev ens3.103 src 192.168.103.254 table isp2
ip route add default via 192.168.101.254 dev ens3 table isp2

P.S. Я написал полный список правил, наличие каких-то других правил, SNAT, маршрутов в isp2 не подразумеваются.

rp_filter на сервере, вроде как не мешает, раз у вас default через ens3, но я бы его выключил.

Вобще странно, что исходно схема не работала. Ну отправляет 192.168.100.10 пакет на 192.168.100.3 через 192.168.100.254 (кинетик). Возможно в ответ получает icmp-redirect, но пакет то дальше доходит. Отвечает ему сервер напрямую. Пакет, вроде как, опять доходит. В ip-пакете ведь нет указания через какие маршрутизаторы он прошёл. Как 192.168.100.10 отличал в приходящих от 192.168.100.3 пакетах, пакеты прошедшие через кинетик и пакеты, идущие по прямому маршруту?

Заработало, спасибо большое.

ip rule add from 192.168.103.0/24 table isp2

ip route 192.168.101.0/24 dev ens3 src 192.168.101.1 table isp2
ip route 192.168.102.0/24 dev ens3.102 src 192.168.102.254 table isp2
ip route 192.168.103.0/24 dev ens3.103 src 192.168.103.254 table isp2

Потеряли «add» после «ip route».

Проблема начиналась при обращении 100.10 к 101.1 или 103.253 или 102.253. Т.к. пакет шел через кинетик, потом попадал на сервер, затем к клиенту. Затем ответ возвращался на сервер, а тот его напрямую к 100.10 возвращал. Там, что-то на подобии подмены mac'a получалось.

ip rule add from 192.168.102.0/23 table isp2

Суффикс 23?

И последний вопрос. В какой каталог поместить скрипт с этими строками?

Потеряли «add» после «ip route».

Да, поторопился.

Суффикс 23?

Да, префикс 23. То есть охватываем две сети /24. Именно по этому

Хотя я так получаю доступ к 192.168.103.0/24.

Я не знаю, куда правильно размещать сетевые команды в Debian 10, раньше в файле /etc/network/interfaces я бы добавление маршрутов раскидал по ″post-up″ соотв. интерфейсов, а всё остальное в «post-up» интерфейса ens3. То есть как-то так:

auto ens3
...
   post-up ip rule add from 192.168.101.0/24 table isp2
   post-up ip rule add from 192.168.102.0/23 table isp2
   post-up ip route add 192.168.101.0/24 dev ens3 src 192.168.101.1 table isp2
   post-up ip route add default via 192.168.101.254 dev ens3 table isp2

auto enp0s3.102
...
   post-up ip route add 192.168.102.0/24 dev ens3.102 src 192.168.102.254 table isp2

...