Два інтернет-канали в офісі: відмовостійкість VPN на MikroTik без хаосу

Що ви насправді будуєте (і чому це ламається)

Коли говорять «фейловер», зазвичай мають на увазі «якщо провайдер A помер — використовувати провайдера B». Для VPN це лише зовнішня оболонка.
Справжня система — це ланцюг залежностей: рішення маршрутизатора, поведінка NAT, досяжність пір тунелю, стан сесій і те, як швидко ви виявляєте проблему, не створюючи осциляцій.

Ворог не в нестачі можливостей. RouterOS має ручки. Ворог — це напівконфігурації, що воюють одна з одною:
дефолтні маршрути, що конкурують із політичними маршрутами, connection tracking, що прив’язує потоки до мертвого виходу, NAT, який переписує відповіді на неправильний інтерфейс,
і перевірки стану, що вимірюють не те, що треба.

Ось найважливіша ментальна модель: фейловер VPN — це не одноразова подія; це контрольована зміна шляху з збереженням детермінізму.
Детермінізм означає: для будь-якого потоку ви можете передбачити, яким WAN він піде, яку локальну IP-адресу використовує, як спрацює NAT і через який тунель вийде.
Якщо ви не можете цього передбачити, користувачі «відкриють» це через відмови.

Жарт №1: Дво-інтернет — це як купити дві парасолі і думати, що дощ сам підлаштує свій графік під ваші наради.

Три режиму відмов, які ви побачите в природі

• Асиметричне маршрутування: вихідний трафік іде через провайдера A, а відповідь повертається через провайдера B (або навпаки). VPN і stateful фаєрволи це ненавидять.
• Хибна перевірка стану: шлюз відповідає на ping, але upstream фактично мертвий; ваш «фейловер» ніколи не спрацьовує, бо ви вимірювали не той хоп.
• Шторми флапів: малі втрати пакетів змушують маршрутизатор постійно перескакувати маршрути/тунелі кожні кілька секунд. VPN «працює», але нічого не тримається стабільно.

Цитата, бо це правда в операціях

Вернер Вогельс (парафраз): «Усе ламається, весь час». Будуйте системи, що очікують цього, і ваш on-call графік буде спокійнішим.

Факти та історичний контекст (коротко, корисно, трохи сумно)

1. IPsec передував сучасним «cloud VPN» зручностям. Основні RFC датуються кінцем 1990-х, що пояснює деякі його грубі межі.
2. NAT traversal (NAT-T) став нормою через повсюдне використання NAT. Інкапсуляція ESP в UDP/4500 була практичним компромісом, а не елегантним рішенням.
3. Stateful фаєрволи змінили очікування від маршрутизації. Як тільки ви відслідковуєте з’єднання, «будь-який шлях назад» перестає бути прийнятним; трафік повернення має відповідати стану.
4. Multi-WAN став популярним у SMB ще до того, як з’явилися люди, що вміють це експлуатувати чисто. Багато малих офісів взяли двох провайдерів значно раніше, ніж з’явився персонал для безпечного політичного маршрутування.
5. BFD (Bidirectional Forwarding Detection) існує, бо маршрутизатори хотіли швидшого виявлення відмов, ніж дають таймери hello. MikroTik підтримує BFD з деякими протоколами, але більшість SMB-дизайнів його не використовують.
6. «check-gateway=ping» — не оракул досяжності. Воно повідомляє про один тільки цільовий хост, і цей хост може відповідати, навіть коли інтернет горить.
7. WireGuard молодий (2010-ті) і навмисно мінімалістичний. Ця простота полегшує розуміння фейловера порівняно зі старими стекми, але дисципліна маршрутизації все одно потрібна.
8. Carrier-grade NAT (CGNAT) тихо зламав припущення. Ваш «публічний IP» може вам не належати, і ініціація VPN ззовні може стати неможливою без допомоги.
9. Таймаути connection tracking важливіші, ніж думають люди. При фейловері застарілі записи conntrack можуть закріпити потоки за мертвим egress навіть після зміни маршрутів.

Принципи проєктування, які утримують фейловер VPN у розумних межах

1) Визначте, що означає «успіх»: лінк вгору, інтернет вгору чи VPN придатний?

Фізичний інтерфейс може бути вгору, тоді як провайдер чорнолистить маршрути. Дефолтний шлюз може відповідати, тоді як upstream DNS помер.
І VPN може показувати «established», а ваші додатки таймаутити через проблеми MTU або асиметричне маршрутування.

