Starlink як резервний канал — одне з найпопулярніших рішень для українського бізнесу після 2022 року. У цій статті покажу як налаштувати автоматичний failover на MikroTik: основний провайдер впав — трафік переходить на Starlink за 2-3 секунди, піднявся — повертається назад.
Що маємо на вході
- MikroTik RouterOS 7.x (hEX, RB4011, CCR — будь-який)
- ether1 — основний провайдер (наприклад, 100 Мбіт/с оптика)
- ether2 — Starlink (через роутер Starlink у режимі bypass або NAT)
- Цільова мережа: LAN 192.168.88.0/24
Крок 1 — IP-адреси на інтерфейсах
Припускаю що інтернет-адреси вже є. Нам потрібні два default route з різними distance:
/ip route
add dst-address=0.0.0.0/0 gateway=1.2.3.1 distance=1 check-gateway=ping comment="WAN-main"
add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=2 check-gateway=ping comment="WAN-starlink"
distance=1 — основний маршрут. distance=2 — резервний, активується автоматично коли основний відвалюється. check-gateway=ping — RouterOS пінгує gateway кожні 10 секунд і деактивує маршрут якщо немає відповіді.
Крок 2 — Netwatch для надійного failover
Проблема з check-gateway=ping: він пінгує gateway, але gateway може відповідати навіть коли провайдер не пускає трафік далі. Тому додаємо Netwatch — пінгуємо зовнішній IP (наприклад, 8.8.8.8) через основний інтерфейс:
/tool netwatch
add host=8.8.8.8 interval=10s timeout=2s
up-script="/ip route set [find comment="WAN-main"] distance=1"
down-script="/ip route set [find comment="WAN-main"] distance=3"
comment="Check main ISP via 8.8.8.8"
Логіка проста: якщо 8.8.8.8 не відповідає — основний маршрут отримує distance=3 (стає гірше ніж Starlink з distance=2), трафік перемикається. Коли з’являється відповідь — distance=1 повертається і трафік іде назад через основного провайдера.
Крок 3 — Правильний NAT для обох WAN
/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade comment="NAT main WAN"
add chain=srcnat out-interface=ether2 action=masquerade comment="NAT Starlink"
Обов’язково два правила masquerade — по одному на кожен WAN-інтерфейс. Якщо зробити одне загальне — при failover трафік буде виходити через Starlink але з IP основного провайдера, і з’єднання будуть розриватись.
Крок 4 — Перевірка
Відключіть кабель основного провайдера або тимчасово заблокуйте маршрут вручну:
# Симулюємо падіння основного провайдера
/ip route set [find comment="WAN-main"] distance=3
# Перевіряємо що активний маршрут — Starlink
/ip route print where active dst-address=0.0.0.0/0
# Повертаємо
/ip route set [find comment="WAN-main"] distance=1
Типові проблеми
Starlink не відповідає на ping всередині мережі
Starlink-роутер за замовчуванням блокує ICMP. Або підключіть MikroTik безпосередньо до Starlink dish у режимі bypass (потрібен адаптер), або використовуйте як check-gateway IP самого Starlink-роутера (зазвичай 192.168.100.1) а Netwatch налаштуйте на зовнішній IP через routing-table.
Трафік не перемикається за 3 секунди
Зменшіть interval та timeout у Netwatch: interval=5s timeout=1s. Але майте на увазі — занадто агресивні значення дадуть хибні спрацювання при короткочасних втратах пакетів.
DNS не оновлюється при failover
Якщо DNS-сервер прописаний від основного провайдера — при failover запити туди не доходять. Використовуйте незалежні DNS: 8.8.8.8 та 1.1.1.1, або підніміть локальний DNS-резолвер на самому MikroTik (/ip dns set allow-remote-requests=yes).
Результат
При такій схемі failover відбувається за 10-30 секунд (залежно від налаштувань Netwatch). TCP-з’єднання що вже існували — розриваються (це особливість IP failover, не баг). Нові з’єднання одразу йдуть через Starlink. Для більшості задач — браузер, Teams, пошта — це непомітно.
Якщо потрібен seamless failover без розриву сесій — це вже тема для VRRP + BGP або SD-WAN, але це окрема велика стаття.