Два провайдера на MikroTik — failover и балансировка

Подключение двух интернет-провайдеров к одному MikroTik — одна из самых востребованных задач в малом и среднем бизнесе. Потеря интернета даже на 10 минут означает простой IP-телефонии, CRM, платёжных терминалов и удалённого доступа. В этом руководстве разберём три способа организации резервирования: простой failover, recursive routing и балансировку нагрузки через PCC.

Инструкция актуальна для RouterOS 7.x и подходит для любых моделей с двумя и более Ethernet-портами: hAP ax2, hAP ax3, RB5009, CCR2004, hex S и других.

Зачем два провайдера

Один провайдер — одна точка отказа. Причины падения разнообразны: обрыв кабеля при строительных работах, авария на стороне провайдера, плановое обслуживание, DDoS-атака на инфраструктуру, проблемы с DNS или BGP. Даже провайдер с SLA 99.9% допускает до 8 часов простоя в год — и эти 8 часов обычно приходятся на самый неподходящий момент.

В офисе с IP-телефонией, облачной CRM или платёжными терминалами даже 5 минут без интернета — это потерянные звонки, недовольные клиенты и упущенная выручка. Второй канал стоит сравнительно недорого, а MikroTik позволяет настроить автоматическое переключение без дополнительного оборудования.

Второй канал решает эту проблему. В зависимости от требований вы можете настроить:

• Failover — основной канал работает постоянно, резервный включается автоматически при падении основного. Самый простой и надёжный вариант.
• Recursive routing — улучшенный failover с проверкой доступности не шлюза, а реального хоста в интернете. Обнаруживает проблемы, которые обычный check-gateway пропускает.
• Load balancing (PCC) — трафик распределяется между двумя каналами одновременно. Максимальная утилизация каналов, но есть ограничения.

Подготовка: два WAN-интерфейса

Предположим следующую топологию:

• ether1 — ISP1 (основной), получает адрес 10.0.1.100/24, шлюз 10.0.1.1
• ether2 — ISP2 (резервный), получает адрес 172.16.0.100/24, шлюз 172.16.0.1
• bridge-LAN — локальная сеть 192.168.88.0/24

Назначим адреса на WAN-интерфейсы (если провайдер не выдаёт адрес по DHCP):

[admin@MikroTik] >
Копировать
/ip/address
add address=10.0.1.100/24 interface=ether1 comment="ISP1"
add address=172.16.0.100/24 interface=ether2 comment="ISP2"

Если один или оба провайдера выдают адрес по DHCP:

[admin@MikroTik] >
Копировать
/ip/dhcp-client
add interface=ether1 add-default-route=no comment="ISP1-DHCP"
add interface=ether2 add-default-route=no comment="ISP2-DHCP"

Обратите внимание на add-default-route=no — маршруты по умолчанию мы будем создавать вручную, чтобы контролировать приоритеты и проверку доступности.

Способ 1 — Failover через distance и check-gateway

Это самый простой и понятный метод. Создаём два маршрута по умолчанию с разными значениями distance. Маршрут с меньшим distance имеет приоритет. Параметр check-gateway=ping заставляет RouterOS периодически пинговать шлюз — если он не отвечает, маршрут деактивируется и трафик переключается на резервный канал.

[admin@MikroTik] >
Копировать
/ip/route
add dst-address=0.0.0.0/0 gateway=10.0.1.1 distance=1 check-gateway=ping comment="ISP1-primary"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 distance=2 check-gateway=ping comment="ISP2-backup"

Проверяем таблицу маршрутизации:

[admin@MikroTik] >
Копировать
/ip/route print where dst-address=0.0.0.0/0

Вы должны увидеть оба маршрута. Маршрут через ISP1 будет active (distance=1), маршрут через ISP2 — в резерве (distance=2).

Как это работает: RouterOS отправляет ICMP-запросы на адрес шлюза каждые 10 секунд. Если три запроса подряд остаются без ответа, маршрут помечается как unreachable, и трафик переключается на следующий маршрут с минимальным distance. Когда шлюз снова отвечает — маршрут восстанавливается.

Недостаток: check-gateway проверяет только доступность шлюза провайдера. Если шлюз отвечает на ping, но интернет за ним недоступен (проблема на магистрали, ошибка маршрутизации у провайдера), переключение не произойдёт. Для решения этой проблемы используйте recursive routing.