Ціль перевірки стану має відповідати рівню, який вам важливий:
ping шлюзу ISP виявляє L2/L3 відмови; ping публічного IP виявляє досяжність upstream;
перевірка віддаленого VPN-ендпоінту виявляє реальну життєздатність сервісу. Більшість офісів потребують принаймні перевірки upstream.

2) Віддавайте перевагу детермінованій маршрутизації над «магією»

MikroTik може багато робити автоматично, але автоматичні поведінки часто «розумні» лише в однолінійних середовищах.
Dual WAN + VPN вимагає явних виборів:

• Яка локальна IP-адреса має використовуватися для кожного тунелю?
• Який WAN має бути пріоритетним для кожного тунелю?
• Який трафік може фейловеритись, а який має залишатися прив’язаним?
• Як запобігти тому, щоб існуючі сесії чіплялися за мертвий WAN?

3) Будуйте для стабільного фейловера, а не швидкого

Так, ви хочете швидкого відновлення. Ні, вам не потрібен маршрутизатор, що міняє думку при кожному киханні пакета.
Додайте гістерезис: кілька підряд невдач перед переключенням і кілька підряд успіхів перед поверненням.

4) Розглядайте NAT як частину маршрутизації (бо це так)

При двох WAN правила NAT мають бути прив’язані до інтерфейсу і відповідати вашій політиці маршрутизації.
Якщо трафік виходить через WAN2, але NATить під адресу WAN1 — ви створили самовикликану відмову.

5) Тримайте маршрутизацію VPN відокремленою від офісного Інтернет-маршрутування

Найчистіші відмови — це локалізовані відмови. Покладіть логіку прийняття рішень для VPN у окремі таблиці маршрутизації (VRF, якщо серйозно),
або принаймні окремі таблиці з routing marks, і тримайте звичайний інтернет-трафік поза цією логікою.

Жарт №2: Якщо ви не можете пояснити своє політичне маршрутування на одній дошці, ваш маршрутизатор вже планує проти вас.

Три працездатні архітектури (виберіть одну, не змішуйте)

Архітектура A: Простий active/standby дефолтний маршрут з чистою ініціацією VPN

Це дизайн «малий офіс, але хоче менше сюрпризів». Ви тримаєте основний дефолтний маршрут через WAN1, резервний через WAN2 з вищою distance.
Піри VPN досяжні через поточний активний WAN; коли WAN1 падає, маршрутизатор перемикає дефолтний маршрут і VPN перевстановлюється через WAN2.

Переваги: простіше, менше mangle-правил, менший шанс самосуду через політичну маршрутизацію. Недоліки: існуючі сесії вмирають при фейловері. Це нормально; ви фейловерите, а не робите операцію.

Найкраще для: один-два site-to-site тунелі, IPsec з динамічними пирами або WireGuard, де повторне підключення недороге.

Архітектура B: Політична маршрутизація з прив’язаним egress тунелю + фейловер на тунель

Тут ви явно маршрутизуєте сам трафік тунелю (IKE/ESP або WireGuard UDP) через бажаний WAN, але дозволяєте резерв.
Використовуєте routing marks, щоб «трафік до пір VPN» використовував виділену таблицю з двома дефолтними маршрутами: WAN1 основний, WAN2 резерв.

Переваги: ізолює контрольний трафік VPN від офісного браузингу; уникає випадкових флапів тунелю через загальні зміни маршрутів.
Недоліки: більше правил, більше шансів наступити на ногу, вимагає дисципліни з address lists і route rules.

Архітектура C: Два тунелі (по одному на кожного провайдера) + динамічна маршрутизація або ручний пріоритет

Це підхід «роби правильно або не роби взагалі» для серйозного міжсайтового зв’язку. Ви будуєте два незалежні тунелі:
один ініційований з WAN1, інший — з WAN2. Потім запускаєте маршрутизуючий протокол (або статичні маршрути з перевірками) через тунелі.

Переваги: реальна резервність на рівні VPN, менша залежність від одного тунелю при перезатвердженні під час подій провайдера.
Недоліки: більша складність, потребує підтримки на віддаленій стороні, вимагає ретельного фільтрування маршрутів і метрик.

Якщо ви можете запускати динамічну маршрутизацію, можна також використовувати BFD для швидкого виявлення в деяких налаштуваннях. Якщо ні — тримайте все статично і стабільно.

Моя порада

Для більшості офісів: Архітектура B — золота середина. Вона відокремлює поведінку VPN, не змушуючи вас переходити до повноцінних маршрутизуючих протоколів.
Архітектура A прийнятна, коли ви готові до коротких розривів. Архітектура C — для випадків, коли «короткі розриви» призводять до скандалів на квартальних нарадах.

Практичні завдання: команди, виводи та рішення

