LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

Есть у меня роутер keenetic и сервер на Debian. Через keenetic идет выход в интернет всех устройств и подсетей. У сервера есть свои подсети. Ниже будет картинка для наглядности. В серевере есть одна физическая сетевая ens3 с IP 192.168.101.1, всё остальное это влан интерфейсы, которые приходят тегированными вланами.(ens3.102 и ens3.103). Встала у меня тут задачка пригнать влан 100(ens3.100), но после этого у меня из подесети 192.168.100.0/24 перестал работь ssh и http на все подсети за сервером 192.168.101.1, т.к. пакет на сервер идет через кинетик, а возвращается прямым маршрутом минуя кинетик.

Путем гугления и подсказок стал использовать pbr. Добавил таблицу маршрутизации:

echo 200 isp2 >> /etc/iproute2/rt_tables
И добавил в нее такие записи:

ip rule add iif ens3.102 table isp2
ip rule add iif ens3.103 table isp2
ip rule add from 192.168.101.1 table isp2
ip rule add from 192.168.101.2 table isp2
ip rule add from 192.168.101.3 table isp2
ip rule add from 192.168.102.253  table isp2
ip rule add from 192.168.102.254  table isp2
ip rule add from 192.168.103.253  table isp2
ip rule add from 192.168.103.254  table isp2
ip route add default via 192.168.101.254 dev ens3 table isp2
Но тут произошло следующее. Сам сервер перестал общаться напрямую со 192.168.102.253 и 192.168.103.253, все запросы согласно правил улетают на 192.168.101.254.

Как-то можно это побороть?

По ссылке схема сети. https://ibb.co/r54dSV0 Зеленой стрелкой запрос от 100.10 в сторону 101.1. Красной стрелкой ответ от 101.1


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

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

mky ★★★★★
()
Ответ на: комментарий от mky

Есть 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 минуя кинетик.

bredis
() автор топика
Последнее исправление: bredis (всего исправлений: 1)
Ответ на: комментарий от bredis

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

bredis
() автор топика
Ответ на: комментарий от bredis

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

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от bredis

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

mky ★★★★★
()
Ответ на: комментарий от anc

Прописал 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]

bredis
() автор топика
Последнее исправление: bredis (всего исправлений: 1)

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

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

infomeh ★★
()
Ответ на: комментарий от infomeh

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

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

anc ★★★★★
()
Ответ на: комментарий от Bers666

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

Когда сервер просто пытается установить соединение (не указав с какого адреса идти), то адрес выбирается исходя из маршрутов в 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 используется.

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

то адрес выбирается исходя из маршрутов в 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» в делаете ваш пост менее заметным для поиска через гугл?

mky ★★★★★
()
Ответ на: комментарий от Bers666

Прописал 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 подсети шлюз указать, но это не зачем.

bredis
() автор топика
Ответ на: комментарий от mky

Здесь речь идёт про адрес, с которого идти, то есть 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, без файрволов/таблиц маршрутизации.

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

root@ns:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:ae:f5:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.1/24 brd 192.168.101.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feae:f55e/64 scope link
       valid_lft forever preferred_lft forever
3: ens3.102@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ae:f5:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.102.254/24 brd 192.168.102.255 scope global ens3.102
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feae:f502/64 scope link
       valid_lft forever preferred_lft forever
4: ens3.103@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ae:f5:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.103.254/24 brd 192.168.103.255 scope global ens3.103
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feae:f503/64 scope link
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 192.168.5.254/24 brd 192.168.5.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::b077:df8a:d71e:b4b0/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
6: ens3.100@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ae:f5:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global ens3.100
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feae:f55e/64 scope link
       valid_lft forever preferred_lft forever
root@ns:~#
root@ns:~# ip ru
0:      from all lookup local
32765:  from all to 192.168.100.0/24 lookup isp2
32766:  from all lookup main
32767:  from all lookup default
root@ns:~#
root@ns:~# ip ro
default via 192.168.101.254 dev ens3 onlink
192.168.5.0/24 dev tun0 proto kernel scope link src 192.168.5.254
192.168.100.0/24 dev ens3.100 proto kernel scope link src 192.168.100.3
192.168.101.0/24 dev ens3 proto kernel scope link src 192.168.101.1
192.168.102.0/24 dev ens3.102 proto kernel scope link src 192.168.102.254
192.168.103.0/24 dev ens3.103 proto kernel scope link src 192.168.103.254
root@ns:~# ip ro show tab isp2
default via 192.168.101.254 dev ens3
root@ns:~#
bredis
() автор топика
Ответ на: комментарий от bredis

ОК, если с такой конфой ты будешь пинговать сервер->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
Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

Добавил

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:~#
2 хоста пингуются с сервера, а 100.10 нет.

bredis
() автор топика
Последнее исправление: bredis (всего исправлений: 1)
Ответ на: комментарий от bredis

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

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

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

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

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

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

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

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

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

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

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

mky ★★★★★
()
Ответ на: комментарий от bredis

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

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

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

mky ★★★★★
()
Ответ на: комментарий от anc

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

anc ★★★★★
()
Ответ на: комментарий от mky

На сервере создал отдельный 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 минуя кинетик. Вланы терминируются на кинетике.

bredis
() автор топика
Ответ на: комментарий от bredis

Итак, на начальный пост этого топика проблема была в том, что в одной подсети (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 (сервер).

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

mky ★★★★★
()
Ответ на: комментарий от bredis

Ну тогда, исходно вы всё правильно делали, просто не хватило маршрутов в 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 не подразумеваются.

mky ★★★★★
()
Ответ на: комментарий от mky

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 пакетах, пакеты прошедшие через кинетик и пакеты, идущие по прямому маршруту?

mky ★★★★★
()
Ответ на: комментарий от mky

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

ip rule add from 192.168.103.0/24 table isp2
Не нужно? Хотя я так получаю доступ к 192.168.103.0/24.

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?

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

bredis
() автор топика
Последнее исправление: bredis (всего исправлений: 1)
Ответ на: комментарий от bredis

Потеряли «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

...
Чтобы маршруты прописывались после того, как интерфейс сконфигурировался и UP-нулся.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.