Способ 2 — Recursive routing (более надёжный)

Recursive routing решает главную проблему простого failover: он проверяет доступность не шлюза, а реального хоста в интернете. Идея в том, чтобы создать «цепочку» маршрутов — сначала маршрут до контрольного хоста через шлюз провайдера, затем маршрут по умолчанию через этот контрольный хост.

Выбираем два надёжных хоста для проверки. Используем публичные DNS-серверы — они имеют высокую доступность:

• 1.1.1.1 (Cloudflare DNS) — для проверки ISP1
• 8.8.4.4 (Google DNS) — для проверки ISP2

Шаг 1: Создаём маршруты до контрольных хостов через шлюзы провайдеров.

[admin@MikroTik] >
Копировать
/ip/route
add dst-address=1.1.1.1/32 gateway=10.0.1.1 scope=10 comment="Check-ISP1"
add dst-address=8.8.4.4/32 gateway=172.16.0.1 scope=10 comment="Check-ISP2"

Шаг 2: Создаём маршруты по умолчанию, которые используют контрольные хосты в качестве gateway. Параметр target-scope должен быть больше или равен значению scope из шага 1.

[admin@MikroTik] >
Копировать
/ip/route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="ISP1-recursive"
add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 target-scope=11 check-gateway=ping comment="ISP2-recursive"

Как это работает: RouterOS пингует 1.1.1.1 через ISP1. Если 1.1.1.1 недоступен (шлюз упал, провайдер потерял связность, магистраль легла) — первый маршрут по умолчанию деактивируется и трафик переходит на ISP2 через 8.8.4.4. Это надёжнее, чем проверка шлюза, потому что мы проверяем реальную связность с интернетом.

Проверяем, что маршруты активны:

[admin@MikroTik] >
Копировать
/ip/route print detail where dst-address=0.0.0.0/0

Важно: не используйте один и тот же контрольный хост для обоих провайдеров. Если выбрать 1.1.1.1 для обоих — трафик до 1.1.1.1 всегда пойдёт через ISP1 (из-за маршрута с dst-address=1.1.1.1/32), и проверка ISP2 будет некорректной.

Важно: убедитесь, что значения scope и target-scope настроены правильно. По умолчанию scope маршрутов — 30, а target-scope — 10. Для recursive routing нужно, чтобы target-scope рекурсивного маршрута (11) был >= scope маршрута до контрольного хоста (10).

Способ 3 — Load balancing через PCC

Per Connection Classifier (PCC) распределяет соединения между двумя каналами на основе хеша адресов и портов. Каждое новое соединение «прикрепляется» к одному из каналов и продолжает использовать его до завершения. Это обеспечивает балансировку нагрузки с сохранением целостности сессий.

Предупреждение: PCC разбивает трафик по соединениям, а не по пакетам. Однако некоторые сервисы привязывают сессию к IP-адресу: интернет-банкинг, VPN-подключения, некоторые системы авторизации (OAuth). При балансировке через PCC запросы одного пользователя могут приходить с разных IP-адресов, что приводит к разрывам сессий и блокировкам. Для большинства пользователей простой failover или recursive routing — более безопасный выбор. Используйте PCC только если вам действительно нужна балансировка и вы готовы обрабатывать исключения.

Шаг 1: Маркируем соединения. Mangle-правила распределяют трафик из LAN 50/50 по двум каналам.

[admin@MikroTik] >
Копировать
/ip/firewall/mangle
add chain=prerouting src-address=192.168.88.0/24 in-interface=bridge-LAN \
    connection-state=new per-connection-classifier=both-addresses:2/0 \
    action=mark-connection new-connection-mark=ISP1-conn passthrough=yes \
    comment="PCC-mark-ISP1"
add chain=prerouting src-address=192.168.88.0/24 in-interface=bridge-LAN \
    connection-state=new per-connection-classifier=both-addresses:2/1 \
    action=mark-connection new-connection-mark=ISP2-conn passthrough=yes \
    comment="PCC-mark-ISP2"

Шаг 2: Маркируем маршруты на основе меток соединений.

[admin@MikroTik] >
Копировать
/ip/firewall/mangle
add chain=prerouting connection-mark=ISP1-conn in-interface=bridge-LAN \
    action=mark-routing new-routing-mark=to-ISP1 passthrough=no \
    comment="PCC-route-ISP1"
