Failover між провайдером і Starlink на MikroTik: практичний гайд з налаштування відмовостійкості

О третій ночі під час планового деплою магістральний провайдер ліг через обрив оптики. Наш резервний Starlink, що працював у bypass-режимі, мав підхопити трафік автоматично. Проте замість безшовного перемикання ми отримали шквал сповіщень у Slack: з’єднання постійно відвалювалося, сесії рвалися кожні дві хвилини, а затримки стрибали до 800 мс через сильну зливу. Стандартний check-gateway=ping просто збожеволів, вважаючи лінк то живим, то мертвим. Цей інцидент змусив нас повністю переписати логіку failover. Нижче — вистраждана на практиці конфігурація без теорії з підручників.

Чому стандартний Dual-WAN тут не працює

Звичайний failover розрахований на стабільні наземні канали. Зі Starlink усе інакше:

• Мікролінки та хмари: Короткочасні втрати пакетів (до 2-3 секунд) при переході між супутниками або під час негоди — це норма для супутникового зв’язку. Стандартний пінг занадто чутливий до таких коливань.
• Оманливий лінк: Якщо впав сам супутниковий зв’язок, ethernet-порт терміналу Starlink залишається активним, а локальний шлюз терміналу (зазвичай 192.168.100.1) продовжує відповідати на ping. Роутер думає, що все добре, і продовжує зливати трафік у “чорну діру”.
• Динамічна адресація: Starlink у bypass-режимі видає IP по DHCP. Шлюз може змінитися, що ламає статичні маршрути, якщо ви прописали їх вручну.

Крок 1. Підготовка інтерфейсів та отримання динамічного шлюзу

Оскільки Starlink видає IP по DHCP, нам потрібен скрипт, який буде динамічно оновлювати шлюз для наших рекурсивних маршрутів. Без цього перша ж зміна оренди DHCP покладе всю схему.

Налаштовуємо DHCP-клієнт на інтерфейсі Starlink (нехай це буде ether2-starlink):

/ip dhcp-client
add interface=ether2-starlink use-peer-dns=no use-peer-ntp=no add-default-route=no script="
:local gw \$/\"gateway-address\"
:if (\$bound = 1) do={
    /ip route set [find comment=\"Starlink-Check\"] gateway=\$gw
}"

Важливо: Ми вимкнули add-default-route, щоб DHCP-клієнт не створював сміттєвих маршрутів з низькою метрикою, які ламатимуть пріоритети.

Крок 2. Рекурсивна маршрутизація (Recursive Routing)

Щоб перевіряти не локальний шлюз Starlink, а реальний інтернет, ми будемо пінгувати публічні DNS-сервери через конкретних провайдерів. Для основного провайдера (ISP1) візьмемо 8.8.8.8, для Starlink (ISP2) — 1.1.1.1.

Припускаємо, що статичний шлюз першого провайдера — 198.51.100.1.

/ip route
# Створюємо маршрути до хостів перевірки (Target IPs)
add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 target-scope=10 comment="ISP1-Check"
add dst-address=1.1.1.1/32 gateway=192.168.100.1 scope=10 target-scope=10 comment="Starlink-Check"

# Створюємо дефолтні маршрути, які дивляться на хости перевірки
add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping comment="Primary-Route"
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=2 check-gateway=ping comment="Backup-Route"

Як це працює: роутер пінгує 8.8.8.8 через шлюз ISP1. Якщо пінг проходить, дефолтний маршрут з distance=1 активний. Якщо 8.8.8.8 перестає відповідати, маршрут вимикається, і весь трафік переходить на Starlink (distance=2), який перевіряє доступність інтернету через 1.1.1.1.

Крок 3. Тюнінг чутливості та боротьба з флапінгом

Стандартний механізм check-gateway=ping надсилає запити кожні 10 секунд. Якщо два пінги поспіль втрачено, лінк вважається мертвим. Для Starlink під час дощу це вирокує постійне перемикання туди-сюди (флапінг), що вбиває активні SSH-сесії та VPN.

Рішення — використання вбудованого інструменту Netwatch у RouterOS v7, який дозволяє гнучко налаштувати інтервали та кількість втрачених пакетів перед прийняттям рішення.

/tool netwatch
add host=8.8.8.8 interval=5s timeout=1s type=simple \
    down-script="/ip route disable [find comment=\"Primary-Route\"]" \
    up-script="/ip route enable [find comment=\"Primary-Route\"]"
    
add host=1.1.1.1 interval=5s timeout=1.5s type=simple \
    down-script="/ip route disable [find comment=\"Backup-Route\"]" \
    up-script="/ip route enable [find comment=\"Backup-Route\"]"

Для Starlink ми свідомо збільшили timeout до 1.5 секунди. Супутниковий лінк може давати затримки на стику супутників, і ми не хочемо ганяти трафік туди-сюди через поодинокі лаги.

Крок 4. Очищення завислих з’єднань (Connection Tracking)

Найбільший біль при перемиканні на резервний канал — це “завислі” TCP-сесії. Користувачі бачать, що інтернет ніби є, але сторінки не вантажаться, поки вони не оновлять їх вручну. Це відбувається тому, що старі з’єднання залишаються в таблиці Connection Tracking роутера.

Додамо примусове очищення з’єднань при падінні основного каналу через той самий Netwatch. Модифікуємо скрипт для хоста 8.8.8.8:

# Додаємо очищення з'єднань у down-script для ISP1
/tool netwatch set [find host=8.8.8.8] down-script="
/ip route disable [find comment=\"Primary-Route\"]
/ip firewall connection remove [find]
:log warning \"Primary ISP down. Connection tracking cleared.\""

Так, це радикально — обірвати всі поточні з’єднання. Але це краще, ніж змушувати клієнтів чекати 10-15 хвилин, поки закриються старі сесії за таймаутом.

Нотатки з полів: реальний досвід експлуатації

• Живлення терміналу: Starlink дуже чутливий до просідання напруги. Якщо ваш офісний чи серверний UPS не видає чисту синусоїду, блок живлення Starlink може йти у циклічне перезавантаження. Симптом — інтерфейс на MikroTik падає у no link кожні 5 хвилин.
• CGNAT: Starlink не видає білих IPv4 адрес (ви за замовчуванням за CGNAT у мережі 100.64.0.0/10). Якщо у вас на MikroTik піднятий IPSec або WireGuard до офісу — ініціатором з’єднання має бути саме сторона зі Starlink, або використовуйте IPv6, який Starlink роздає цілком адекватно.
• Обігрів та танення снігу: Взимку функція підігріву тарілки споживає до 150-200 Вт. Враховуйте це при розрахунку ємності акумуляторів вашого інвертора чи UPS.