Це реальні перевірки, які можна виконати під час побудови або дебагу. Кожне завдання містить: команду, що типовий вивід означає, і рішення, яке ви приймаєте.
Команди — в CLI RouterOS, якщо не вказано інакше. Ви можете вставляти їх у термінал MikroTik.

Завдання 1: Підтвердьте стан інтерфейсів та швидкість/дуплекс (не вважайте кабель продовженням долі)

cr0x@server:~$ /interface/ethernet/print detail where name~"ether1|ether2"
 0 name="ether1" default-name="ether1" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:01 arp=enabled
   speed=1Gbps full-duplex=yes auto-negotiation=yes link-downs=0
 1 name="ether2" default-name="ether2" mtu=1500 l2mtu=1598 mac-address=DC:2C:6E:AA:BB:02 arp=enabled
   speed=100Mbps full-duplex=yes auto-negotiation=yes link-downs=7

Значення: ether2 має link-downs і погодився на 100Mbps. Це не «добре»; це підказка.
Рішення: поміняти кабель, перевірити точку передачі провайдера або зафіксувати швидкість/дуплекс, якщо upstream-пристрій «дурний». Нестабільний WAN робить логіку фейловера схожою на поламаний годинник.

Завдання 2: Перегляньте дефолтні маршрути та чи вони активні

cr0x@server:~$ /ip/route/print where dst-address="0.0.0.0/0"
Flags: D - dynamic, A - active, c - connect, s - static
 #      DST-ADDRESS        GATEWAY            DISTANCE
 0  As  0.0.0.0/0          198.51.100.1              1
 1  s   0.0.0.0/0          203.0.113.1               5

Значення: маршрут через WAN1 активний; WAN2 в режимі standby (вища distance).
Рішення: якщо обидва активні, коли ви очікуєте один, ви отримаєте поведінку схожу на ECMP і випадкові збої сесій, якщо ви цього не планували.

Завдання 3: Перевірте поведінку «check-gateway» і чи вона вас не обманює

cr0x@server:~$ /ip/route/print detail where dst-address="0.0.0.0/0"
 0 A S  dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=1 check-gateway=ping
 1   S  dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=5 check-gateway=ping

Значення: ви пінгуєте IP шлюзу, а не інтернет.
Рішення: для реального фейловера віддавайте перевагу рекурсивним маршрутам з публічною ціллю (або скриптовим перевіркам), щоб тестувати далі першого хопу.

Завдання 4: Перевірте рекурсивні цілі маршрутизації (рекомендований підхід для перевірки досяжності upstream)

cr0x@server:~$ /ip/route/print where comment~"rec-check"
Flags: D - dynamic, A - active, c - connect, s - static
 #     DST-ADDRESS        GATEWAY         DISTANCE COMMENT
 0 As  1.1.1.1/32         198.51.100.1           1 rec-check-wan1
 1  s  0.0.0.0/0          1.1.1.1                1 default-via-wan1
 2  s  8.8.8.8/32         203.0.113.1            1 rec-check-wan2
 3  s  0.0.0.0/0          8.8.8.8                5 default-via-wan2

Значення: дефолтні маршрути рекурсивні через публічні IP. Якщо публічний IP перестає бути досяжним через той WAN, дефолтний маршрут зникає.
Рішення: використовуйте це, коли хочете фейловер на основі «доступності Інтернету», а не «шлюз відповідає на ARP».

Завдання 5: Підтвердьте, що маршрутизатор може досягти цілей перевірки через потрібний WAN

cr0x@server:~$ /ping 1.1.1.1 routing-table=main count=3
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 1.1.1.1                                     56  57 11ms
    1 1.1.1.1                                     56  57 10ms
    2 1.1.1.1                                     56  57 11ms
    sent=3 received=3 packet-loss=0% min-rtt=10ms avg-rtt=10ms max-rtt=11ms

Значення: досяжність присутня, але це все одно не доводить конкретний WAN-шлях, якщо ви його не обмежите.
Рішення: якщо вам потрібні перевірки по кожному WAN, використовуйте правила маршрутизації/таблиці і пінгуйте з routing-table=….

Завдання 6: Перевірте правила маршрутизації (policy routing) і зловіть тіньові правила

cr0x@server:~$ /routing/rule/print
Flags: X - disabled
 #   SRC-ADDRESS     DST-ADDRESS     ACTION           TABLE
 0   10.10.10.0/24                    lookup          main
 1                   203.0.113.10/32 lookup          to_wan1_vpn
 2                   203.0.113.11/32 lookup          to_wan2_vpn