add chain=prerouting connection-mark=ISP2-conn in-interface=bridge-LAN \
    action=mark-routing new-routing-mark=to-ISP2 passthrough=no \
    comment="PCC-route-ISP2"

Шаг 3: Создаём маршруты для каждой метки и общий маршрут failover.

[admin@MikroTik] >
Копировать
/ip/route
add dst-address=0.0.0.0/0 gateway=10.0.1.1 routing-mark=to-ISP1 distance=1 check-gateway=ping comment="PCC-ISP1"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 routing-mark=to-ISP2 distance=1 check-gateway=ping comment="PCC-ISP2"
add dst-address=0.0.0.0/0 gateway=10.0.1.1 distance=1 check-gateway=ping comment="Fallback-ISP1"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 distance=2 check-gateway=ping comment="Fallback-ISP2"

Два последних маршрута без routing-mark обеспечивают failover для трафика самого роутера (DNS-запросы, NTP, обновления) и для ситуаций, когда один из каналов падает.

NAT для двух провайдеров

При использовании двух WAN-интерфейсов необходимо настроить masquerade или src-nat для каждого из них. Если использовать одно правило masquerade без привязки к интерфейсу, пакеты могут уходить с неправильным source-адресом.

Вариант с masquerade (проще, подходит для динамических адресов):

[admin@MikroTik] >
Копировать
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=masquerade comment="NAT-ISP1"
add chain=srcnat out-interface=ether2 action=masquerade comment="NAT-ISP2"

Вариант с src-nat (эффективнее, подходит для статических адресов):

[admin@MikroTik] >
Копировать
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=src-nat to-addresses=10.0.1.100 comment="SNAT-ISP1"
add chain=srcnat out-interface=ether2 action=src-nat to-addresses=172.16.0.100 comment="SNAT-ISP2"

Рекомендация: если адрес от провайдера статический — используйте src-nat. Он работает быстрее, потому что не тратит ресурсы на определение исходящего адреса. Для DHCP — используйте masquerade, так как адрес может измениться.

DNS при failover

Проблема: если вы используете DNS-серверы только одного провайдера, при его падении DNS-разрешение перестанет работать даже при переключении на резервный канал. Решение — использовать публичные DNS-серверы.

[admin@MikroTik] >
Копировать
/ip/dns
set servers=1.1.1.1,8.8.8.8,8.8.4.4,1.0.0.1 allow-remote-requests=yes cache-size=4096KiB

Если вы используете recursive routing с контрольными хостами 1.1.1.1 и 8.8.4.4, добавьте дополнительные DNS-серверы, которые не совпадают с контрольными хостами, или убедитесь, что маршруты до DNS-серверов корректны.

Также полезно увеличить размер кэша DNS. При переключении провайдера кэш сохранит часть записей и ускорит работу в переходный период.

Для надёжности можно настроить DNS-over-HTTPS (DoH) в RouterOS 7:

[admin@MikroTik] >
Копировать
/ip/dns
set use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes

Перед включением DoH импортируйте корневые сертификаты:

[admin@MikroTik] >
Копировать
/tool/fetch url=https://curl.se/ca/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Netwatch для мониторинга и уведомлений

Netwatch — встроенный инструмент мониторинга, который выполняет заданные скрипты при изменении доступности хоста. Используем его для логирования переключений и отправки уведомлений.

Базовый мониторинг ISP1:

[admin@MikroTik] >
Копировать
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP1: link restored\"" \
    down-script="/log error \"ISP1: link down, switching to ISP2\"" \
    comment="Monitor-ISP1"

Базовый мониторинг ISP2:

[admin@MikroTik] >
Копировать
/tool/netwatch
add host=8.8.4.4 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP2: link restored\"" \
    down-script="/log error \"ISP2: link down\"" \
    comment="Monitor-ISP2"

Расширенный мониторинг с уведомлением по email:

Сначала настройте SMTP (используйте app password для Gmail):

[admin@MikroTik] >
Копировать
/tool/e-mail
set server=smtp.gmail.com port=587 start-tls=yes \
    from=router@yourdomain.com user=your@gmail.com password="app-password"

Затем создайте Netwatch с отправкой email при падении:

[admin@MikroTik] >
Копировать
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    down-script={
        /log error "ISP1 DOWN - failover activated"
        /tool e-mail send to="admin@yourdomain.com" \
            subject="[MikroTik] ISP1 DOWN" \
            body="Primary ISP is unreachable. Failover to ISP2 activated."
    } \
    up-script={
        /log warning "ISP1 UP - primary link restored"
        /tool e-mail send to="admin@yourdomain.com" \
            subject="[MikroTik] ISP1 UP" \
            body="Primary ISP is back online. Traffic restored to ISP1."
    } \
    comment="Monitor-ISP1-email"

Мониторинг с проверкой HTTP (RouterOS 7.1+):

[admin@MikroTik] >
Копировать
/tool/netwatch
add host=1.1.1.1 type=http-get http-code-min=200 http-code-max=399 \
    interval=60s timeout=3000ms \
    down-script="/log error \"ISP1: HTTP check failed\"" \
    comment="Monitor-ISP1-HTTP"

Скрипт автопереключения

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

Создаём скрипт:

[admin@MikroTik] >
Копировать
/system/script
add name="failover-check" policy=read,write,test source={
    :local pingTarget1 "1.1.1.1"
    :local pingTarget2 "8.8.4.4"
    :local isp1Gateway "10.0.1.1"
    :local isp2Gateway "172.16.0.1"
    :local isp1Interface "ether1"
    :local isp2Interface "ether2"

    # Проверяем ISP1 — пингуем через конкретный интерфейс
    :local isp1Status [/ping $pingTarget1 count=3 interface=$isp1Interface]
    :local isp2Status [/ping $pingTarget2 count=3 interface=$isp2Interface]

    # Получаем текущее состояние маршрутов
    :local route1Active [/ip/route find where gateway=$isp1Gateway dst-address=0.0.0.0/0 distance=1]
    :local route2Active [/ip/route find where gateway=$isp2Gateway dst-address=0.0.0.0/0 distance=2]

    :if ($isp1Status = 0) do={
        :if ([/ip/route get $route1Active disabled] = false) do={
            /ip/route set $route1Active disabled=yes
            /log error "Failover script: ISP1 down, disabling primary route"
        }
    } else={
        :if ([/ip/route get $route1Active disabled] = true) do={
            /ip/route set $route1Active disabled=no
            /log warning "Failover script: ISP1 restored, enabling primary route"
        }
    }

    :if ($isp2Status = 0) do={
        :if ([/ip/route get $route2Active disabled] = false) do={
            /ip/route set $route2Active disabled=yes
            /log error "Failover script: ISP2 down, disabling backup route"
        }
    } else={
        :if ([/ip/route get $route2Active disabled] = true) do={
            /ip/route set $route2Active disabled=no
            /log warning "Failover script: ISP2 restored, enabling backup route"
        }
    }
}

Настраиваем запуск по расписанию каждые 30 секунд:

[admin@MikroTik] >
Копировать
/system/scheduler
add name="failover-scheduler" interval=30s \
    on-event="/system/script/run failover-check" \
    policy=read,write,test comment="Run failover check every 30s"

Проверка работы

После настройки важно убедиться, что failover работает корректно. Вот пошаговый план тестирования.

1. Проверяем текущие маршруты:

[admin@MikroTik] >
Копировать
/ip/route print where dst-address=0.0.0.0/0

Убедитесь, что основной маршрут (distance=1) активен, резервный (distance=2) — в таблице, но не активен как preferred.

2. Проверяем NAT:

[admin@MikroTik] >
Копировать
/ip/firewall/nat print

Должны быть правила masquerade или src-nat для обоих WAN-интерфейсов.

3. Трассировка через каждый канал:

[admin@MikroTik] >
Копировать
/tool/traceroute 8.8.8.8

Первый хоп должен быть шлюзом ISP1 (10.0.1.1). Запомните маршрут.

4. Имитируем падение ISP1:

Физически отключите кабель из ether1, или программно:

[admin@MikroTik] >
Копировать
/interface/disable ether1

Подождите 30-40 секунд (время на обнаружение и переключение) и проверьте:

[admin@MikroTik] >
Копировать
/ip/route print where dst-address=0.0.0.0/0
/tool/traceroute 8.8.8.8

Теперь первый хоп должен быть шлюзом ISP2 (172.16.0.1). Проверьте лог:

