Форум системных администраторов
IT => Networks => Тема начата: Gekko от 12 января 2018, 16:34:52
-
День добрый! Возник теоретический вопрос: как объеденить две подсети. В идеале было бы круто, если бы виндовый браузер сети находил машины из другой подсетки.
Теперь о деталях: структура сети изображена на картинке: свич по середине представляет собой провайдерскую сеть, и все что от него исходит - есть VPN соединения по оптике. То есть филиалы обьеденены в сеть 172.16.10.0, дальше микротики раздают локальные подсети типа 192.168.10.0/24 - 192.168.40.0/24. В данный момент необходимо добиться хотя бы проницаемости по самба порту к определенному компу в соседней сети. Натить самбу - по моему моветон. Как прописать маршруты таким образом что бы рабочие станции из сети 20 видели сеть 30?
На микротик 172.16.10.30 прописал путь : route 192.168.20.0/24 255.255.255.0 172.16.10.20
На 172.16.10.20 соответственно: route 192.168.30.0/24 255.255.255.0 172.16.10.30
Неработает...
Попробовал прописать путь на рабочих станциях - тот же результат.
Где я глубоко заблуждаюсь?
-
тут есть несколько нюансов:
1. Нет ли у провайдера политики изоляции клиентов, когда один клиент (суть - 1ый филиал) не может обращаться ко второму клиенту (суть - 2ой филиал) и оба они могут только в интернет.
проверить это можно выставив какой нибудь сервис наружу NAT-ом и попробовать обратиться к нему из других филиалов
2. Не смущает ли Вас то, что трафик между вашими филиалами будет гоняться в открытом виде и теоритически доступен для снимания на стороне провайдера?
после решения 1ого вопроса - могу предложить 2 варианта
Если открытость трафика для провайдера не проблема (что сомнительно) - поднять динамическую маршрутизацию, например OSPF
Если открытость трафика - проблема, то строить VPN туннели. Либо звездой, либо full-mesh
-
тут есть несколько нюансов:
1. Нет ли у провайдера политики изоляции клиентов, когда один клиент (суть - 1ый филиал) не может обращаться ко второму клиенту (суть - 2ой филиал) и оба они могут только в интернет.
проверить это можно выставив какой нибудь сервис наружу NAT-ом и попробовать обратиться к нему из других филиалов
2. Не смущает ли Вас то, что трафик между вашими филиалами будет гоняться в открытом виде и теоритически доступен для снимания на стороне провайдера?
после решения 1ого вопроса - могу предложить 2 варианта
Если открытость трафика для провайдера не проблема (что сомнительно) - поднять динамическую маршрутизацию, например OSPF
Если открытость трафика - проблема, то строить VPN туннели. Либо звездой, либо full-mesh
Трафик открыт. Все достаточно без проблем натится.
Немножечко детализирую схему:
Сеть №1 192.168.20.0./24 ----------{192.168.20.1 - 172.16.10.20}-------------------{172.16.10.30 - 192.168.30.1}---------- Сеть №2 192.168.30.0/24
Микротик №1 Микротик №2
И вот что получается: пингуются только адреса внутреннего интерфейса роутера.
То есть если с компьютера 192.168.20.100 попробовать пинговать 192.168.30.100 - получаем таймаут.
Если пинговать с того же 192.168.20.100 адрес 192.168.30.1 - получаем положительный ответ.
-
1. Нет ли у провайдера политики изоляции клиентов, когда один клиент (суть - 1ый филиал) не может обращаться ко второму клиенту (суть - 2ой филиал) и оба они могут только в интернет.
+1, нередкая дурь.
2. Ну у меня вообще мостами три филиала, и ничо живут... И да нам на перехват трафика пофиг.
-
Нет. Сеть 172.16.0.0 - это наше пространство. Тут мы вольны делать все что угодно. Где то я в самих микротиках что то упускаю. Из любой точки сети я могу пинговать внешние адреса роутеров: 172.16.10.10, 172.16.10.20, 172,16.10.30... все это пингуется. Более того - пингуются внутренние адреса тех же роутеров: 192.168.10.1, 192.168.20.1, 192.168.30.1. За роутерами немогу прощупать ни один хост.
ЗЫ И кстати да: на шифрование - пофиг.
-
Я щам может и глупость скажу но если у нас обычный мост, то разве нам не нужна для шировещательных запросов общая маска для этих четырех сетей /32
-
...скорее для трех.(192.168.20.0/24, 192.168.30.0/24 и 172.16.10.0/21). Остальные подсети в объединении не нуждаются. И что то мне не хватает знаний для понимания роли подобной сети. Может это proxy-arp?
Вот еще один эксперимент:
Я - 172.16.10.84
Система - винда.
Прописал маршрут: route add 192.168.20.0 mask 255.255.255.0 172.16.10.20 metric 1
На роутере 172.16.10.20 есть следующие маршруты по умолчанию:
# DST-ADDRESS PREF-SRC GATEWAY
0 A S 0.0.0.0/0 172.16.10.254
1 ADC 172.16.0.0/21 172.16.10.20 ether1
2 ADC 192.168.20.0/24 192.168.20.1 bridge
Теперь я начинаю сей роутер пинговать:
Внешний интерфейс роутера: ping 172.16.10.20 - есть пинг
Внутренний интерфейс роутера: ping 192.168.20.1 - нет пинга
Хост за роутером: ping 192.168.20.100 - нет пинга
ЗЫ Теперь добовляем на оба роутера маршруты на внутренние сети друг друга: на микротике 172.16.10.20 добавим маршрут до сети 192.168.30.0 через микротик 172.16.10.30, а на микротике 172.16.10.30 соответственно добавим маршрут до сети 192.168.20.0 через шлюз 172.16.10.20.
172.16.10.20
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 172.16.10.254 1
1 ADC 172.16.0.0/21 172.16.10.20 ether1 0
2 ADC 192.168.20.0/24 192.168.20.1 bridge 0
3 A S 192.168.30.0/24 172.16.10.30 1
172.16.10.30
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 172.16.10.254 1
1 ADC 172.16.0.0/21 172.16.10.30 ether1 0
2 ADC 192.168.30.0/24 192.168.30.1 bridge 0
3 A S 192.168.20.0/24 172.16.10.20 1
В таком виде мы получаем возможность пинговать с одного микротика внешний и внутренний интерфейс другого микротика, но не можем пинговать хосты... Какой то нонсенс. :( Как так получается?
Сижу на 192.168.20.100 и пингую:
ping 172.16.10.30 - вижу!
ping 192.168.30.1 - вижу!
ping 192.168.30.10 - таймаут... Как так? Почему один адрес из сети вижу а остальные - нет?
Updated: 16 January 2018, 17:39:41
Вот и решение подоспело. Статические маршруты - вещь довольно тривиальная, и чудес быть не могло. Решил я пинги запустить и на вкладку Firewall - Rules попялиться в режиме реалтайм. Обнулил счетчики пакетов, запустил пинги и стал наблюдать за правилами...
В последнем или предпоследнем обновлении RouterOS в скрипте начальных настроек добавили в конце новое правило:
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1
Дропает все влетающее с интерфейса WAN что не похоже на нат. В общем тут нужно либо правило на accept вставлять до него, либо отключать его нафих. Я отключил. :blush2: