LINUX.ORG.RU
ФорумAdmin

Две сети, два роутера, port forwarding на один сервер

 , ,


1

1

Есть две разные внешние сети, каждая со своим IP-адресом:

  • Сеть А с адресом 95...*
  • Сеть Б с адресом 46...*

Есть два роутера, каждый подключен к своей сети:

  • ASUS к сети А
  • ZTE к сети Б

Сеть А имеет внутреннюю адресацию 192.168.3.0/24 Сеть Б имеет внутреннюю адресацию 192.168.1.0/24

Есть сервер на Fedora 42 с подключением к обоим сетям через разные интерфейсы.

  • IP адрес сервера 192.168.1.111 в сети Б и
  • 192.168.3.111 в сети А.

На обоих роутерах настроен форвардинг 80-го порта на 80-ый порт этого сервера.

На самом сервере установлен nginx, на котором настроено несколько сайтов. Сайты доступны только если их А-записи смотрят на IP сети Б (46...*). Сайты сети А недоступны.

Что нужно сделать чтобы были видны все сайты?

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

firkax ★★★★★
()

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

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

По статье с одного ресурса сделал следующее [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?)

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

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

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

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

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

ip rule add priority 100 from all table main
И что бы два раза не вставать, в таблице main не должно быть default route

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

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

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

> 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
alexashx
() автор топика
Ответ на: комментарий от anc

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

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

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

> 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
alexashx
() автор топика
Ответ на: комментарий от firkax

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

Но сейчас все работает - и соединение по 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 (!))

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

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

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

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

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

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

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

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

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

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

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

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

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

Не надо методом тыка ничего делать, надо разобраться с заббиксом - почему он починился от той замены правил в начале, хотя не должен был. Посмотри (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 
ты когда добавил? Если бы в первом было lan_table вместо wan_table - скорее бы всё работало нормально.

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

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

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

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

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

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

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

Еще на самом деле опрос сервером сервером заббикса не работал всё же. Работали только трапки (исходящие метрики). Фикс указанного косяка (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

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

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
Шлёт через 1.1, и заменяет адрес отправителя 0.0.0.0 на 192.168.1.111.

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

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

Чтобы вернуть серверу исходное поведение, которое было до 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 вперёд.

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

Чтобы вернуть серверу исходное поведение, которое было до 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 надо изолировать, но доступ к этому серверу нужен обеим локалкам и почему-то нет возможности коннектиться из них к разным айпи-адресам. Ну, если автор наверно скажет если так надо и оно сломалось.

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

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

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

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

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

alexashx
() автор топика