[admin@MikroTik] >
Копировать
/log print where topics~"warning|error"

5. Восстанавливаем ISP1:

[admin@MikroTik] >
Копировать
/interface/enable ether1

Через 10-20 секунд трафик должен вернуться на ISP1. Проверьте трассировкой.

6. Проверяем скорость обратного переключения:

Засеките время между включением интерфейса и появлением маршрута. Для check-gateway=ping это обычно 10-30 секунд. Для recursive routing — до 60 секунд в зависимости от настроек интервала.

7. Мониторинг в реальном времени:

[admin@MikroTik] >
Копировать
/tool/torch interface=ether1
/tool/torch interface=ether2

Torch показывает трафик в реальном времени. При переключении вы увидите, как трафик пропадает на одном интерфейсе и появляется на другом.

8. Проверяем обратное переключение при PCC:

Если вы настроили PCC, отключите поочерёдно каждый канал и убедитесь, что весь трафик уходит через оставшийся. Проверьте, что после восстановления обоих каналов балансировка возобновляется:

[admin@MikroTik] >
Копировать
/ip/firewall/mangle print stats where comment~"PCC"

Счётчики пакетов и байтов покажут, как распределяется нагрузка. В идеале значения должны быть примерно равными (точное соотношение 50/50 не гарантируется — это зависит от характера трафика).

Connection tracking и failover

При переключении между провайдерами существующие соединения (TCP-сессии) обрываются, потому что меняется source IP. Это нормальное поведение. Новые соединения установятся через резервный канал автоматически.

Для ускорения восстановления можно уменьшить таймауты connection tracking:

[admin@MikroTik] >
Копировать
/ip/firewall/connection/tracking
set tcp-established-timeout=3600s tcp-close-wait-timeout=10s tcp-time-wait-timeout=10s

Если нужно принудительно сбросить все соединения после переключения (чтобы приложения быстрее переподключились):

[admin@MikroTik] >
Копировать
/ip/firewall/connection/remove [find]

Эту команду можно добавить в down-script Netwatch, чтобы она выполнялась автоматически при падении канала.

Дополнительно стоит учитывать UDP-трафик. В отличие от TCP, UDP не имеет механизма повторной передачи, поэтому VoIP-звонки и видеоконференции прерываются мгновенно при переключении. Приложения должны самостоятельно переустановить соединение. Для SIP-телефонии рекомендуется уменьшить registration timeout на телефонных аппаратах до 60-120 секунд — так телефоны быстрее перерегистрируются через новый канал.

Правила Firewall при двух WAN

При двух WAN-интерфейсах не забудьте обновить правила firewall. Типичная ошибка — защитить только один WAN-интерфейс.

Создайте interface list для удобства:

[admin@MikroTik] >
Копировать
/interface/list
add name=WAN
/interface/list/member
add interface=ether1 list=WAN
add interface=ether2 list=WAN

Используйте interface list в правилах firewall вместо указания конкретного интерфейса:

[admin@MikroTik] >
Копировать
/ip/firewall/filter
add chain=input in-interface-list=WAN connection-state=established,related action=accept
add chain=input in-interface-list=WAN protocol=icmp action=accept comment="Allow ICMP from WAN"
add chain=input in-interface-list=WAN action=drop comment="Drop all from WAN"

add chain=forward in-interface-list=WAN connection-state=established,related action=accept
add chain=forward in-interface-list=WAN connection-state=new action=drop comment="Drop new from WAN to LAN"

Такой подход гарантирует, что при добавлении третьего провайдера вам достаточно добавить интерфейс в list WAN — правила firewall обновятся автоматически. Не придётся дублировать каждое правило для каждого интерфейса.

Типичные ошибки

1. Забыли NAT для второго провайдера. Самая частая ошибка. Трафик переключается на ISP2, но пакеты уходят с source-адресом сети ISP1. Провайдер их отбрасывает (RPF/BCP38). Решение: отдельное правило masquerade для каждого WAN-интерфейса.

2. DHCP-клиент создаёт маршрут автоматически. Если провайдер выдаёт адрес по DHCP, клиент создаёт маршрут по умолчанию с distance=1 по умолчанию. Это конфликтует с вашими ручными маршрутами. Решение: add-default-route=no в настройках DHCP-клиента.

