Настрой на сервере source-based routing (сразу скажу, какие надо вводить команды я не помню, но по этим словам всё элементарно находится) чтобы пакеты с srcaddr 192.168.3.111 слались через соответствующий роутер. Сейчас, я так понимаю, там настроен default gateway 192.168.1.1, очевидно для связности через сеть А он не подходит.

Сеть 192.168.1.0/24 в курсе про существование сети 192.168.3.0/24?

Волшебные слова в гугле это «policy based routing» и лайтовый вариант «linux два провайдера». Кратко так, в системе не должно быть default route в таблице main, добавляете default route в отдельные таблицы, входящие соединения маркируете и потом исходящие пакеты в соотвествии с меткой отправляете нужным маршрутом.
ЗЫ Возможно набор моих букав вам показался чем-то сложным, не пугайтесь, там реально всё очень просто.

Нет, сети не в курсе про существование друг друга.

По статье с одного ресурса сделал следующее [code]

ip route add default via 192.168.1.1 table 101

ip route add default via 192.168.3.1 table 102

ip rule add from 192.168.1.111 table 101

ip rule add from 192.168.3.111 table 102

[/code]

После этих манипуляций сайты стали доступны, однако я потерял возможность коннектится к серверу по SSH локально, через ssh @192.168.1.111. Выдаёт ошибку: [code] kex_exchange_identification: read: Connection reset by peer Connection reset by 192.168.1.111 port 22 [/code]

• заббикс сервер потерял возможность опрашивать этот сервер.

В целом, и такое положение вещей меня устраивает, однако есть ли возможность ограничить эти правила только для 80 и 443 портов, например? Или чего не хватает, чтобы все работало вообще прекрасно (в том числе SSH и Zabbix?)

Проблему с заббиксом решил через замену правил на

ip rule add from 192.168.1.0/24 table 101
ip rule add from 192.168.3.0/24 table 102

Заббикс начал нормально работать в активном и пассивном режиме (сервер находится в сети 192.168.1.*)

Осталось решить проблему с ssh

Локально - это откуда (из какой сети и адреса)? И заббикс где расположен и с каким айпи-адресом?

Заббикс сервер расположен в сети по адресу 192.168.1.109, но с ним всё стало хорошо. А пытаюсь войти по ssh локально с ноута 192.168.1.10 через

> ssh 192.168.1.111

Таблица main должна быть вначале. Что-то в виде такого:

ip rule add priority 100 from all table main

Прочитал ваш комментарий, но пока не попробовал поиграться с приоритетами.

Просто для информации текущее состояние таблиц, правил и маршрутов:

> cat /usr/share/iproute2/rt_tables 
#
# reserved values
#
255	local
254	main
253	default
0	unspec
#
# local
#
#1	inr.ruhep

101 lan_table
102 wan_table

Правила:

> ip rule show
0:	from all lookup local
32764:	from 192.168.3.0/24 lookup wan_table
32765:	from 192.168.1.0/24 lookup lan_table
32766:	from all lookup main
32767:	from all lookup default

И маршрутов:

ip route show table all
default via 192.168.1.1 dev enp3s0 table lan_table 
default via 192.168.3.1 dev wlo1 table wan_table 
192.168.1.0/24 dev enp3s0 table wan_table scope link 
192.168.3.0/24 dev wlo1 table wan_table scope link 
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.111 metric 100 
default via 192.168.3.1 dev wlo1 proto dhcp src 192.168.3.111 metric 600 
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.111 metric 100 
192.168.3.0/24 dev wlo1 proto kernel scope link src 192.168.3.111 metric 600 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.1.111 dev enp3s0 table local proto kernel scope host src 192.168.1.111 
broadcast 192.168.1.255 dev enp3s0 table local proto kernel scope link src 192.168.1.111 
local 192.168.3.111 dev wlo1 table local proto kernel scope host src 192.168.3.111 
broadcast 192.168.3.255 dev wlo1 table local proto kernel scope link src 192.168.3.111 
fe80::/64 dev enp3s0 proto kernel metric 1024 pref medium
fe80::/64 dev wlo1 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::ce28:aaff:fe47:6af9 dev enp3s0 table local proto kernel metric 0 pref medium
local fe80::e1b2:99f6:254c:a0f9 dev wlo1 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev enp3s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlo1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eno2 table local proto kernel metric 256 pref medium

