Как сделать паралельное «keepalive» резервиврование двох VPN:EoIP по IPsec в одном bridge на mikrotik c 2WAN?

Question

[Igor_kov]

Есть центральный микротик с одним WAN и филиал в котором 2 WAN с реальными IP -адресами.

1. В филиале настроил и проверил автоматическое переключение интернет каналов от разных провайдеров по этой инструкции .

2. Сделал на центральном два входящих интерфейса и соответственно два инициирующих на клиентском Микротиках по этой инструкции

Но EoIP пара интерфейсов на клиентском и серверном работает только по одному WAN интернет каналу, т.е. когда первый провайдер в филиале пропадает, вторая пара по резервному согласно правилу "keepalive" не инициирует связь между офисами.

local address, remote address, tunnel id, ipsec secret - были настроены соответственно своим парам и перепроверены несколько раз.

Подскажите как "дебажить" маршрутизацию в момент переключения и почему не работает вторая "резервная" пара в такой схеме?

Answer 1

[Grustnui]

Igor_kov, а вы точно уверены что оно Вам таким образом надо ? Во первых, вы почти организовали кольцо. 2EoIP туннеля в 2 бриджа, это всё равно соединить 2 простых свитча, 2 мя патчкордами. Спасло Вас 2 вещи, 1) у Вас не поднялся второй интерфейс. 2) У микротика по умолчанию на бридже включен RSTP(если вы его сами не выключили). Далее по тексту, г-н poisons совершенно правильно вас отправил читать про переключение каналов без скриптов. Это просто работает. Далее прошу Вас, еще подумайте, а надо ли вам объединять офисы по L2 ? Вы понимаете, что весь broadcast траффик будет гулять по 2м офисам сразу ?. А что будет если завтра надо будет добавить еще один филиал ?. Сложнее настраивать файрволы и прочеее для ограничения доступа между офисами. В общем случае если нет приложений и оборудования, для работы которого необходимо, чтобы они находились в одном broadcast домене. Нет никакого смысла обьединять офисы по L2, пожалуйста рассмотрите вариант с L3.
Теперь на тему как дебажить: 1) Переделать переключение каналов как указано выше. Далее выкинуть EoIP из бриджей. Чтобы исключить влияние RSTP. Отключить IPSEC. B посмотреть поднялись ли оба туннеля с включенным KeepAlive. (см статус должен быть R). Вам уже написали Выше, скорее всего, проблема в том, что роутер зверушка глупая, и отправляет свои пакеты в соответствии с таблицей маршрутизации. В итоге получается следующая история пусть гл офис 3.3.3.3. Основной провайдер в филиале 1.1.1.1 резевный - 2.2.2.2. Роутеру сказано организуй туннель между 3.3.3.3 и 2.2.2.2 роутер что делает: формирует EoIP пакет, и отправляет его.... тадам в соотвествии с таблицой маршрутизации. А у нас кто основной правайдер ? 1.1.1.1 В итоге запрос на установку соединения туннеля с 2.2.2.2-3.3.3.3 прилетел через другой канал 1.1.1.1. D В общем случае это не то, что мы хотели, но туннель поднялся бы если бы не.... вторая проблема: посылает 3.3.3.3 запрос на установку соединения на 2.2.2.2. Ок пакет пришел мы что то с ним сделали и отвечаем... внимание в соответсвии с таблицой маршрутизации где написано что ? если работает 1й провайдер отвечать с 1.1.1.1. В итоге головной офис ждет ответ от 2.2.2.2 на запрос а получает ответ от 1.1.1.1. И его отбрасывает. Итого вам нужно сделать грубо говоря две вещи 1) чтобы роутер отвечал с того интерфейса, на который получил запрос, 2) EoIP соединения из филлиала с 2.2.2.2-3.3.3.3 должны уходить таки через интерфейс 2.2.2.2 :) Решается это все с помощью mangl'о магии.

Answer 2

[mr_ZM]

Я бы с радостью L3, но тут древние сервисы, которым 100 лет и есть попытка уйти от них. По поводу гуляния broadcast - на стороне филиала будет только 1 хост, к которому нужен доступ, не такой большой объем траффика, при запущенном канале Torch не показывает чего-то невероятного.
Манглами, я полагаю, как оба провайдера сделать, откуда пришло, туда и ушло, только тут с IPoE тоннелями?
Может тогда попробовать сделать через netwhach - поднимать тоннель eoip, в случае обрыва основного канала?