Направление внешнего соединения в Локальную сеть

[Gregory]

Уважаемые сетевики, есть сабж!!

R1 :
Статический WAN IP - 1.1.1.1 получаем от провайдера.
LAN-Bridge - 192.168.88.0/24 IP=192.168.88.1
LAN Pool 192.168.88.5-192.168.88.29

R2:
WAN IP динамический
LAN-Bridge - 192.168.88.0/24 IP=192.168.88.2
LAN Pool 192.168.88.30-192.168.88.59

Между роутерами поднят OpenVPN и поверх него поднят EoIP, интерфейсы которого засунуты в LAN-Bridge
В Bridge Filter заблокированы исходящие DHCP запросы через интерфейсы EoIP (forward). DHCP-Server у каждого роутра свой но подсеть одна.

Так вот, я пытаюсь достучаться до R2 и устройств в его подсети(192.168.88.30-192.168.88.59) через статический адрес роутера R1 откуда-то из интернета (например с работы) простым пробросом порта (dst-nat)
Сейчас у меня это работает через маркировку по определенным портам и маскарадинг по данной маркировке обратно в LAN-Bridge

Это связано с тем, что делая без маркировки dst-nat на R1 запрос уходит к R2 и его устройствам, но возвращается уже через дефолтный маршрут R2, т.е. не туда откуда он пришел.
Пробовал делать второй дефолтный маршрут 0.0.0.0/0 через 192.168.88.1 с rout-mark
Впрочем загвоздка начинается в Mangle. В принципе достаточно одного правила prerouting на входящем интерфейсе LAN-Bridge

Но что-то мне подсказывает, что это не правильно. Должен быть другой путь.
Можно ли сделать возврат соединения на самом R2 используя Mangle и Route?
Какие лучше будет прописать правила?

Схема

[KARaS'b]

Поиск наше все - viewtopic.php?f=15&t=6467

[Gregory]

Не совсем наше все.
А вернее немного не то.
Посыл верный, но Вы не учли, что подсеть единая 192.168.88.0/24, нет как такового транспортного уровня с другой подсетью.
Вернее есть, но она не участвует в маршрутизации никоим образом. EoIP идет поверх OpenVPN..

Такая топология мне нужна для поддержки Netbios трафика

Попробуйте собрать подобную схему )

[Vlad-2]

Странные мы, админы...

Порой простые задачи и даже действия проще в самом начале сделать,
а мы лепим и лепим обходные моменты и костыли.
Всё равно что уравнение 4 класса решать методом производных или более
высокими математическими способами, когда на самом деле всё просто.
Создать маркировку, поднять туннель, загнать EoIP трафик и всё ради NetBios трафика...
Не уж то Ярлык/Иконку или подключить сетевой диск (батник или руками) сложнее?
Нет слов...эмоции...

1) совет глобальный - уйти от одной адресации, сделать маршрутизацию и спокойно работать.
2) не попадать в другую сеть через противоположный роутер, тоже не совсем понимаю,
если разные сети расположены в разных местах, зачем залезать в другой офис, через
первый? Не рационально.
2.1) да, Вы сейчас скажете - так надо/так получилось/так вышло - а я поверю, но
надо тогда тоже продолжнать извращаться, но уже всё же это делать в рамках
сетей и их правил.
2.2) приведите оба провайдера на оба роутера, и уже попробуйте в такой схеме поработать/сделать логику доступов.
2.2.1) это даже позволит в какой то степени более полно и динамически использовать схему...
3) Hairpin NAT тут не поможет, хотя да, он бы в целом помог,
ибо он скроет Вас за каким то адресом, но увы, опять двадцать пять - адресация у Вас одинаковая.
4) можно было попробовать замутить NetMap'ом - через него обращаться в сеть, которая есть локально уже,
но там используется NAT - а значит будет подстановка адреса, и опять это будет не совсем то.
5) Жёстко запретить делать подключения из вне с одно узла на адреса второго офиса, и также наоборот,
тогда это решило проблемы.

Итог:
-) не продуманность логики сети
-) утяжеление L2-уровня
-) потом дополнительная защита от DHCP серверов друг от друга
и многое другое свидетельствует что концепции основные сетевые явно нарушены, а NetBios
спокойно можно пользоваться и в рамках L3 и не грузить каналы бездарным трафиком L2-уровня.
(у меня NAS от Infortrenda - никогда себя в сетевом окружении не показывает...даже когда ты с ним
тупо и всегда в одном бродкаст-домене, так что NetBios не стоит порой таких жертв).

поэтому пунтк 1 = переделать один офис, сделать 89 подсетку, поднять маршрутизацию L3,
и не резать DHCP и работать более правильно, разные сети, разные каналы и так далее,
и отдавать пропускную способность туннеля под данные только, а не гоняя в них бродкасты и т.д...

[Gregory]

Vlad-2,
Вы конечно много в чем правы, сети, логика, правильность. Все это здорово.
А как же любопытство и интерес. А можно ли так сделать, а будет ли работать?
Не буду спорить с Вами насчет построения сетей, меня споры не интересуют.
Если знаете, как сделать на данной топологии, милости прошу, если не знаете не советую тратить тут и Ваше и моё время.

Создать маркировку, поднять туннель, загнать EoIP трафик и всё ради NetBios трафика...
Не уж то Ярлык/Иконку или подключить сетевой диск (батник или руками) сложнее?
Нет слов...эмоции...