Выставление приоритетов помогло! Спасибо! Теперь всё работает как надо

Из таблицы main убрать default route. Таблицу main добавить в начало правил:

ip rule add priority 100 from all table main

Я не сразу понял в чём проблема с локальными коннектами была, теперь понял (пакеты из-за двух новых таблиц всегда слались в роутер и не попадали в link-local маршруты), но всё равно не понимаю две вещи

1) почему у него заббикс заработал после изменения rule на маски сетей вместо айпи адресов

2) зачем ты советуешь ставить main вверх

По-моему правильнее продублировать link-local роуты в таблицы по src, причём в каждую только своё. То есть 192.168.1.111 -> 192.168.3.0/24 не должно быть link-local-ом, оно должно попадать в default route для src 1.111 и идти через роутер.

Получилось как-то так

> ip route show table main
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.111 metric 100 
192.168.3.0/24 dev wlo1 proto kernel scope link src 192.168.3.111 metric 600

> ip rule show
0:	from all lookup local
100:	from all lookup main
32764:	from 192.168.3.0/24 lookup wan_table
32765:	from 192.168.1.0/24 lookup lan_table
32767:	from all lookup default

Я с сетями вообще на вы, но тоже хотелось бы побольше понимать происходящее. Если нужна какая-то доп инфа для объективной оценки, то могу показать.

Но сейчас все работает - и соединение по ssh из каждой из сети: то есть если я делаю ssh 192.168.1.111 с ноута с IP 192.168.1.10 - все заходит, и елси я присоединяюсь к серверу через ssh 192.168.3.111 с ноута с IP 192.168.3.178

И заббикс работает и в пассивном и в активном режиме (zabbix-server висит на 192.168.1.150, но при этом у него есть wan интерфейс на 192.168.3.109 (!))

При этом устройства из одной сети не видят устройств другой, то есть все еще нет возможности сделать кросс-сетевой коннект, но это и НЕ НУЖНО.

В любом случае спасибо за помощь всем участникам конференции.

Проверь откуда приходят пакеты заббикса - в какой интерфейс enp3s0 или wlo1 и с каком айпи-адресом отправителя. Есть подозрение что там что-то не так.

2) зачем ты советуешь ставить main вверх

Это не я такой умный, я тут только «повторюшка» :) В таблице main прописаны локальные роуты.

Как это повторюшка, никто больше про это не писал.

Если локальные это link-local то они тоже должны зависеть от srcip по-хорошему. Я же расписал в чём дело.

С заббиксом проверю. Но после удаления дефолтных роутов в main его кто-то упорно туда добавляет на интерфейс enp3s0 (192.168.1.111).

Как это повторюшка, никто больше про это не писал.

Писали, только давно.

Если локальные это link-local то они тоже должны зависеть от srcip по-хорошему.

Нет, локальные это я имел ввиду локалка, link-local это таблица local она в самом начале с priority 0 из каробки.

Может быть dhcp клиент?

А, тфу, я перепутал название. Вобщем я имел ввиду прямые маршруты без промежуточных узлов.

Пакеты 192.168.1.111 -> 192.168.3.4 должны направляться в 192.168.1.1, а он уже решит что с ними дальше делать (скорее всего - отправит в 192.168.3.0/24 сеть, но ведь там могут быть ещё какие-то действия делаться). В твоей схеме же их будет сервер сразу напрямую слать в чужую для этого srcip локалку.

Не надо методом тыка ничего делать, надо разобраться с заббиксом - почему он починился от той замены правил в начале, хотя не должен был. Посмотри (tcpdump) через какой интерфейс приходят от него пакеты и какой там ip-адрес отправителя.