Значення: ви маршрутизуєте трафік до конкретних VPN-пір через виділені таблиці.
Рішення: переконайтеся, що порядок має сенс; ширше правило раніше може вкрасти трафік у пізнішого, більш специфічного.

Завдання 7: Перевірте, чи правила NAT прив’язані до інтерфейсу (і правильно відсортовані)

cr0x@server:~$ /ip/firewall/nat/print
Flags: X - disabled, I - invalid, D - dynamic
 #   CHAIN  ACTION    SRC-ADDRESS       OUT-INTERFACE   COMMENT
 0   srcnat masquerade 10.10.10.0/24    ether1          NAT-to-WAN1
 1   srcnat masquerade 10.10.10.0/24    ether2          NAT-to-WAN2
 2   srcnat accept     10.10.10.0/24    (none)          no-NAT-to-VPN

Значення: правило «no-NAT-to-VPN» останнє, тож ніколи не буде зіставлене перед masquerade.
Рішення: перемістіть accept-правила вище за masquerade. Порядок NAT — не філософський диспут; це послідовний рушій виконання.

Завдання 8: Побачте активні IPsec SAs і підтвердьте, яку локальну адресу вони використовують

cr0x@server:~$ /ip/ipsec/active-peers/print detail
 0 address=203.0.113.200 local-address=198.51.100.10 state=established
   nat-traversal=yes ike2=yes exchange-mode=ike2

Значення: тунель встановлений і ініційований з WAN1 публічної IP.
Рішення: якщо при фейловері він все ще використовує мертвий WAN, потрібна явна обробка local-address або політика маршрутів для трафіку до пір.

Завдання 9: Перевірте IPsec-політики і чи вони не занадто широкі (непрямі витоки маршрутів)

cr0x@server:~$ /ip/ipsec/policy/print
Flags: T - template, D - dynamic, X - disabled, A - active
 #   SRC-ADDRESS      DST-ADDRESS      SA-SRC-ADDRESS    SA-DST-ADDRESS
 0 A 10.10.10.0/24    10.20.20.0/24    198.51.100.10     203.0.113.200
 1   0.0.0.0/0        0.0.0.0/0        198.51.100.10     203.0.113.200

Значення: є політика 0/0. Це «зброя самогубства», якщо ви не взяли на себе намір створити full-tunnel.
Рішення: видаліть або вимкніть широкі політики, якщо ви не зможете пояснити їх своєму майбутньому «я» о 3:00 ранку.

Завдання 10: Перевірте handshakes WireGuard-пірів і передачу по кожному лінку

cr0x@server:~$ /interface/wireguard/peers/print detail
 0 interface=wg0 public-key="..." endpoint-address=203.0.113.210 endpoint-port=51820
   allowed-address=10.20.20.0/24 persistent-keepalive=25s
   last-handshake=1m12s rx=145.2MiB tx=162.9MiB

Значення: handshakes відбуваються; трафік тече. Якщо last-handshake росте під час «фейловера», ви не перевстановлюєте з’єднання.
Рішення: перевірте маршрути до ендпоінта і правила NAT; розгляньте два пірі/endpoint’и, якщо віддалена сторона підтримує обидва ISPs.

Завдання 11: Перевірте connection tracking на предмет потоків, застряглих на неправильному WAN

cr0x@server:~$ /ip/firewall/connection/print where dst-address~"203.0.113.200" and protocol=udp
Flags: S - seen-reply, A - assured, C - confirmed, D - dying
 #   PROTO SRC-ADDRESS:PORT    DST-ADDRESS:PORT    TIMEOUT     TCP-STATE
 0 SAC udp  198.51.100.10:4500 203.0.113.200:4500 00:00:27

Значення: IPsec NAT-T потік відслідковується і прив’язаний до конкретного джерела. Під час фейловера старі записи можуть продовжувати пробувати мертвий шлях.
Рішення: після зміни маршрутів можливо потрібно очистити конкретні записи conntrack (хірургічно), щоб примусити повторну ініціацію.

Завдання 12: Скиньте лише те, що потрібно (хірургічний скидання conntrack)

cr0x@server:~$ /ip/firewall/connection/remove [find dst-address~"203.0.113.200" and protocol=udp]

Значення: видаляє відслідковані потоки до пір, щоб тунель міг перевстановитися з новим шляхом.
Рішення: уникайте очищення всіх з’єднань, якщо ви не отримали задоволення від пояснень CEO, чому всі дзвінки впали.

Завдання 13: Захопіть трафік, щоб підтвердити, який інтерфейс реально використовується

