← Назад на сайт

MikroTik + Starlink: налаштування автоматичного failover

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, але це окрема велика стаття.