3. Одинаковый distance на обоих маршрутах. Если оба маршрута имеют distance=1, RouterOS будет использовать ECMP (Equal-Cost Multi-Path) — это не failover и не контролируемая балансировка. Убедитесь, что distance различается.

4. check-gateway без gateway на одном L2-домене. Если шлюз провайдера доступен на канальном уровне (ARP отвечает), но не маршрутизирует трафик — check-gateway=ping покажет шлюз как доступный. Используйте recursive routing для таких случаев.

5. Не обновили DNS. При использовании DNS-серверов провайдера ISP1 — после переключения на ISP2 DNS перестаёт работать. Используйте публичные DNS (1.1.1.1, 8.8.8.8) или настройте DoH.

6. Не настроили firewall на втором WAN. Второй WAN-интерфейс — это ещё одна точка входа для атак. Используйте interface list WAN и применяйте правила фильтрации ко всем WAN-интерфейсам.

7. PCC без понимания последствий. PCC ломает сервисы, привязанные к IP: банковские приложения разлогинивают пользователей, VPN-туннели обрываются, OAuth-авторизация не проходит. Если вы не уверены — используйте простой failover.

8. Неправильные scope и target-scope в recursive routing. Если target-scope рекурсивного маршрута меньше scope маршрута до контрольного хоста — маршрут не активируется. Проверяйте: target-scope >= scope.

9. Контрольный хост стал недоступен. Если 1.1.1.1 или 8.8.4.4 временно упал (крайне редко, но возможно), failover сработает ложно. Для минимизации этого риска можно использовать скрипт, который проверяет несколько хостов и принимает решение по большинству.

10. Слишком агрессивные таймауты. Если поставить interval=5s в Netwatch или check-gateway, при кратковременных потерях пакетов будут постоянные переключения (flapping). Рекомендуемый интервал — 20-30 секунд для Netwatch, а check-gateway использует фиксированный 10-секундный интервал с порогом в 3 потери.

Итоговая рекомендация

Для большинства сценариев рекомендуем recursive routing — это оптимальный баланс между надёжностью и простотой. Он обнаруживает проблемы, которые обычный check-gateway пропускает, и не имеет побочных эффектов PCC.

Минимальная конфигурация для production:

[admin@MikroTik] >
Копировать
# Маршруты до контрольных хостов
/ip/route
add dst-address=1.1.1.1/32 gateway=10.0.1.1 scope=10 comment="Probe-ISP1"
add dst-address=8.8.4.4/32 gateway=172.16.0.1 scope=10 comment="Probe-ISP2"

# Рекурсивные маршруты по умолчанию
/ip/route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="Default-ISP1"
add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 target-scope=11 check-gateway=ping comment="Default-ISP2"

# NAT для обоих провайдеров
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=masquerade comment="NAT-ISP1"
add chain=srcnat out-interface=ether2 action=masquerade comment="NAT-ISP2"

# DNS — публичные серверы
/ip/dns set servers=1.1.1.1,8.8.8.8,1.0.0.1,8.8.4.4 allow-remote-requests=yes

# Мониторинг
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP1 restored\"" \
    down-script="/log error \"ISP1 down\""
add host=8.8.4.4 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP2 restored\"" \
    down-script="/log error \"ISP2 down\""

Эта конфигурация обеспечивает автоматическое переключение на резервный канал при любых проблемах с основным провайдером, корректный NAT для обоих каналов, DNS-резольвинг через публичные серверы и мониторинг с записью событий в лог.

Не забудьте также настроить firewall для обоих WAN-интерфейсов (см. раздел выше) и проверить работу по пошаговому плану из раздела «Проверка работы». После настройки рекомендуется экспортировать конфигурацию для резервного копирования:

[admin@MikroTik] >
Копировать
/export file=failover-config
/system/backup/save name=failover-backup encryption=aes-sha256

Храните резервную копию за пределами роутера. В случае аппаратного сбоя вы сможете быстро восстановить конфигурацию на новом устройстве.