ip rule add from 192.168.1.0/24 table 101
ip rule add from 192.168.3.0/24 table 102

Вот тут в from ничего кроме айпи-адресов самого сервера быть не должно. Ведь он же не занимается ещё и роутингом чужих пакетов?

И main надо назад вниз убрать.

А вот эти роуты

192.168.1.0/24 dev enp3s0 table wan_table scope link 
192.168.3.0/24 dev wlo1 table wan_table scope link 

Если не делать первой таблицу main без default-маршрутов, то в каждой таблице (wan_table и lan_table) должны быть по два маршрута к каждой из локальных сетей.

Сервер должен отвечать на пинги на адрес 192.168.3.111 из сети 192.168.1.0/24.

Тоже думал, но не нашел ни в сервисах, ни в процессах.

У вас ip адреса прописаны статиком? Если да, то там где они прописаны случайно до кучи не прописаны default gw ?

Почему по два то? По одному, к своей локалке только. К чужой - через внешний роутер как default route.

Сервер должен отвечать на пинги на адрес 192.168.3.111 из сети 192.168.1.0/24.

Он и будет отвечать. Условный комп 192.168.1.55 шлёт пинг, у него если локально доступное 1.111, а 3.111 это дефолт - он его шлёт на 1.1, тот со своего 3.1 интерфейса шлёт на 3.111. 3.111 отвечает назад на 3.1, тот роутит до 1.55.

Не вижу причин почему надо хотеть чтобы оно работало напрямую в обход роутера, это наоборот потенциальные проблемы. Ну и клиенты слать пинги в обход роутера всё равно не будут, они не могут знать что 3.111 это тот же комп что и 1.111.

Даже хз, на самом деле, откуда эти записи появились.

Еще на самом деле опрос сервером сервером заббикса не работал всё же. Работали только трапки (исходящие метрики). Фикс указанного косяка (wan_table вместо lan_table) починил это.

Плюс до кучи я вернул записи в исходный вариант (текущий конфиг ip rule show):

0:	from all lookup local
32762:	from 192.168.3.111 lookup wan_table
32763:	from 192.168.1.111 lookup lan_table
32766:	from all lookup main
32767:	from all lookup default

И все продолжило работать. Так что я сам уже запутался.

Однако в дополнение ко всему выяснил, что если удалить все дефолтные маршруты из main, то перестают работать запросы с самого сервера - dnf и wget выдают ошибку и кто-то постоянно туда вписывает default на 192.168.1.1.

А если поднять main наверх, то с дефолтными маршрутами отваливаются сайты из второй сети (192.168.3.*)

Пока остановился на вот таких маршрутах:

default via 192.168.1.1 dev enp3s0 table lan_table 
192.168.1.0/24 dev enp3s0 table lan_table scope link 
default via 192.168.3.1 dev wlo1 table wan_table 
192.168.3.0/24 dev wlo1 table wan_table scope link 
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.111 metric 100 
default via 192.168.3.1 dev wlo1 proto dhcp src 192.168.3.111 metric 600 
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.111 metric 100 
192.168.3.0/24 dev wlo1 proto kernel scope link src 192.168.3.111 metric 600 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.1.111 dev enp3s0 table local proto kernel scope host src 192.168.1.111 
broadcast 192.168.1.255 dev enp3s0 table local proto kernel scope link src 192.168.1.111 
local 192.168.3.111 dev wlo1 table local proto kernel scope host src 192.168.3.111 
broadcast 192.168.3.255 dev wlo1 table local proto kernel scope link src 192.168.3.111 
fe80::/64 dev enp3s0 proto kernel metric 1024 pref medium
fe80::/64 dev wlo1 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::ce28:aaff:fe47:6af9 dev enp3s0 table local proto kernel metric 0 pref medium
local fe80::e1b2:99f6:254c:a0f9 dev wlo1 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev enp3s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlo1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eno2 table local proto kernel metric 256 pref medium

Сейчас работают и сайты и заббикс в обе стороны и коннект по ssh из обеих сетей и исходящие запросы через dnf/curl

