Как соединить три удаленных офиса в 1 сеть через Mikrotik-и?
Существует 3 помещения, уже соединенные друг с другом через роутеры - Mikrotikи, только выполняется там несколько другая функция - соединение с основным офисом и доступ к его внутренней подсети.
В одном офисе стоит как бы основной роутер с настроенными 2-мя pptp-серверами, 2 другие роутера цепляются к основному как pptp-клиенты. В данный момент действует следующая схема ip-адрессов:
1 - сервер
внутренняя сеть 192.168.1.0/24, где сам маршрутизатор 192.168.1.1
c первым vpn клиентом (первый удаленный офис) маршрутизатор 10.10.1.1
со вторым vpn клиентом (второй удаленный офис) маршрутизатор 10.10.2.1
2- первый удаленный офис
внутренняя сеть 192.168.2.0/24, где сам маршрутизатор 192.168.2.1
при подключении к серверу роутер имеет ip-шник 10.10.1.2
3- второй удаленный офис
внутренняя сеть 192.168.3.0/24, где сам маршрутизатор 192.168.3.1
при подключении к серверу роутер имеет ip-шник 10.10.2.2
Плюс на сервере настроены маршруты как попасть в 192.168.2.1 и 192.168.3.1, и на каждом из удаленных офисов прописано как попасть в 192.168.1.1.
На данный момент стоит задача чтобы все клиенты 192.168.2.1 видели и взаимодействовали с клиентами 192.168.3.1, только вот разобраться не могу как правильней это сделать.
PS придерживаясь организации обмена pptp прописал следующие дополнительные правила:
На стороне сервера:
ip firewal nat add action=masquerade chain=srcnat out-interface=vpn_na_pervoe_podkluchenie
ip firewal nat add action=masquerade chain=srcnat out-interface=vpn_na_vtoroe_podkluchenie
ip firewall filter add chain=forward src-address=192.168.1.0/24 dst-address=192.168.2.0/24 action=accept
ip firewall filter add chain=forward src-address=192.168.2.0/24 dst-address=192.168.1.0/24 action=accept
На стороне первого клиента:
ip route add dst-address=192.168.2.0/24 gateway=10.10.1.1 pref-src=10.10.1.2
На стороне второго клиента:
ip route add dst-address=192.168.1.0/24 gateway=10.10.2.1 pref-src=10.10.2.2
Но с адреса 192.168.2.20 никак не получается пингануть 192.168.1.1. Кажется чтото не дописал, подскажите пожалуйста, где я мог ошибиться.
Привет! В данном случае если оставаться на pptp то:
1. На третьем маршрут до сети второго через pptp адрес первого
2. На втором маршрут до сети третьего через pptp адрес первого
3. На третьем разрешить ходить трафику между сетими третьего и второго.
Если же отказаться от этого гемороя и перейти к другому геморою, то можно сделать так
1. Перейти на IPSec в туннельном режиме
2. Настроить пиры и политики на всех трёх, при этом разрешить автосоздание политик и преднастроить исходящие политики только для локальной сети на каждом узле
3. В таком случае соединение будет каждый с каждым и донастраивать что-то при изменении топологии будет много проще.
Так же можно перейти на IPSec в транспортном + EoIP или GRE туннели, это вариант защищённый как и IPSec, но проще в плане обслуживания как PPTP.
А вот от чистого PPTP я вам рекомендую скорейши отказываться, так как сами знаете 128 бит шифрование в публичной сети это...
Я в скором будущем планирую перевести эту схему на IPSec, но в данный момент пока что только через pptp от независящих от меня причин. Дело в том что маршруты из второго на третий и с третьего на второй я прописал, а как разрешить ходить трафику между подключениями на сервере?
@alz5 в нат и в фильтрах два правила с действием accept между двумя сетями (в начале в одном направлении, потом в другом). Правила расположите выше остальных.
@SmileyK ну да, он лучше нежели тупой rip (хотя последний понимают клиентские машины и его можно использовать вместе с pptp, например). Но имхо, настройка динамики ради трёх пиров и трёх же подсетей - это избыточно.
Евгений Быченко: Можете подробнее расписать как "1. Перейти на IPSec в туннельном режиме..." И вообще можно ли это сделать если 1 сервер с белым ip а 2 других - серые?
Валихан: Ох, ну вы спросили, спустя год =) Если одна сторона с серым адресом - то IPSec крайне трудно поднимать, т.к. там политика подразумевает указание адресов обеих сторон, и если скажем одна сторона имеет внешнюю динамику, то нужно будет каждый раз знать какой у пира внешний адрес.
Евгений Быченко: Спрошу ещё через год. =) А вы не сталкивались с конструкцией, когда на двух офисах сеть 192.168.1.0/24 и надо два офиса слить в одну сеть с той же 192.168.1.0/24? Сработает? Нет? Нужны особые пляски с бубном?
Игорь Б: лютый геморой, но можно, если скажем сети не "очень далеко" (такая конструкция крайне чувствительна к задержкам в месте стыка, т.к. именно в этом месте будут основные затраты на arp, anycast, dhcp и прочий широковещательный трафик). Сделать это можно если поднять l2 туннель (их несколько типов) между сетями и загнать этот туннель с каждой стороны в бридж с локальным интерфейсом.
l2 можно поднять, например, поверх IPSec если он сам не умеет в шифрование.