cr0x@server:~$ /tool/sniffer/quick interface=ether1 ip-address=203.0.113.200
  TIME  NUM  DIR  SRC-ADDRESS           DST-ADDRESS           PROTOCOL  SIZE
  0.01    1  tx   198.51.100.10         203.0.113.200         udp       146
  0.02    2  rx   203.0.113.200         198.51.100.10         udp       146

Значення: трафік йде через ether1. Якщо ви вважаєте, що перейшли на ether2, але бачите пакети на ether1 — маршрутизація/NAT не роблять те, що ви думаєте.
Рішення: довіряйте захопленню пакетів більше, ніж дашбордам і відчуттям.

Завдання 14: Спостерігайте зміни маршрутів наживо, симулюючи відмову

cr0x@server:~$ /log/print follow where topics~"route"
12:01:14 route,info default-via-wan1 inactive
12:01:14 route,info default-via-wan2 active
12:01:16 route,info default-via-wan1 active
12:01:17 route,info default-via-wan2 inactive

Значення: ви флапаєте. Це не «швидко»; це нестабільно.
Рішення: введіть гістерезис: подовжені інтервали перевірки, кілька невдач перед переключенням і затримане повернення на первинний шлях.

Завдання 15: Перевірте завантаження CPU під час подій фейловера (крипто VPN може бути вузьким місцем)

cr0x@server:~$ /system/resource/print
                   uptime: 3d4h22m
                  version: 7.16.1 (stable)
               cpu-load: 84
         free-memory: 214.3MiB
        total-memory: 512.0MiB

Значення: високе завантаження CPU під час перезатвердження або відбудови тунелю може затримувати збіжність і робити перевірки стану таймаутити.
Рішення: зменшити криптоване навантаження (вибір алгоритмів), зменшити кількість тунелів або оновити обладнання. «Але це всього лише офіс» — це не план пропускної здатності.

Завдання 16: Перевірте MTU/MSS clamp, якщо бачите дивні проблеми в конкретних додатках

cr0x@server:~$ /ip/firewall/mangle/print where comment~"MSS"
Flags: X - disabled, I - invalid, D - dynamic
 #   CHAIN     ACTION             PROTOCOL  TCP-FLAGS  NEW-MSS  COMMENT
 0   forward   change-mss         tcp       syn       1360     clamp-mss-for-vpn

Значення: MSS clamp налаштований. Якщо ви цього не маєте і запускаєте тунелі поверх PPPoE або з різними MTU, ви можете отримати «VPN up, додаток down».
Рішення: якщо великі завантаження зависають або певні SaaS падають лише через VPN, протестуйте PMTUD і розгляньте MSS clamp на правильному шляху.

План швидкої діагностики

Коли VPN «не фейловерить» (або фейловерить у стіну), вам потрібен повторюваний триаж-порядок.
Це оптимізовано для швидкості і сигналу, а не для елегантності.

Перш за все: визначте, чи проблема у лінку, маршрутах чи стані

1. Лінк: інтерфейс down, флапи, проблеми переговору, втрата пакетів.
2. Маршрутизація: активний неправильний маршрут, неправильна таблиця/правило, рекурсивна ціль все ще досяжна через невірний WAN.
3. Стан: conntrack прив’язує, stale IPsec/WireGuard handshake, застряглі NAT-мапінги.

Друге: вимірюйте WANи окремо, а не «інтернет» загалом

• Пінгуйте публічну ціль через routing table WAN1.
• Пінгуйте публічну ціль через routing table WAN2.
• Снифайте трафік до VPN-піра, щоб підтвердити фактичний egress інтерфейс.

Третє: перевірте контрольну площину тунелю перед плоскостю даних

Для IPsec перевірте активних peer-ів, SAs і логи на предмет помилок під час rekey. Для WireGuard — перевірте last handshake.
Якщо тунель не встановлений, налагодження маршрутів до підмереж — марна трата часу.

Четверте: підтвердіть порядок NAT і фаєрволу

Неправильний порядок NAT — класика: ви «дозволяєте no-NAT до VPN», але masquerade спрацьовує раніше.
Завжди читайте правила зверху вниз з тим же цинічним підходом, який застосовуєте до нотаток релізів вендора.

П’яте: очищуйте лише стан, який блокує збіжність

Видаляйте conntrack-записи для піра. Перезавантажуйте тунель, якщо потрібно. Уникайте перезавантаження маршрутизатора, якщо не вичерпали всі ідеї та авторитет.

Типові помилки: симптом → корінь → виправлення

1) Симптом: VPN лишається «up», але трафік вмирає після фейловера

Корінь: асиметричне маршрутування або застарілий conntrack. Контрольні пакети тунелю можуть ще працювати, але дані прив’язані до мертвого egress.

