Уважаемые сетевики, есть сабж!!
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?
Какие лучше будет прописать правила?
Схема
Направление внешнего соединения в Локальную сеть
- Gregory
- Сообщения: 17
- Зарегистрирован: 26 окт 2017, 17:21
-
- Сообщения: 1199
- Зарегистрирован: 29 сен 2011, 09:16
- Gregory
- Сообщения: 17
- Зарегистрирован: 26 окт 2017, 17:21
Не совсем наше все.
А вернее немного не то.
Посыл верный, но Вы не учли, что подсеть единая 192.168.88.0/24, нет как такового транспортного уровня с другой подсетью.
Вернее есть, но она не участвует в маршрутизации никоим образом. EoIP идет поверх OpenVPN..
Такая топология мне нужна для поддержки Netbios трафика
Попробуйте собрать подобную схему )
А вернее немного не то.
Посыл верный, но Вы не учли, что подсеть единая 192.168.88.0/24, нет как такового транспортного уровня с другой подсетью.
Вернее есть, но она не участвует в маршрутизации никоим образом. EoIP идет поверх OpenVPN..
Такая топология мне нужна для поддержки Netbios трафика
Попробуйте собрать подобную схему )
Некоторые заметки из жизни: gregory-gost.ru
- Vlad-2
- Модератор
- Сообщения: 2531
- Зарегистрирован: 08 апр 2016, 19:19
- Откуда: Петропавловск-Камчатский (п-ов Камчатка)
- Контактная информация:
Странные мы, админы...
Порой простые задачи и даже действия проще в самом начале сделать,
а мы лепим и лепим обходные моменты и костыли.
Всё равно что уравнение 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 и работать более правильно, разные сети, разные каналы и так далее,
и отдавать пропускную способность туннеля под данные только, а не гоняя в них бродкасты и т.д...
Порой простые задачи и даже действия проще в самом начале сделать,
а мы лепим и лепим обходные моменты и костыли.
Всё равно что уравнение 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
- Сообщения: 17
- Зарегистрирован: 26 окт 2017, 17:21
Vlad-2,
Вы конечно много в чем правы, сети, логика, правильность. Все это здорово.
А как же любопытство и интерес. А можно ли так сделать, а будет ли работать?
Не буду спорить с Вами насчет построения сетей, меня споры не интересуют.
Если знаете, как сделать на данной топологии, милости прошу, если не знаете не советую тратить тут и Ваше и моё время.
Это сугубо домашняя сборка, никаких офисов. Дань родительской неграмотности. Netbios такой Netbios.
Трафик меня не интересует и нагрузка тоже т.к. она не существенна. Это не корпоративная сеть.
Plex Media Server + SMART TV
Эти железки очень любят искать DLNA сервера в своей подсети.
Также еще пара софтин работает схожим образом.
Хотя смысл этих объяснений. Это совершенно неважно. Важно то, что можно ли реализовать эту идею!
Отсюда:
Не будет разделения подсетей. Необходимо найти другое решение.
Вы конечно много в чем правы, сети, логика, правильность. Все это здорово.
А как же любопытство и интерес. А можно ли так сделать, а будет ли работать?
Не буду спорить с Вами насчет построения сетей, меня споры не интересуют.
Если знаете, как сделать на данной топологии, милости прошу, если не знаете не советую тратить тут и Ваше и моё время.
Vlad-2 писал(а):Создать маркировку, поднять туннель, загнать EoIP трафик и всё ради NetBios трафика...
Не уж то Ярлык/Иконку или подключить сетевой диск (батник или руками) сложнее?
Нет слов...эмоции...
Это сугубо домашняя сборка, никаких офисов. Дань родительской неграмотности. Netbios такой Netbios.
Трафик меня не интересует и нагрузка тоже т.к. она не существенна. Это не корпоративная сеть.
Plex Media Server + SMART TV
Эти железки очень любят искать DLNA сервера в своей подсети.
Также еще пара софтин работает схожим образом.
Хотя смысл этих объяснений. Это совершенно неважно. Важно то, что можно ли реализовать эту идею!
Отсюда:
Не будет разделения подсетей. Необходимо найти другое решение.
Некоторые заметки из жизни: gregory-gost.ru
- Vlad-2
- Модератор
- Сообщения: 2531
- Зарегистрирован: 08 апр 2016, 19:19
- Откуда: Петропавловск-Камчатский (п-ов Камчатка)
- Контактная информация:
Gregory писал(а):Если знаете, как сделать на данной топологии, милости прошу, если не знаете не советую тратить тут и Ваше и моё время.
Ну вариантов я Вам в своём первом сообщении накидал, Вы их вообще как будто не заметили.
Gregory писал(а):Plex Media Server + SMART TV
Ну коли Вы так всё знаете, то знаете что и медиа-устройства можно настроить, привязать.
Если Вы гоните туда EoIP - можно в L2- уровень вместе с медиа-сервером загонять
то устройство на котором Вы хотите обращаться к медиа-серверу.
Но подчёркиваю, чуть чуть настроив медиа-сервер - и всё, нет проблем.
Gregory писал(а):Также еще пара софтин работает схожим образом.
Делите свою сеть на сеть которая является частью родительской, и другую часть своей сети
уже делайте основной и в другой адресации.
Варианты есть, но Вы хотите по велению галочки/правила чтобы всё заработало....странно
особенно когда Вы понимаете процессы.
Gregory писал(а):Хотя смысл этих объяснений. Это совершенно неважно. Важно то, что можно ли реализовать эту идею!
Реализовать идею можно, но и условия должны быть..а у Вас их нет.
Всё равно что решить задачу как дышать в космосе, не имея ничего..в буквальном смысле...
Gregory писал(а):Отсюда:
Не будет разделения подсетей. Необходимо найти другое решение.
Как уже я написал, инженер ситуацию(проблему делит), я бы тоже делил,
выше я написал.....идей дал уже и под-идей....
P.S.
ещё одна идея..делайте метку трафику, если местка есть...то Вы попали на тот роутер, метки нету,
не тот роутер и не та сетка...это идея пока что....как реализовать я не знаю сейчас...
но яж поделился...
-
- Сообщения: 536
- Зарегистрирован: 03 сен 2017, 03:08
- Откуда: Marienburga
И это всё для Plex Media Server ? К стати - DLNA сервер на нём только ради галочки. Лучше даже отключить.
Если нужен доступ к Plex Media Server, то ето решается совсем другим способом.
Если нужен доступ к Plex Media Server, то ето решается совсем другим способом.
-
- Сообщения: 1199
- Зарегистрирован: 29 сен 2011, 09:16
Gregory писал(а):Не совсем наше все.
А вернее немного не то.
Посыл верный, но Вы не учли, что подсеть единая 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
Соответственно никакой маркировки вообще не надо, просто правило проброса и вот эта конструкция.
Но это все голая теория, проверять вам, т.к. пример все же описан для другого случая. Плюс не забывайте, расположение правила играет роль и вот тут вам придется "поиграть".
-
- Сообщения: 7
- Зарегистрирован: 04 ноя 2017, 19:12
- Откуда: Москва
Я бы советовал поменять 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 гонять.
А насчет исходной задачи, можно dst-натить на R1 не в 192.168.88.30-192.168.88.59, а на ip-адрес интерфейса vpn со стороны R2. На нем уже натить в 192.168.88.30-192.168.88.59. При этом помечая новые соединения, которые пришли через впн, чтобы потом зароутить обратные пакеты через туннель. Проброс портов не надо вообще через EoIP гонять.
- Gregory
- Сообщения: 17
- Зарегистрирован: 26 окт 2017, 17:21
KARaS'b писал(а):Ну так вот, ключевой момент во всем том, на что я сослался это
Невзирая на разность в строении сети примера, ваша задача точно такая же, прикинуться кем-то, кого знаю хосты из удаленной сети, что бы не отсылать ответ по дефолтному маршруту своему маршрутизатору, а поскольку про существование второго шлюза они знаю благодаря маске, то ваше правило будет выглядеть примерно так
Соответственно никакой маркировки вообще не надо, просто правило проброса и вот эта конструкция.
Но это все голая теория, проверять вам, т.к. пример все же описан для другого случая. Плюс не забывайте, расположение правила играет роль и вот тут вам придется "поиграть".
Спасибо за наводку, буду проверять.
Понимание грубости у нас с Вами явно отличаются =)
lupus23ua'b писал(а):Я бы советовал поменять 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 у меня не сложилось по причине слишком частых разрывов соединения при той же конфигурации.
Vlad-2 писал(а):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 для удаленного доступа
Некоторые заметки из жизни: gregory-gost.ru