/ip/address
add address=10.0.1.100/24 interface=ether1 comment="ISP1"
add address=172.16.0.100/24 interface=ether2 comment="ISP2"
/ip/dhcp-client
add interface=ether1 add-default-route=no comment="ISP1-DHCP"
add interface=ether2 add-default-route=no comment="ISP2-DHCP"
/ip/route
add dst-address=0.0.0.0/0 gateway=10.0.1.1 distance=1 check-gateway=ping comment="ISP1-primary"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 distance=2 check-gateway=ping comment="ISP2-backup"
/ip/route print where dst-address=0.0.0.0/0
/ip/route
add dst-address=1.1.1.1/32 gateway=10.0.1.1 scope=10 comment="Check-ISP1"
add dst-address=8.8.4.4/32 gateway=172.16.0.1 scope=10 comment="Check-ISP2"
/ip/route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="ISP1-recursive"
add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 target-scope=11 check-gateway=ping comment="ISP2-recursive"
/ip/route print detail where dst-address=0.0.0.0/0
/ip/firewall/mangle
add chain=prerouting src-address=192.168.88.0/24 in-interface=bridge-LAN \
    connection-state=new per-connection-classifier=both-addresses:2/0 \
    action=mark-connection new-connection-mark=ISP1-conn passthrough=yes \
    comment="PCC-mark-ISP1"
add chain=prerouting src-address=192.168.88.0/24 in-interface=bridge-LAN \
    connection-state=new per-connection-classifier=both-addresses:2/1 \
    action=mark-connection new-connection-mark=ISP2-conn passthrough=yes \
    comment="PCC-mark-ISP2"
/ip/firewall/mangle
add chain=prerouting connection-mark=ISP1-conn in-interface=bridge-LAN \
    action=mark-routing new-routing-mark=to-ISP1 passthrough=no \
    comment="PCC-route-ISP1"
add chain=prerouting connection-mark=ISP2-conn in-interface=bridge-LAN \
    action=mark-routing new-routing-mark=to-ISP2 passthrough=no \
    comment="PCC-route-ISP2"
/ip/route
add dst-address=0.0.0.0/0 gateway=10.0.1.1 routing-mark=to-ISP1 distance=1 check-gateway=ping comment="PCC-ISP1"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 routing-mark=to-ISP2 distance=1 check-gateway=ping comment="PCC-ISP2"
add dst-address=0.0.0.0/0 gateway=10.0.1.1 distance=1 check-gateway=ping comment="Fallback-ISP1"
add dst-address=0.0.0.0/0 gateway=172.16.0.1 distance=2 check-gateway=ping comment="Fallback-ISP2"
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=masquerade comment="NAT-ISP1"
add chain=srcnat out-interface=ether2 action=masquerade comment="NAT-ISP2"
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=src-nat to-addresses=10.0.1.100 comment="SNAT-ISP1"
add chain=srcnat out-interface=ether2 action=src-nat to-addresses=172.16.0.100 comment="SNAT-ISP2"
/ip/dns
set servers=1.1.1.1,8.8.8.8,8.8.4.4,1.0.0.1 allow-remote-requests=yes cache-size=4096KiB
/ip/dns
set use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/tool/fetch url=https://curl.se/ca/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP1: link restored\"" \
    down-script="/log error \"ISP1: link down, switching to ISP2\"" \
    comment="Monitor-ISP1"
/tool/netwatch
add host=8.8.4.4 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP2: link restored\"" \
    down-script="/log error \"ISP2: link down\"" \
    comment="Monitor-ISP2"
/tool/e-mail
set server=smtp.gmail.com port=587 start-tls=yes \
    from=router@yourdomain.com user=your@gmail.com password="app-password"
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    down-script={
        /log error "ISP1 DOWN - failover activated"
        /tool e-mail send to="admin@yourdomain.com" \
            subject="[MikroTik] ISP1 DOWN" \
            body="Primary ISP is unreachable. Failover to ISP2 activated."
    } \
    up-script={
        /log warning "ISP1 UP - primary link restored"
        /tool e-mail send to="admin@yourdomain.com" \
            subject="[MikroTik] ISP1 UP" \
            body="Primary ISP is back online. Traffic restored to ISP1."
    } \
    comment="Monitor-ISP1-email"
/tool/netwatch
add host=1.1.1.1 type=http-get http-code-min=200 http-code-max=399 \
    interval=60s timeout=3000ms \
    down-script="/log error \"ISP1: HTTP check failed\"" \
    comment="Monitor-ISP1-HTTP"
/system/script
add name="failover-check" policy=read,write,test source={
    :local pingTarget1 "1.1.1.1"
    :local pingTarget2 "8.8.4.4"
    :local isp1Gateway "10.0.1.1"
    :local isp2Gateway "172.16.0.1"
    :local isp1Interface "ether1"
    :local isp2Interface "ether2"

    # Проверяем ISP1 — пингуем через конкретный интерфейс
    :local isp1Status [/ping $pingTarget1 count=3 interface=$isp1Interface]
    :local isp2Status [/ping $pingTarget2 count=3 interface=$isp2Interface]

    # Получаем текущее состояние маршрутов
    :local route1Active [/ip/route find where gateway=$isp1Gateway dst-address=0.0.0.0/0 distance=1]
    :local route2Active [/ip/route find where gateway=$isp2Gateway dst-address=0.0.0.0/0 distance=2]

    :if ($isp1Status = 0) do={
        :if ([/ip/route get $route1Active disabled] = false) do={
            /ip/route set $route1Active disabled=yes
            /log error "Failover script: ISP1 down, disabling primary route"
        }
    } else={
        :if ([/ip/route get $route1Active disabled] = true) do={
            /ip/route set $route1Active disabled=no
            /log warning "Failover script: ISP1 restored, enabling primary route"
        }
    }

    :if ($isp2Status = 0) do={
        :if ([/ip/route get $route2Active disabled] = false) do={
            /ip/route set $route2Active disabled=yes
            /log error "Failover script: ISP2 down, disabling backup route"
        }
    } else={
        :if ([/ip/route get $route2Active disabled] = true) do={
            /ip/route set $route2Active disabled=no
            /log warning "Failover script: ISP2 restored, enabling backup route"
        }
    }
}
/system/scheduler
add name="failover-scheduler" interval=30s \
    on-event="/system/script/run failover-check" \
    policy=read,write,test comment="Run failover check every 30s"
/ip/route print where dst-address=0.0.0.0/0
/ip/firewall/nat print
/tool/traceroute 8.8.8.8
/interface/disable ether1
/ip/route print where dst-address=0.0.0.0/0
/tool/traceroute 8.8.8.8
/log print where topics~"warning|error"
/interface/enable ether1
/tool/torch interface=ether1
/tool/torch interface=ether2
/ip/firewall/mangle print stats where comment~"PCC"
/ip/firewall/connection/tracking
set tcp-established-timeout=3600s tcp-close-wait-timeout=10s tcp-time-wait-timeout=10s
/ip/firewall/connection/remove [find]
/interface/list
add name=WAN
/interface/list/member
add interface=ether1 list=WAN
add interface=ether2 list=WAN
/ip/firewall/filter
add chain=input in-interface-list=WAN connection-state=established,related action=accept
add chain=input in-interface-list=WAN protocol=icmp action=accept comment="Allow ICMP from WAN"
add chain=input in-interface-list=WAN action=drop comment="Drop all from WAN"

add chain=forward in-interface-list=WAN connection-state=established,related action=accept
add chain=forward in-interface-list=WAN connection-state=new action=drop comment="Drop new from WAN to LAN"
# Маршруты до контрольных хостов
/ip/route
add dst-address=1.1.1.1/32 gateway=10.0.1.1 scope=10 comment="Probe-ISP1"
add dst-address=8.8.4.4/32 gateway=172.16.0.1 scope=10 comment="Probe-ISP2"

# Рекурсивные маршруты по умолчанию
/ip/route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="Default-ISP1"
add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 target-scope=11 check-gateway=ping comment="Default-ISP2"

# NAT для обоих провайдеров
/ip/firewall/nat
add chain=srcnat out-interface=ether1 action=masquerade comment="NAT-ISP1"
add chain=srcnat out-interface=ether2 action=masquerade comment="NAT-ISP2"

# DNS — публичные серверы
/ip/dns set servers=1.1.1.1,8.8.8.8,1.0.0.1,8.8.4.4 allow-remote-requests=yes

# Мониторинг
/tool/netwatch
add host=1.1.1.1 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP1 restored\"" \
    down-script="/log error \"ISP1 down\""
add host=8.8.4.4 interval=30s timeout=1000ms type=icmp \
    up-script="/log warning \"ISP2 restored\"" \
    down-script="/log error \"ISP2 down\""
/export file=failover-config
/system/backup/save name=failover-backup encryption=aes-sha256