Виправлення: примусіть політичну маршрутизацію для трафіку до пір; очистіть conntrack для піра після фейловера; переконайтеся, що NAT-правила відповідають правилу out-interface.

2) Симптом: VPN перепідключається, але працюють лише деякі підмережі

Корінь: перекриття маршрутів, занадто широка політика IPsec або відсутні маршрути на віддаленому сайті після зміни шляху.

Виправлення: звужуйте селектори/політики; перевіряйте маршрути на обох кінцях; уникайте політик 0/0, якщо ви не дійсно хочете full-tunnel.

3) Симптом: фейловер ніколи не спрацьовує під час «виходу провайдера»

Корінь: ви пінгуєте шлюз провайдера, який все ще відповідає, хоча upstream мертий.

Виправлення: використовуйте рекурсивні дефолтні маршрути через публічні цілі або скриптові перевірки, що тестують далі шлюзу.

4) Симптом: фейловер постійно тригериться (флапінг)

Корінь: перевірка стану надто чутлива; ціль перевірки ненадійна; WAN має переривчасті втрати; або спайки CPU затримують відповіді.

Виправлення: додайте гістерезис (кілька відповідей/невдач), оберіть стабільні цілі, виправте фізичний лінк і стежте за CPU під час churn.

5) Симптом: після повороту назад на WAN1 VPN не відновлюється без ручного втручання

Корінь: віддалений бік все ще очікує стару source IP; NAT-мапінги застрягли; IPsec peer прикріплений до конкретної адреси; DPD таймери занадто повільні.

Виправлення: налаштуйте подвійні пири або динамічну ідентифікацію, де можливо; обережно зменшіть час виявлення DPD; під час тестування очищайте стан на обох кінцях.

6) Симптом: Інтернет працює, але переговори VPN падають лише на WAN2

Корінь: WAN2 за NAT (CGNAT) або блокує UDP/500/4500; або MTU відрізняється настільки, що ламає фрагментацію.

Виправлення: перевірте досяжність UDP-портів; віддавайте перевагу WireGuard над IPsec у ворожих NAT-середовищах; застосуйте MSS clamp; розгляньте зміну провайдера, якщо він блокує VPN.

7) Симптом: користувачі скаржаться «дзвінки Teams ламаються саме під час фейловера»

Корінь: це нормальне явище. Реальні-time потоки не переживають зміну шляху без резильєнсу на рівні сесії.

Виправлення: прийміть, що фейловер розриває живі сесії; зосередьтесь на часі відновлення і стабільності; повідомте очікувану поведінку користувачам.

8) Симптом: випадкові вихідні підключення падають, коли обидва WAN маршрути активні

Корінь: випадковий ECMP без симетричного повернення; невідповідність NAT/conntrack.

Виправлення: тримайте один дефолт активним, якщо не реалізували PCC/load balancing з відповідними NAT-правилами; не допускайте «випадкового мультишляху».

Три корпоративні міні-історії з глибоких рубок

Міні-історія 1: Аварія через неправильне припущення

Середня компанія додала другий оптичний канал після пам’ятного простою, коли хтось хотів роздати VPN через телефонний хотспот.
Директива була проста: «автоматичний фейловер». Мережевий адміністратор поставив два дефолтні маршрути з різною distance і увімкнув gateway ping checks.
Здавалося чисто. Але воно базувалося на одному неправильному припущенні: «Якщо шлюз пінгується, інтернет працює».

Через місяць у ISP A стався upstream routing issue. Шлюз залишався досяжним, ARP був ок, і пінги до шлюзу були ідеальними.
Тим часом все за межами краю провайдера іноді чорнолистилося. MikroTik відмовлявся фейловерити, бо його ціль перевірки залишалася зеленою.
Користувачі пережили повільний апокаліпсис: таймаути DNS, проблеми з логінами SaaS, VPN «up», але непридатний.

Адмін намагався «примусово» перевести трафік, відключивши маршрут вручну. Трафік перейшов на ISP B і відразу стабілізувався.
Коли знову вмикнули маршрут WAN1, маршрутизатор знову віддав перевагу йому (distance=1) і біда повернулася. Квитки до служби підтримки прийшли з протилежними симптомами.

Виправлення не було героїчним. Вони перейшли на рекурсивні дефолтні маршрути з публічними перевірками досяжності і додали гістерезис, щоб не повертатися після одного вдалого ping.
Урок виявився операційним: ваша моніторингова ціль визначає вашу реальність, навіть якщо реальність заперечує.

Міні-історія 2: Оптимізація, що відвернула фіаско

