Микротик. 2 провайдера. Резервирование каналов 45


Имеем:
Основной провайдер — Prov1
Резервный провайдер — Prov2

Хотим:
чтобы оба канала работали одновременно — сам микротик и возможные сервисы за ним были доступны по двум каналом связи независимо друг от друга.
Пользователи выходят в сеть Интернет с основного канала, в случае неработоспособности — с резервного.

резервирование канала с микротик

Резервирование каналов с микротик

Теоретическая основа:
Нужно настроить маркировку входящего соединения, чтобы отслеживать — если запрос пришел с Prov1 то и ответ отправить через Prov1.
Два маршрута по умолчанию с разным «весом» (Distance). Скрипт переключения Distance в зависимости от состояния канала.
Не напутать с таблицами маршрутизации

Что делаем (вариант настройки из WinBox/Web  интерфейса):

1

Два маршрута по умолчанию (Dst. Address 0.0.0.0/0) с Comment «Prov1» и «Prov2» соответственно (нужно для работы скрипта), а Distance выставляем для основного -1, для резервного — 2.

2. IP->Firewall->Mangle

добавляем в начало правила маркировки соединения:

General
Chain: prerouting
Dst. Address: [ip Prov1]
In. Interface: [порт подключения Prov1]

Action
Action: mark_connection
New Connection Mark: Prov1_c
Passthrough: yes

 

General
Chain: prerouting
Dst. Address: [ip Prov2]
In. Interface: [порт подключения Prov2]

Action
Action: mark_connection
New Connection Mark: Prov2_c
Passthrough: yes

Для всяких случаев продублируем эти правила в chain  = input

3. IP->Routes

Добавляем два маршрута по умолчанию, так же как в п.1, только без Comment, а в Routing Mark пишем Prov1 для основного и Prov2 для резервного. Distance=1.

Эти маршруты будут работать только если мы завернем в них трафик создав соответствующие правило (см п.4).

4. IP->Routes->Rules

Создадим правила, заворачивающие  помеченные соединения в соответствующие таблицы маршрутов:

Src. Address: [ip Prov1]
Dst. Addess: 0.0.0.0/0
Routing Mark: Prov1_r
Action: lookup only in table
Table: Prov1

 

Src. Address: [ip Prov2]
Dst. Addess: 0.0.0.0/0
Routing Mark: Prov2_r
Action: lookup only in table
Table: Prov2

И на всякие случаи не помеченные:

Src. Address: [ip Prov1]
Dst. Addess: 0.0.0.0/0
Action: lookup
Table: Prov1

 

Src. Address: [ip Prov2]
Dst. Addess: 0.0.0.0/0
Action: lookup
Table: Prov2

5.  IP->Firewall->Mangle

Сразу после правил маркировки соединения пропишем правила маркировки маршрута:

General
Chain: prerouting
Connection Mark: Prov1_c

Action
Action: mark routing
New Routing Mark: Prov1_r
Passthrough: yes

 

General
Chain: prerouting
Connection Mark: Prov2_c

Action
Action: mark routing
New Routing Mark: Prov2_r
Passthrough: yes

Продублируем в  chain=output:

General
Chain: output
Connection Mark: Prov1_c
Action.
Action: mark routing
New Routing Mark: Prov1_r
Passthrough: yes

 

General
Chain: output
Connection Mark: Prov2_c
Action.
Action: mark routing
New Routing Mark: Prov2_r
Passthrough: yes

6.  IP->Firewall->NAT

Два правила маскарадинга для двух исходящих интерфейсов:

General
Chain: srcnat
Out. Interface: [порт подключения Prov1]
Action.
Action: masquerade

 

General
Chain: srcnat
Out. Interface: [порт подключения Prov2]
Action.
Action: masquerade

 

Если нужно — правила проброса портов на сервисы DMZ, в двух вариантах — для каждого провайдера

После этих настроек у нас должны заработать — сам микротик и настроенные пробросы портов должны заработать независимо на двух каналах связи.
Если что-то не заработало, то скорей всего надо внимательно смотреть таблицы и правила маршрутизации. Правила mangle сами по себе только ставят метки,
а значит если что-то перестаёт работать при вкл/выкл правила в mangle, то виновато не само правило mangle, а то правило, которое использует поставленные метки (или его отсутствие)

Не забываем проверить включен ли Tracking соединений: IP->Firewall->Connections->Tracking

 

