Dual-WAN Failover MikroTik для ISP

Кратко Dual-WAN failover MikroTik удерживает объект в сети, автоматически переводя трафик на резервный аплинк, когда основной канал отказывает. RouterOS даёт три строительных блока — рекурсивную маршрутизацию с check-gateway, Netwatch и NAT по WAN — и правильное сочетание зависит от того, насколько быстрым и насколько умным должно быть ваше обнаружение. Для сетей ISP более сложная задача — не сам фрагмент конфигурации, а подтверждение на сотнях удалённых площадок за CGNAT, что переключение действительно сработало. Это руководство охватывает и то, и другое.

Что Такое Dual-WAN Failover MikroTik?

Dual-WAN failover MikroTik — это конфигурация RouterOS, которая даёт маршрутизатору два интернет-аплинка — основной и резервный — и автоматически переводит трафик на резервный, когда основной перестаёт пропускать пакеты, а затем возвращает его после восстановления. Это не то же самое, что балансировка нагрузки: failover держит один канал простаивающим как страховку, тогда как балансировка распределяет трафик между обоими. Цель — непрерывность, а не дополнительная полоса, и именно поэтому это шаблон резервирования по умолчанию для площадок, которые просто не могут остаться без связи.

Механизм опирается на выбор маршрута. RouterOS выбирает активный маршрут по умолчанию по наименьшему административному distance, поэтому основному вы задаёте меньший distance, а резервному — больший. Весь замысел тогда сводится к одному вопросу: как маршрутизатор решает, что основной «лёг», и понижает его маршрут? Сделайте это решение правильно — достаточно быстро, но без дёрганья — и failover будет надёжным. Ошибитесь — и вы либо переключитесь слишком медленно, либо будете метаться между каналами при каждом потерянном пакете.

Шаг 1 — Опишите оба WAN-канала, прежде чем трогать маршрут

Начните с того, чтобы записать, чем на самом деле является каждый аплинк. Фиксированная оптика или PPPoE-основной канал со статическим или назначенным PPP шлюзом ведёт себя иначе, чем резервный Starlink или LTE, который сидит за Carrier-Grade NAT и выдаёт вам динамический адрес. Это важно, потому что рекурсивная маршрутизация работает только со стабильными IP-шлюзами, а не с динамическими типами интерфейсов вроде PPPoE или DHCP, где адрес может меняться (Документация MikroTik — Failover (WAN Backup)). Решите, какой канал основной, какой резервный и меняет ли какой-либо из них IP при переподключении — этот единственный факт диктует, какой метод обнаружения вы можете использовать.

Шаг 2 — Добавьте рекурсивные маршруты по умолчанию с check-gateway

Классический подход использует рекурсивную маршрутизацию: вместо того чтобы направлять маршрут по умолчанию прямо на следующий хоп, вы направляете его на цель проверки (например, известный публичный резолвер) и добавляете статический маршрут, говорящий RouterOS достигать этой цели только через конкретный WAN-шлюз. Затем вы создаёте два маршрута по умолчанию, разрешаемых рекурсивно через эти цели — основной с меньшим distance и включённым check-gateway=ping, резервный с большим distance (Scoop — Basic ISP Failover with MikroTik).

Поведение, под которое нужно планировать, — это тайминг. Check-gateway деактивирует маршрут после двух подряд неудачных проверок, а проверки выполняются примерно каждые 10 секунд, поэтому реальное переключение приходится на 20–30 секунд — и оно не реагирует на перемежающуюся потерю пакетов, только на полностью мёртвый шлюз (Документация MikroTik — Failover (WAN Backup)). Для многих площадок клиентов ISP это приемлемо. Для голосовых или платёжных терминалов часто нет, и тут на сцену выходит Шаг 4.

Шаг 3 — Настройте NAT для обоих аплинков

Маршрутизатору dual-WAN нужно отдельное правило masquerade (или src-nat) на каждый WAN-интерфейс, чтобы активный канал корректно транслировал исходящий трафик; единственное правило, привязанное к одному интерфейсу, тихо разорвёт связность в тот момент, когда failover переведёт трафик на другой канал. Добавьте одно правило masquerade в цепочку srcnat для основного out-interface и второе — для резервного. Если вы публикуете какие-либо входящие сервисы, помните, что правила dst-nat, привязанные к адресу основного, перестают работать, когда этот канал — и его публичный IP — исчезает. Эта хрупкость по входящему трафику — та же архитектурная ловушка, что разобрана в нашем кейсе об изменениях IP у Starlink, и именно поэтому доступ, закреплённый на исходящем соединении, масштабируется лучше проброса портов. Об основах NAT см. наше руководство по настройке NAT на MikroTik.

Шаг 4 — Используйте Netwatch, когда нужно более быстрое или умное обнаружение

Когда 20–30 секунд слишком медленно или нужно реагировать на деградировавшие-но-живые каналы, Netwatch — более гибкий инструмент. В RouterOS v7 у Netwatch появился параметр type, который может проверять через icmp, tcp-conn, http-get, https-get или simple, и вы можете задать собственный интервал проверки вместо того, чтобы мириться с фиксированным ритмом check-gateway (Документация MikroTik — Failover (WAN Backup)). У каждого хоста есть скрипт up и down, поэтому при переходе вы можете отключить основной маршрут по умолчанию, поднять оповещение или записать событие в лог.

Многие операторы сочетают оба: рекурсивная маршрутизация справляется с чистой смертью канала, а Netwatch покрывает более грязные случаи и отправляет уведомления. Длинная ветка сообщества обсуждает именно этот компромисс, и её стоит прочитать, прежде чем стандартизировать один метод по всей сети (Форум MikroTik — netwatch instead of recursive routing). Что бы вы ни выбрали, держите конфигурацию идентичной на каждой площадке — сеть из самодельных failover-скриптов сама по себе авария, ждущая своего часа.

Шаг 5 — Проверьте переключение на каждой удалённой площадке

Вот часть, которую конфиг-туториалы пропускают. Добавить маршруты на одном настольном маршрутизаторе легко; доказать, что failover работает на сотнях развёрнутых CPE, — вот настоящая проблема ISP, и она становится сложнее, когда резервный канал — Starlink или LTE за CGNAT, потому что у устройства часто нет доступного публичного IP, чтобы управлять им после переключения. Если вы можете подтвердить failover только дождавшись звонка клиента, у вас на самом деле нет failover; у вас есть скрипт, который вы надеетесь, что отработает.

Вот где централизованное управление меняет экономику. MKController держит каждый маршрутизатор доступным через аутентифицированный исходящий туннель, поэтому вы можете подтвердить, что резервный путь несёт трафик, наблюдать переход failover в мониторинге и отправить исправленную конфигурацию — не завися от публичного IP, которого на резервном канале может не существовать. Дополните это телеметрией: наши руководства по удалённому мониторингу MikroTik с Zabbix и мониторингу SNMP для MikroTik показывают, как оповещать о самом событии failover, чтобы тихое переключение на дорогой резервный канал никогда не оставалось незамеченным.

Советы

• Держите проверку check-gateway резервного канала направленной на цель, которую вы достигаете через этот канал, а не через основной, иначе ваш тест бессмыслен.
• Помечайте переходы failover в мониторинге, чтобы площадка, неделями работающая на резервном аплинке, поднимала тикет — переключение, которого никто не замечает, — это повторяющаяся статья расходов, а не спасение.
• Тестируйте реальный кабель, а не только маршрут: выдерните коннектор основного канала и засеките реальное время переключения.

Сведите failover в единую плоскость управления

Dual-WAN failover на одном MikroTik — решённая задача. Делать это надёжно по всей сети — с единообразной конфигурацией и возможностью доказать, что резерв работает на маршрутизаторе, до которого не достучаться по публичному IP, — вот где большинство операторов теряет деньги. Централизованное управление, закреплённое на исходящем соединении, закрывает этот разрыв.

Начните бесплатный пробный период MKController