Інша компанія хотіла «нульовий простій» між провайдерами. Хтось прочитав про load balancing і вирішив бути хитрим:
увімкнули per-connection balancing по обох WAN і одночасно запустили IPsec site-to-site до датацентру.
Мета — використовувати обидва лінки і «отримати більше пропускної здатності безкоштовно».

Що вони отримали — це картка допомоги. Передачі файлів починалися швидко, а потім зависали.
Деякі веб-застосунки працювали, інші випадково падали при аутентифікації. VPN переконувався багато разів на годину.
Моніторингові графіки виглядали живими — і це найжорстокіше, що може зробити графік.

Проблема не в тому, що load balancing злий. Вони не спроєктували симетричні шляхи.
Частина трафіку до VPN-піра виходила через WAN1, відповіді поверталися через WAN2, conntrack відкидав їх, і data plane тунелю перетворився на кидання монетки.
NAT додатково погіршував ситуацію: потоки, що виходили WAN2, часом маскарадувалися як WAN1 через надто загальні або неправильно відсортовані правила.

Відкат був, по суті, визнанням: вони повернулися до одного активного дефолту, прив’язали трафік VPN до виділеної таблиці й припинили намагатися бути розумнішими за stateful мережі.
Бізнес був задоволений стабільністю, хоч і трохи повільнішою.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансова організація мала два ISP і один ключовий site-to-site VPN до хостингу бухгалтерської платформи.
У них був процес змін, що був агресивно несексуальним: будь-які мережеві зміни вимагали письмового плану відкату, вікна технічного обслуговування,
і симуляції фейловера принаймні раз на квартал. Ніхто цього не любив. Ніхто не ставив це в резюме.

Потім будівельна бригада перерізала канал. WAN1 впав різко. WAN2 залишився.
MikroTik перейшов на резерв за пару інтервалів перевірки, VPN відновився, і користувачі побачили коротке відключення, а потім нормальну роботу.
У служби підтримки було кілька дзвінків, в основному «інтернет сьогодні трохи дивний?».

Що допомогло — не якийсь витончений дизайн, а нудна дисципліна:
окремі таблиці маршрутизації для контрольного трафіку VPN, NAT-правила, прив’язані до out-interface, і відпрацьована процедура скидання conntrack для пір, якщо треба.
Вони також відправляли логи з маршрутизатора кудись, щоб довести послідовність подій, коли вендори почали звичний танець перекладання провини.

Пізніше на post-incident review хтось спитав, чому все пройшло гладко.
Відповідь мережевого адміністратора була проста: «Ми практикуємо те, що заявляємо». Це не поезія, але так продовжує працювати продукція.

Чек-листи / покроковий план

Покроково: побудова dual-WAN VPN фейловера на MikroTik (стабільно, не красиво)

1. Перевірте реалії. Підтвердьте, чи кожен ISP дає вам реальний публічний IP, чи один із них за CGNAT, і чи не блокує хтось UDP/500/4500.
   Якщо WAN2 за CGNAT — плануйте ініціацію тільки з локальної сторони або розгляньте WireGuard з keepalive.
2. Іменуйте інтерфейси і документуйте їх. «ether1» — не документація. Використовуйте коментарі, списки інтерфейсів і послідовні імена.
3. Виберіть сигнал фейловера. Віддавайте перевагу рекурсивним дефолтним маршрутам через публічні цілі або скриптовим перевіркам справжньої досяжності.
4. Тримайте логіку дефолтних маршрутів простою. Один активний дефолт, один резерв з вищою distance.
   Якщо хочете використовувати обидва лінки — це окремий проєкт з окремими режимами відмов.
5. Ізолюйте маршрутизацію до VPN-пір. Створіть таблицю маршрутизації для трафіку до пір VPN (і, за бажанням, по одній на кожен WAN) та додайте правила для IP-адрес пір.
6. Зробіть NAT детермінованим. Помістіть no-NAT/accept правила для VPN-пунктів вище за masquerade. Використовуйте match за out-interface у правилах masquerade.
7. Перевірте встановлення тунелю на кожному WAN окремо. Тимчасово вимкніть маршрут WAN1 і підтвердьте, що тунель може піднятися через WAN2, і навпаки.
8. Додайте гістерезис. Уникайте швидкого повернення. Вимагайте стійких успіхів перед поверненням на WAN1.
9. Окресліть процедуру скидання стану. Знайте, які записи conntrack очищати, як перезапустити тунель і які логи дивитися.
10. Тестуйте контрольовано. Не виривайте кабелі рандомно. Вимкніть маршрут або інтерфейс у запланований час і дивіться логи/сніфер.
11. Спостерігайте за MTU. Якщо додатки поводяться дивно через один ISP — протестуйте MSS clamp і PMTUD.
12. Запишіть усе. Конфіг не є самоврахованим документом, і ви не згадаєте намір через півроку.