Mikrotik Connection Tracking

Настройки connection tracking в Mikrotik

Осталось запилить механизм, который будет переключать основной маршрут в зависимости от состояния каналов.

Один из вариантов скрипта переключения основан на следующем:

  1. Есть по 3 ip на канал, которые мониторятся средствами ping
  2. Доступность канала определяется формулой:
    MainIfInetOk (($PingResult1 + $PingResult2 + $PingResult3) >= (2 * $PingCount))

    $PingCount = количество пинг запросов на хост. Другими словами — канал в порядке, если 2/3 запросов на проверочные хосты прошли.

  3. При наступлении события, соответственно переключаем Distance маршрута по умолчанию
  4. Не забываем от flush ить существующие NAT таблицы и IPSec SA (на данный момент существует одно стабильное средство — выкл/вкл интерфейс)

Чтобы ping запросы на проверочные хосты проходили через соответствующие интерфейсы (для основного канала (Prov1) через основные, для резервного (Prov2)- через резервный), нужно

добавить правила маршрутизации отдельно для проверочных хостов. Если вы дочитали до этого места, то уже понимаете как это сделать.

Если нужны скриншоты и/или какие-то пояснения — просьба отписать в комментариях.

 

Теперь у вас Mikrotik работает на двух провайдерах одновременно, сервисы за NAT доступны одновременно с двух каналов связи, а скрипт резервирования переключает пользовательский трафик на резервный канал в случае падения основного. О том, как сделать балансировку между двумя провайдерами будет отдельная история…

Скрипт резервирования:

#Main interface name
:global MainIf ether1-Prov1
#Reserve interface name
:global RsrvIf ether2-Prov2

:local PingCount 3
#
:local PingTarget1 8.8.8.8
#
:local PingTarget2 91.219.24.37
#
:local PingTarget3 213.59.5.110
#
:local PingTarget1R 194.87.0.50
#
:local PingTarget2R 80.68.243.243
#
:local PingTarget3R 8.8.4.4

#Check main internet connection
:local MainIfInetOk false;
:local PingResult1 [/ping $PingTarget1 count=$PingCount interface=$MainIf]
:local PingResult2 [/ping $PingTarget2 count=$PingCount interface=$MainIf]
:local PingResult3 [/ping $PingTarget3 count=$PingCount interface=$MainIf]
:set MainIfInetOk (($PingResult1 + $PingResult2 + $PingResult3) >= (2 * $PingCount))

#Check reserved internet connection
:local RsrvIfInetOk false;
:local PingResult1 [/ping $PingTarget1R count=$PingCount interface=$RsrvIf]
:local PingResult2 [/ping $PingTarget2R count=$PingCount interface=$RsrvIf]
:local PingResult3 [/ping $PingTarget3R count=$PingCount interface=$RsrvIf]

:set RsrvIfInetOk (($PingResult1 + $PingResult2 + $PingResult3) >= (2 * $PingCount))

:put "MainIfInetOk=$MainIfInetOk"
:put "RsrvIfInetOk=$RsrvIfInetOk"

if (!$MainIfInetOk) do={
/log error "Main internet connection error"
}

if (!$RsrvIfInetOk) do={
/log error "Reserve internet connection error"
}

:local MainGWDistance [/ip route get [find comment="Prov1"] distance]
:local RsrvGWDistance [/ip route get [find comment="Prov2"] distance]
:put "MainGWDistance=$MainGWDistance"
:put "RsrvGWDistance=$RsrvGWDistance"

#SetUp gateways
if ($MainIfInetOk && ($MainGWDistance >= $RsrvGWDistance)) do={
/ip route set [find comment="Prov1"] distance=1
/ip route set [find comment="Prov2"] distance=2
/interface disable $RsrvIf
/ip firewall connection tracking set enabled=no
delay 5
/ip firewall connection tracking set enabled=yes
/ip ipsec installed-sa flush sa-type=all
/log warning "Switch to main internet connection"
/interface enable $RsrvIf
}

if (!$MainIfInetOk && $RsrvIfInetOk && ($MainGWDistance <= $RsrvGWDistance)) do={
/ip route set [find comment="Prov1"] distance=2
/ip route set [find comment="Prov2"] distance=1
/interface disable $MainIf
/ip firewall connection tracking set enabled=no
delay 5
/ip firewall connection tracking set enabled=yes
/ip ipsec installed-sa flush sa-type=all
/log warning "Switch to reserve internet connection"
/interface enable $MainIf
}

Поблагодарить:


Оставьте комментарий

Ваш e-mail не будет опубликован.

45 мыслей про “Микротик. 2 провайдера. Резервирование каналов

  • Маша

    А по mikritik балансировке между каналами что-нибудь есть? Это вообще реализуемо между двумя разными провайдерами? А то за два канала платим а работает только один, начальство дало задание: сделать балансировку/распределение между двумя провайдерами именно на микротике …

  • Владимир

    Здравствуйте.
    Подскажите как можно реализовать следующую схему подключения на МИкроТике?
    Порт 1 — WAN1 — Провайдер №1 — получает адрес от провайдера по DHCP
    Порт 2 — WAN2 — Провайдер №2 — получает адрес от провайдера по DHCP
    Порт 3 — LAN1 — сеть с адресами 192.168.0.Х — static
    Порт 4 — LAN2 — сеть с адресами 192.168.1.Х — static
    Порт 5 — LAN3 — сеть с адресами 192.168.2.Х — раздает DHCP

    Для LAN1 — основной провайдер WAN1, в случае потери связи переключение на WAN2 (после восстановления связи с провайдером — обратно на WAN1)

    Для LAN2 и LAN3 — основной провайдер WAN2, в случае потери связи переключение на WAN1 (после восстановления связи с провайдером — обратно на WAN2)

    Если из сети LAN1, LAN3, идет запрос на внешний адрес (на пример) 10.10.10.10 по портам от 1234 до 2345, то пакеты перенаправлять на LAN2 (адрес 192.168.1.5)
    И если есть подключения из вне (на адреса WAN1 и WAN2), то также перенаправлять на LAN2 (на пример на адрес 192.168.1.5).

    Заранее благодарен!!!

    • admin От автора

      Владимир, это очень интересная задача, но я не готов сейчас разложить ее по полочкам и выдать готовое решение. Можно сказать, что это вполне реализуемо.
      Копать нужно в сторону маркировки соединений или пакетов. Создать правила маркировки в IP->Firewall->Mangle, после чего использовать эти отметки в других правилах заворачивая трафик куда нужно, не забывая менять в IP->Firewall->NAT адреса источника и назначения, если это требуется. Скрипт резервирования в этом случае будет сложней, могут быть сложности с тем, что WAN подключается по DHCP, но думаю решение найти можно, поскольку микротик достаточно гибок, а то, что не удается решить предлагаемым интерфейсом можно заскриптовать

  • pit

    вообще-то для правильной работы одновременно по двум провайдерам (имеется ввиду apache за натом) нужно правила в ветке mangle :
    сначала марк роутинг
    а уж потом марк коннект

    кусочек конфига:
    /ip firewall mangle
    add action=mark-routing chain=prerouting connection-mark=inWAN1 dst-address-list=!local_net log-prefix=skymr new-routing-mark=1WAN src-address-list=local_net
    add action=mark-routing chain=prerouting connection-mark=inWAN2 dst-address-list=!local_net log-prefix=tktmr new-routing-mark=2WAN src-address-list=local_net
    add action=mark-connection chain=prerouting dst-address=IP_WAN1 in-interface=ether1_wan1 new-connection-mark=inWAN1
    add action=mark-connection chain=prerouting dst-address=IP_WAN2 in-interface=ether2-wan2 new-connection-mark=inWAN2

    /ip firewall address-list
    add address=192.168.1.0/24 list=local_net
    add address=192.168.2.0/25 list=local_net
    add address=192.168.88.0/24 list=local_net
    add address=10.0.1.0/24 list=local_net

  • Andrey

    Хорошая статья, можно ли все-таки для полноты подкорректировать ее и дописать правила которые нужно «добавить правила маршрутизации отдельно для проверочных хостов.» или отправить на E-Mail.

    • admin От автора

      Тут ничего сложного, просто статические маршруты для проверочных хостов. Например, если проверочный хост 8.8.8.8 для Prov1 то добавить маршрут в main таблицу, где в Distance указывается 8.8.8.8 а next hop — шлюз Prov1

      • Andrey

        Не могли бы вы написать пример для ввода через окно терминала а то не могу найти где там nexthop задается и с какой версией прошивки вы это настраивали, то есть минимальная достаточная версия для Mikrotik?

          • Andrey

            Теперь понятно, спасибо, а по второму вопросу — на какой версии прошивки у вас это работало?

          • Andrey

            Пытаюсь настроить по вашей конфигурации с двумя ISP 1)Etehrnet static IP, 2)USB 3G modem DHCP IP ppp-out1. При попытке прописать правило Mangle для ppp-out1 что указывать в Dst-address тк если указываешь ppp-out1 ругается, требует IP но IP каждый раз другой?

          • Andrey

            Понятно в случае динамического белого IP на 3G надо будет для удобства DDNS использовать, чтобы попасть снаружи на него после очередной смены, в случае динамического серого IP снаружи не попасть вовсе, но изнутри в Интернет в любом случае пользователи смогут без проблем ходить, поэтому вопрос остается актуальным — какой писать IP для ppp-out1 в случае динамического?

          • admin От автора

            Андрей, задача у вас интересная, но эта статья Ваш случай не рассматривает. В mangle можно не указывать Ip в distance, указать только интерфейс. Вообще, в случае динамического IP, теоретически два варианта: либо вы указываете только интерфейс, либо, если не везде можно обойтись без явного указания IP, нужен скрипт который будет этот IP определять и создавать нужные правила. Не проще ли запросить у провайдера статический IP? Ведь есть такая услуга даже на обычных тарифах.

          • Аноним

            В общем то вы правы, однобоко будет без статики — снаружи все равно не зайти будет по резервному каналу, спасибо вам за оперативные ответы на комментарии, тема в статье затронута очень актуальная. Еще бы придумать как 3G не держать постоянно включенным а поднимать только на время сбоя основного канала и выключать потом обратно при восстановлении. А то все эти USB 3G любят подвисать когда долго включенные стоят или очередной костыль делать чтобы питание передергивать периодически.

          • Andrey

            Настроил, все работает в режиме ETTH static IP + USB 3G static IP.
            Компьютеры за роутером работают нормально, запускаю на самом Mikrotik — Check updates — пишет could not resolve address upgrade.mikrotik.com. Запускаю Tools-Ping upgrade.mikrotik.com нормально идет через оба WAN. Вопрос, почему ругается check updates на разрешение имени?

          • Andrey

            Конечно же я не проверяю доступность самого http сервера upgrade.mikrotik.com с помощью ping а использую этот адрес чтобы сработало разрешение имени и оно работает без проблем.

          • admin От автора

            Тут можно посоветовать сохранить текущую конфигурацию, сбросить настройки в заводские, настроить wan обычным образом и проверить check updates. Если ситуация повторяется — можно обратиться к разработчикам, а можно проапдейтить вручную.
            Если не повторяется, значит конфигурация как-то мешает этой функции и нужно разбираться детально. Лично я бы не стал тратить на это время — то, что нужно работает, а обновиться можно и вручную.

          • Andrey

            Конфигурацию уже пробовал сбрасывать, даже делал полную перепрошивку через netinstall без сохранения конфигурации.
            IMHO это как то связано с разной логикой разрешения DNS для check updates.
            В текущей конфигурации с резервированием DNS для ETTH и 3G интерфейсов не определены, для клиентов DHCP сервера назначаются DNS1 Prov1 и DNS2 8.8.8.8. В таком окружении все встроенные утилиты ping, netwatch могут штатно отрезолвить имя upgrade.mikrotik.com, а check updates как то по другому резолвит. И как всегда вы правы, поскольку этот косяк не критичен для самого резервирования и у клиентов за роутером проблем нет, то как вы и сказали можно забить на него и при необходимости обновляться вручную.

  • Andrey

    Похоже вы давно занимаетесь администрированием, видно у вас разумную и обоснованную лень 🙂

    Еще может подскажете что лучше использовать в качестве хостов для проверки работоспособности каналов. Скажем есть некая удаленная точка (назовем Y) которая цепляется к офису (X). Для проверки наличия доступности канала со стороны Y в сторону X с использованием Prov1 я определил IP gateway X + IP DNS1,2 Prov1 при проверке которых также косвенно проверяется gateway Y. Сам IP X в качестве проверяемого не стал использовать тк если сервер в офисе к которому организовано подключение удаленной точки перегружается или недоступен то и соединяться Y не с кем, поэтому Y перескачет на резервный канал. А в качестве проверочных хостов для 3G (Prov2) использую IP DNS Yandex и Google.
    У меня возникает желание использовать что-то другое вместо проверки 2 шт DNS Prov1 тк в принципе один из них может не работать и это допустимо в некоторых случаях.
    А скрипт если я правильно понял логику заточен на то чтобы доходило хотя бы 2 из 3 пингов с каждого из 3х хостов? Если по одному из DNS Prov1 может отключать то уже будет похоже на проблемы канала Prov1 и скрипт переключится на Prov2. Вот и хотелось бы может какой трасе запустить из Y в сторону X и по пути какие узлы есть использовать, но маршрут короткий получается типа Y -> gateway Y — X тк провайдер у Х,Y один и тот же.
    Что можете посоветовать?

    • admin От автора

      В данном случае это элемент вашего творчества. Можно взять DNS Google и Yandex, но с IP отличными от проверок для Prov2. Можно изменить формулу определения доступности канала, можно изменить количество хостов и/или количество запросов к каждому хосту. И так далее. В статье приведены проверочные хосты, которые на момент применения работали в десятках мест с различными провайдерами и проблем с определением доступности зафиксировано не было.

  • ilya

    Добрый день! Небольшое добавление к
    «Не забываем от flush ить существующие NAT таблицы и IPSec SA (на данный момент существует одно стабильное средство — выкл/вкл интерфейс)»

    Если IPsec демон запущен не на передёргиваемом интерфейсе, SA останутся живыми. Более точный способ flushнуть SA — выкл./вкл. IPsec пира.
    Для flush NAT так же можно использовать выкл./вкл. conntrack с задержкой:

    ip firewall connection tracking set enabled=no;
    delay 1
    ip firewall connection tracking set enabled=yes;

    • admin От автора

      Спасибо за дополнение, Илья. Вполне возможно что сейчас, на новых прошивках, работают предложенные вами методы, но на момент написания статьи корректные способы отфлешить NAT не работали. А вот передергивание интерфейса работает стабильно. Думаю, что для надежности можно использовать все способы разом )
      Кстати в скрипте так и реализовано:
      ———————————————
      /interface disable $MainIf
      /ip firewall connection tracking set enabled=no
      delay 5
      /ip firewall connection tracking set enabled=yes
      /ip ipsec installed-sa flush sa-type=all
      /log warning «Switch to reserve internet connection»
      /interface enable $MainIf
      ————————————————————-

      • Andrey

        Здравствуйте, хотелось бы внести изменения в данный скрипт, чтобы получать уведомления о переключениях каналов с помощью /tool -email через smtp.gmail.com , но есть ограничение. Prov1-основной провайдер и имеет выход только в городскую сеть. Prov2-имеет выход во внешку в тч до smtp.gmail.com. Как бы допилить скрипт, чтобы команда /tool e-mail server=[:resolve smtp.gmail.com] отправляла почту всегда только через Prov2 независимо от состояния основного и резервного канала. Натолкните на истинный путь или может черкнете пару строк как пример.

        • Andrey

          Разобрался сам — достаточно проверять перед отправкой E-Mail список [:resolve smtp.gmail.com] и добавлять их в routes:
          ip route add dst-address=173.194.222.108 gateway=Prov2
          ip route add dst-address=173.194.222.109 gateway=Prov2
          и т.д.

          Но готов посмотреть еще альтернативные решения если кто поделится…

          • Andrey

            Здравствуйте, вы написали в статье «Если нужно – правила проброса портов на сервисы DMZ, в двух вариантах – для каждого провайдера. После этих настроек у нас должны заработать – сам микротик и настроенные пробросы портов должны заработать независимо на двух каналах связи.»
            Не могли бы вы привести пример проброса какого-нибудь одного порта через каждого провайдера чтобы сервис был доступен при заходе с любого из провайдеров.

  • Олег

    В ходе настройки вашего решения встретился со странной проблемой. Скрипт просто не выполняется хотя счетчик выполнений растёт. даже поставив в начало скрипта /log error «test» в логах ничего не пишется. Можете подсказать как с этим бороться?
    устройство hap AC lite

    • Олег

      делает ли
      /ip firewall connection tracking set enabled=no
      тоже самое что и
      foreach i in=[/ip firewall connection find] do={/ip firewall connection remove $i}
      это рекомендует volink для правильной работы asterisk при переключении. Без этой строчки ломается связь.

      • Andrey

        Здравствуйте, вы написали в статье “Если нужно – правила проброса портов на сервисы DMZ, в двух вариантах – для каждого провайдера. После этих настроек у нас должны заработать – сам микротик и настроенные пробросы портов должны заработать независимо на двух каналах связи.”
        Не могли бы вы привести пример проброса какого-нибудь одного порта через каждого провайдера чтобы сервис был доступен при заходе с любого из провайдеров.

      • Валерий

        Олег, нет, это не то же самое. Первый вариант работает гораздо надежней и был выбран после тестов второго варианта, который не всегда срабатывал.
        Только если я правильно помню нужно так же делать выкл/вкл интерфейса.

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

        • Салоед

          не понял, как будет скрипт переключения срабатывать? он же должен переодически запускатьсясам или как?

          и как мониторить логи скрипта, т.е. вручную запустил, а рехультат не видно.

          • Аноним

            Вам просто нужно настроить system => scheduler и там создаете правило с запуском скрипта с определенным интервалом

  • Павел

    Добрый день, спасибо большое за статью! За подробное объяснение.
    Но возникла одна проблема, когда оба провайдера в рабочем состоянии, и все пользователи идут через основного провайдера, отсутствует доступ к ресурсам сети второго провайдера. Т.е. получается работают они не одновременно, инструкцию перепроверил несколько раз. Причём запрос на второго провайдера приходит (это видно в статистике) но дальше роутера не идёт, либо идёт но через другой шлюз (первого провайдера). Если Вам не сложно, могли бы вы меня натолкнуть что не правильно в настройках. Спасибо.

  • Илья

    Прошу расписать инструкцию по «Осталось запилить механизм, который будет переключать основной маршрут в зависимости от состояния каналов.», чтобы не сделать ошибку.

  • Евгений

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

    Версия 6.38.1

    • admin От автора

      Один из вариантов отладки: вставлять в скрипте строчки вывода в системный лог. Место вставки определяет та часть логики скрипта, отработку которой нужно проверить.

      • Евгений

        да в скрипте были синтаксические ошибки, видимо связанные с разными версиями ОС /ip ipsec installed-sa flush этого достаточно и sa-type=all указывать не нужно! В дальнейшем я отказался вообще от использования скрипта, настроив резервирование на основе рекурсивных маршрутов с разными значениями distance для основного и резервных каналов. Всё взлетело.

        • Евгений

          вот пример моего конфига с 6 маршрутами
          /ip route
          add distance=1 gateway=xxx.xxx.xxx.xxx routing-mark=Prov1
          add distance=2 gateway=xxx.xxx.xxx.xxx routing-mark=Prov2
          add distance=1 gateway=8.8.8.8
          add distance=2 gateway=8.8.4.4
          add check-gateway=ping comment=Prov2 distance=2 dst-address=8.8.4.4/32 gateway=xxx.xxx.xxx.xxx scope=10
          add check-gateway=ping comment=Prov1 distance=1 dst-address=8.8.8.8/32 gateway=xxx.xxx.xxx.xxx scope=10

          • Андрей

            Евгений, не могли бы вы привести полный вариант скрипта с проверкой через рекурсивные маршруты?

  • никита

    а сколько занимает время переключения с основного на резервный и происходит ли обрыв сессии? и возможно ли к данному примеру прикрутить тонели ip-to-ip c резервировинием .спасибо

    • Валерий Москалев От автора

      Время будет зависит от того как часто Вы поставите выполнятся скрипт проверки.
      Сам скрипт отрабатывает достаточно быстро: 6-10 секунд

      Сессия обрывается и не может не обрываться при такой схеме (ведь для внешнего ресурса меняется IP источника). Более того, скрипт это делает нарочно:

      /interface disable $MainIf
      /ip firewall connection tracking set enabled=no
      delay 5
      /ip firewall connection tracking set enabled=yes
      /ip ipsec installed-sa flush sa-type=all

      чтобы переключение на новый канал произошло быстрее (не дожидаясь таймаутов сессии).

      Туннели будут восстанавливаться при такой схеме резервирования, если инициатор соединения микротик, а принимающая сторона не привязывается к IP инициатора.

      Можно придумать различные схемы резервирования для разных случаев. Но это выходит за рамки статьи.