Это сугубо домашняя сборка, никаких офисов. Дань родительской неграмотности. Netbios такой Netbios.
Трафик меня не интересует и нагрузка тоже т.к. она не существенна. Это не корпоративная сеть.
Plex Media Server + SMART TV
Эти железки очень любят искать DLNA сервера в своей подсети.
Также еще пара софтин работает схожим образом.
Хотя смысл этих объяснений. Это совершенно неважно. Важно то, что можно ли реализовать эту идею!

Отсюда:
Не будет разделения подсетей. Необходимо найти другое решение.

[Vlad-2]

Если знаете, как сделать на данной топологии, милости прошу, если не знаете не советую тратить тут и Ваше и моё время.

Ну вариантов я Вам в своём первом сообщении накидал, Вы их вообще как будто не заметили.

Plex Media Server + SMART TV

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

Также еще пара софтин работает схожим образом.

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

Хотя смысл этих объяснений. Это совершенно неважно. Важно то, что можно ли реализовать эту идею!

Реализовать идею можно, но и условия должны быть..а у Вас их нет.
Всё равно что решить задачу как дышать в космосе, не имея ничего..в буквальном смысле...

Отсюда:
Не будет разделения подсетей. Необходимо найти другое решение.

Как уже я написал, инженер ситуацию(проблему делит), я бы тоже делил,
выше я написал.....идей дал уже и под-идей....

P.S.
ещё одна идея..делайте метку трафику, если местка есть...то Вы попали на тот роутер, метки нету,
не тот роутер и не та сетка...это идея пока что....как реализовать я не знаю сейчас...
но яж поделился...

[mafijs]

И это всё для Plex Media Server ? К стати - DLNA сервер на нём только ради галочки. Лучше даже отключить.
Если нужен доступ к Plex Media Server, то ето решается совсем другим способом.

[KARaS'b]

Не совсем наше все.
А вернее немного не то.
Посыл верный, но Вы не учли, что подсеть единая 192.168.88.0/24, нет как такового транспортного уровня с другой подсетью.
Вернее есть, но она не участвует в маршрутизации никоим образом. EoIP идет поверх OpenVPN..

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

Код: Выделить всё

Соответственно идем в нат с нашей стороны и создаем правило типа 
chain=srcnat dst-address=192.168.1.0/24 action=src-nat to-address=1.1.1.1

Ну и подымаем его повыше. 

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

Код: Выделить всё

chain=srcnat dst-address=адрес нужного хоста action=src-nat to-address=192.168.88.1

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

[lupus23ua]

Я бы советовал поменять openvpn на l2tp или pptp. Просто потому,что производительность openvpn по tcp очень печальная. А уж tcp поверх eoip поверх tcp... Но это так, к слову.
А насчет исходной задачи, можно dst-натить на R1 не в 192.168.88.30-192.168.88.59, а на ip-адрес интерфейса vpn со стороны R2. На нем уже натить в 192.168.88.30-192.168.88.59. При этом помечая новые соединения, которые пришли через впн, чтобы потом зароутить обратные пакеты через туннель. Проброс портов не надо вообще через EoIP гонять.

[Gregory]

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

Спасибо за наводку, буду проверять.
Понимание грубости у нас с Вами явно отличаются =)

Я бы советовал поменять openvpn на l2tp или pptp. Просто потому,что производительность openvpn по tcp очень печальная. А уж tcp поверх eoip поверх tcp... Но это так, к слову.
А насчет исходной задачи, можно dst-натить на R1 не в 192.168.88.30-192.168.88.59, а на ip-адрес интерфейса vpn со стороны R2. На нем уже натить в 192.168.88.30-192.168.88.59. При этом помечая новые соединения, которые пришли через впн, чтобы потом зароутить обратные пакеты через туннель. Проброс портов не надо вообще через EoIP гонять.

Попробую и Вашу идею. Благодарю!
Про OpenVPN знаю, его выбрал т.к. он у меня стабильно работает. Кстати на R2 канал 100Mbps, на R1 500Mbps. Если отключить шифрование на OpenVPN я получаю скорость туннеля 85-90Mbps (Btest), так что не вижу плохой производительности.
С L2TP и PPTP у меня не сложилось по причине слишком частых разрывов соединения при той же конфигурации.

P.S.
ещё одна идея..делайте метку трафику, если местка есть...то Вы попали на тот роутер, метки нету,
не тот роутер и не та сетка...это идея пока что....как реализовать я не знаю сейчас...
но яж поделился...

Пока делал вот так, правда тогда до 88.1 не достучаться:
Firewall Mangle

Код: Выделить всё

chain=prerouting action=mark-routing new-routing-mark=bridge-one-route 
passthrough=no protocol=tcp dst-address=!192.168.88.0/24 
src-address-list=Local_Access in-interface=LAN-Bridge src-port="" log=yes 
log-prefix="ROUTE"

IP Route

Код: Выделить всё

dst-address=0.0.0.0/0 gateway=192.168.88.1 
gateway-status=192.168.88.1 reachable via  LAN-Bridge 
check-gateway=ping distance=2 scope=30 target-scope=10 
routing-mark=bridge-one-route

В Local_Access добавил нужные IP для удаленного доступа