main вообще не надо было трогать - это настройки на случай когда из новых таблиц (lan_table и wan_table) ничего не подошло.

Ну я вижу ты его и вернул в исходный вид в итоге.

Однако в дополнение ко всему выяснил, что если удалить все дефолтные маршруты из main, то перестают работать запросы с самого сервера - dnf и wget выдают ошибку

Потому что они ставят адрес отправителя 0.0.0.0 - то есть чтобы ядро само выбрало откуда слать. В этом случае как раз и задействуется main, вот это правило

default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.111 metric 100

Почему по два то?

Чтобы вернуть серверу исходное поведение, которое было до ip rule.

К чужой - через внешний роутер как default route.

Ну, это с вашей точки зрения, а ТС пишет:

При этом устройства из одной сети не видят устройств другой, то есть все еще нет возможности сделать кросс-сетевой коннект, но это и НЕ НУЖНО.

С учётом того, что у него куча default маршрутов у этого сервера, и zabbix-сервер имеет два ip-адреса 192.168.1.150 и 192.168.3.109 там может быть что угодно. Может у него dhcp-сервер маршруты раздаёт, может у него клиент из сети 192.168.1.0/24 считает, что 192.168.3.111 на одном с ним интерфесей и кидает ARP-запрос, и линукс на него отвечает...

никто больше про это не писал.

Идеологом ставить main вперёд был vel, года с 2013 Вопрос по ip route (комментарий) только он ещё пояснял, что нелья просто из main убрать default, нужно оставить одну безусловно просматриваемую таблицу с default для исходящих с сервера соединеий, которым не указали src ip-адрес.

А anc, где-то с 2016 года пишет про таблицу main вперёд.

Чтобы вернуть серверу исходное поведение, которое было до ip rule.

Исходное поведение ему не годилось - при нём входящие коннекты с второй сети не работали.

а ТС пишет

Я вообще не понял это его заявление и не вникал. Сейчас почитал внимательнее. Мне казалось что 1.0 и 3.0 это два сегмента одной сети, разделённых роутером (считающим 3.0 аплинком т.к. автор его wan называет), а походу всё не так и это две независимые сети. Ну, тогда тем более, он прямо пишет что коннекты из 1.0 в 3.0 и назад ему не нужны. Значит и не надо их разрешать.

у него куча default маршрутов у этого сервера

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

zabbix-сервер имеет два ip-адреса 192.168.1.150 и 192.168.3.109

Как раз видно что доступ в обе сети, там где он нужен, действительно прописан явно.

может у него клиент из сети 192.168.1.0/24 считает, что 192.168.3.111 на одном с ним интерфесей и кидает ARP-запрос, и линукс на него отвечает...

Не вижу с чего такие подозрения. В любом случае, даже если и так, на мой взгляд всё равно желательно этот бардак прекратить и настроить нормально.

Хотя да, наверно могут быть случаи когда надо именно так: допустим, 1.0 и 3.0 надо изолировать, но доступ к этому серверу нужен обеим локалкам и почему-то нет возможности коннектиться из них к разным айпи-адресам. Ну, если автор наверно скажет если так надо и оно сломалось.

Соглашусь, что все это, возможно, звучит как странный и ненужный геморрой. Но при помощи всех вас я добился именно того, что мне было нужно.

Если больше конкретики накинуть и убрать все пробелы в понимании инфраструктуры, так вот:

Есть две разные сети (абсолютно разные провайдеры). Есть два роутера, каждый из которых подключен к своей сети и получает от нее свой статический внешний IP адрес: при этом один роутер образует внутреннюю сеть 192.168.1.1 и выделяет адреса из нее, второй - соответственно сеть 192.168.3.1. Устройства из одной сети не видять устройств из другой и им это не нужно.

Затея была в том, чтобы сделать общий сервер для обеих сетей - фронтенд/балансировщик для всех сайтов с одной лишь задачей - получить запрос из внешки независимо от того, на какой внешний IP адрес он приходит и направить на свой бэкенд в конкретную сеть для конкретного сайта.