Tutorial
Dual-WAN Failover MikroTik для ISP
Як налаштувати надійний dual-WAN failover MikroTik для мережі ISP: рекурсивна маршрутизація, Netwatch, NAT по WAN, час перемикання та віддалена перевірка.
Стисло 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, — ось де більшість операторів втрачає гроші. Централізоване керування, закріплене на вихідному з’єднанні, закриває цей розрив.