Операційний чек-лист: перед застосуванням змін у проді

• Майте план out-of-band доступу (LTE консоль, віддалений руксервіс або хоча б місцева людина з ноутбуком).
• Експортуйте поточну конфігурацію і збережіть у надійному місці.
• Знайте команди для відкату і порядок їх застосування.
• Виберіть тест, який відповідає бізнесу: DNS lookup, вхід в ERP, передача файлу, VoIP дзвінок — те, що падає першим.
• Визначте прийнятний час простою на подію фейловера і повідомте зацікавлених.

FAQ

1) Чи може MikroTik зробити «безшовний» фейловер VPN без розриву сесій?

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

2) Чи варто використовувати «check-gateway=ping» на дефолтному маршруті?

Лише якщо ви приймаєте, що воно виявляє «мій шлюз відповідає», а не «інтернет працює».
Для офісів рекурсивна маршрутизація через стабільну публічну ціль зазвичай є кращим тригером фейловера.

3) Чи простіший WireGuard, ніж IPsec для фейловера?

Операційно — так. Модель handshakes WireGuard і мінімалізм роблять поведінку легшою для розуміння.
Але вам все одно потрібно вирішити питання маршрутизації та детермінізму NAT; WireGuard не врятує вас від халтурного policy routing.

4) Чому VPN показує established, але користувачі не можуть дістатися віддалених підмереж?

Бо успіх контрольної площини не гарантує успіху площини даних. Типові винуватці: неправильний порядок NAT, відсутні маршрути, асиметричний шлях або проблеми MTU.
Захоплення пакетів до піра і lookup маршруту зазвичай виявляють істину.

5) Чи потрібні мені два VPN-тунелі (по одному на кожного провайдера)?

Якщо VPN критично важливий для бізнесу і ви можете координувати обидва кінці — два тунелі найнадійніший підхід.
Для типовго офісу з терпимістю до коротких перепідключень вистачає одного тунелю, що може повторно встановлюватися через будь-який WAN.

6) А як щодо балансування навантаження по обох WAN та фейловера VPN?

Це можливо, але не наступайте на нього випадково. Потрібна консистентна класифікація по з’єднанню, відповідні NAT-правила і план для симетричного повернення.
Якщо ви не готові тестувати кілька днів — тримайте один WAN основним.

7) Як уникнути флапінгу між провайдерами?

Використовуйте гістерезис: кілька невдач перед переключенням і затримане повернення, поки стабільність не підтверджена.
Також обирайте стабільні цілі перевірки і усувайте фізичні втрати. Жодний скрипт не перехитрить поганий зріз кабелю.

8) Як безпечно тестувати фейловер під час робочого часу?

Не витягуйте кабелі. Тимчасово відключіть первинний дефолтний маршрут або понизьте його пріоритет і спостерігайте логи і стан тунелю.
Обмежте час тесту, повідомте про коротке переривання і майте план відкату.

9) Чому WAN2 не працює хоча загальний інтернет серфінг працює?

VPN-протоколи вибагливіші за веб-трафік. WAN2 може бути за CGNAT або блокувати UDP/500/4500, або мати менший MTU, що ламає інкапсуляцію.
Перевірте досяжність протоколів і розгляньте WireGuard, якщо ISP булить IPsec.

Наступні кроки (нудні речі, що запобігають тікетам)

Побудуйте найпростішу архітектуру, що відповідає бізнес-вимогам, а потім зробіть її детермінованою:
явна маршрутизація для пір VPN, NAT-правила, що відповідають обраному egress, й перевірки стану, що вимірюють правильний рівень.
Тримайте фейловер стабільним, не нервовим. Якщо хочете швидшої збіжності — інвестуйте в кращу детекцію, а не в більше випадковості.

Практичні кроки, які ви можете зробити цього тижня:

• Замініть пінги шлюзу на рекурсивні перевірки до публічних цілей.
• Ізолюйте маршрутизацію пір VPN в окрему таблицю і перевірте це через packet capture.
• Аудитуйте порядок NAT-правил і додайте виключення no-NAT для VPN-підмереж зверху.
• Проведіть контрольований тест фейловера та зафіксуйте: час виявлення, час повторного встановлення тунелю і ту одну дивну апку, що скаржиться першою.
• Напишіть односторінковий ранубук: що перевіряти, що очищати і як відкотитись. Майбутнє «ви» скаже дякую у вигляді менше алертів.