Резервування офісного VPN: тримайте тунелі в роботі з 2 провайдерами (без ручного керування)

December 30, 2025 • February 3, 2026 • Читання: 6 хв • Views: 13

Було корисно?

Офіс втрачає інтернет. Хтось кричить «VPN не працює», у Slack паніка, і раптом ви дебагуєте з телефону на парковці з одним стовпчиком LTE. Тим часом другий провайдер, за якого ви платите щомісяця, лежить як запасне колесо, яке ніколи не накачували.

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

Що має означати «резервування при відмові» (і чого воно не має означати)

В офісному середовищі «резервування VPN» зазвичай означає «тунель має залишатися в роботі, коли провайдер падає». Це бажаний результат. Але ви отримаєте його лише якщо визначите, що означає «в роботі» і що ви готові приймати під час відмови.

Визначте успіх в операційних термінах

Recovery time objective (RTO): Скільки секунд втрати пакетів прийнятно? 2 секунди? 30 секунд? «Поки Боб помітить» — це не метрика.
Recovery point objective (RPO): Для VPN це менше про дані, більше про стан. Станові потоки (VoIP, RDP, довгі завантаження) порвуться при зміні шляху, якщо ви не зберігаєте сесію (рідко). Вирішіть, чи допустиме розривання сесій.
Blast radius: Чи впливатиме відмова лише на трафік сайт‑to‑site, чи також на вихід в інтернет, DNS, SaaS, голосову телефонію?
Дія оператора: «Автоматично» означає — без CLI опівночі. Може при цьому голосно сповіщати. Просто не повинно вимагати вашого втручання.

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

Жарт №1: Dual WAN без перевірок стану — як мати дві парасольки й все одно промокати, бо відкриваєш їх лише коли прогноз каже «дощ».

Кілька фактів і історія, що пояснюють сучасні режими відмов

Трохи контексту робить сучасне резервування VPN менш таємничим і більше «а, от чому це ламається». Ось конкретні факти, які варто тримати в голові:

IPsec з’явився ще до сьогоднішніх «завжди онлайн» офісів. Перші стандарти IPsec з’явилися наприкінці 1990‑х, коли припускали статичні сайти та довгоживучі лінії; швидке перемикання не було головною метою дизайну.
NAT не був першокласним громадянином. NAT‑traversal (NAT‑T) став загальним пізніше; чимало дивних поведінок походять від упакування ESP в UDP/4500, щоб пройти через NAT‑пристрої.
Поведінка IKEv1 і IKEv2 різниться при відмовах. Багато «працює, поки не впаде» конфігів покладаються на особливості IKEv1; IKEv2 загалом поводиться краще, але все одно залежить від таймерів і налаштувань DPD.
Відмови у споживчих ISP часто часткові. Багато outage‑ів — не фізичне відключення лінка. Це збій DNS, зламаний PMTU або флап маршрутизації вгорі. Ось чому виявлення «мертвого шлюзу» пінгом до next‑hop провайдера — пастка.
BGP став «дорослим» способом мульті‑хоумінгу для підприємств. Але більшість офісів не можуть отримати provider‑independent адресацію чи BGP від дешевих ліній; тому ми імітуємо відмовостійкість на вищих шарах.
SD‑WAN не придумав перевірки стану; він їх продуктизував. Основна ідея — вимірювати втрати/латентність до реальної цілі й керувати трафіком — існувала десятиліттями у самодельних скриптах та функціях маршрутизаторів.
Втрата пакетів шкодить VPN більше, ніж звичайному веб‑серфінгу. Інкапсуляційний оверхед IPsec плюс повторні передачі можуть перетворити «1% втрат» на «чому Teams не працює?» швидше, ніж хочете.
PMTU‑чорні діри — старий, повторюваний режим відмови. Оверхед тунелю зменшує ефективний MTU; якщо ICMP блокується, Path MTU Discovery ламається і великі пакети зникають у безодні.

Топології, які працюють: active/standby, active/active і «так не робіть»

Топологія A: Active/standby тунелі (найпростіше, часто найкраще)

Ви будуєте два site‑to‑site VPN‑тунелі: один через ISP1, інший через ISP2. Лише один несе трафік за нормальних умов. Якщо перевірки стану падають, ви переводите маршрут на стенд‑бай тунель. Це можна реалізувати за допомогою:

Маршрутоорієнтований VPN (рекомендовано): два тунельні інтерфейси, два next‑hop, метрики/пріоритети.
Політико‑орієнтований VPN (працює, але стає крихким при рості мережі).
Динамічна маршрутизація (BGP/OSPF) поверх тунелів (чисте перемикання, більше рухомих частин).

Чому це працює: стабільно, передбачувано, менше несподіваних асиметрій маршрутизації. Дебаг на 3‑ї ранку стає терпимим.

Компроміс: ви «марнуєте» резервний лінк. І це нормально. Ваш фінансовий директор марнує більше грошей на крісла у залах засідань.

Топологія B: Active/active тунелі (складніше, застосовуйте тільки за потреби)

Обидва тунелі несуть трафік одночасно. Ви робите маршрутизацію по префіксу, керування по застосунках або ECMP. Це розповсюджено, коли хочете більше пропускної здатності або щоб один провайдер не був «мертвим вантажем».

Де це ламається:

Асиметрична маршрутизація, якщо відповідь не повертається тим самим тунелем.
Станові фаєрволи, що прив’язують потоки до шляху й відхиляють пакети, які приходять на «неправильний» інтерфейс.
Обмеження на віддаленій стороні (деякі VPN‑шлюзи в хмарі не люблять часті зміни шляху).

Моя порада: використовуйте active/standby, якщо у вас немає виміряної потреби в пропускній здатності, яка виправдовує складність. Якщо потребуєте active/active — чесно признайте: ви будуєте невеликий WAN. Трактуйте його відповідно.

Топологія C: «Failover через DNS» (не робіть)

Дехто пробує: «Якщо ISP1 впаде, поміняємо DNS для кінцевої точки VPN». Це не резервування; це план технічного обслуговування, замаскований під стійкість. Кеші DNS, TTL, і довгоживучі сесії зроблять так, що ваші користувачі будуть тими, хто реалізує ваш тест вирізання в продакшні.

Механіка: поведінка IKE/IPsec, NAT, DPD та реальність рекі

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

DPD: Dead Peer Detection — необхідно, але недостатньо

DPD (або еквівалентні keepalive) може сказати, що пір не відповідає. Але якщо інтернет‑шлях напівзламаний — пакети виходять, а відповіді не повертаються — вам потрібен додатковий доказ.

Хороша практика:

Увімкніть DPD з розумними значеннями (наприклад 10–30 с інтервали, невелика кількість повторів).
Використовуйте також probes на рівні data‑plane (ICMP або TCP до цілі через тунель).
Приймайте рішення про перемикання на підставі стійких втрат/латентності, а не одного пропущеного запиту.

NAT і вихідні адреси: обирайте стабільні ідентичності

У конфігурації з двома провайдерами локальний VPN‑шлюз може показувати різні публічні IP. Віддалена сторона може аутентифікувати за ідентифікатором (FQDN) і не звертати уваги на зміну вихідного IP, або ж фіксувати конкретну адресу. Багато сервісів у хмарі очікують, що ви явно налаштуєте обидва тунелі; це добре. Ви хочете, щоб віддалий бік був готовий до відмови.

Рекі поведінка під час перемикання

Рекі‑події — класична «кожну годину ламається» таємниця. Під час перемикання таймери рекі можуть зійтися з нестабільністю шляху, що призведе до повторних спроб переговорів. По можливості:

Рознесіть терміни життя SA між первинним і вторинним тунелями.
Переконайтеся, що обидва тунелі можуть обговорюватися незалежно (без плутанини між SA).
Зберігайте логи. Помилки при рекі рідко вирішуються «на око».

MTU: мовчазний вбивця тунелів

Інкапсуляція зменшує MTU. Якщо у вас LAN MTU 1500 і ви інкапсулюєте в IPsec поверх PPPoE (поширено на DSL), можливо треба зажати TCP MSS або зменшити MTU інтерфейсу. Інакше ви отримаєте періодичні збої, які виглядають як «деякі сайти завантажуються, деякі — ні».

Жарт №2: Проблеми з MTU — це ІТ‑еквівалент скрипучого крісла: нешкідливо, поки не доведе всіх до божевілля й ви не почнете сумніватися у своїх життєвих рішеннях.

Маршрутизація, яка не бреше: політика проти маршруто-орієнтованої проти BGP

Маршруто-орієнтований VPN: стандартна рекомендація

Маршруто‑орієнтований VPN дає вам тунельний інтерфейс. Ви можете використовувати статичні маршрути, метрики і звичну таблицю маршрутизації. Його легше поєднувати з перевірками стану та динамічною маршрутизацією.

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

Політико‑орієнтований VPN: прийнятний для крихітних мереж

Політико‑орієнтований VPN пов’язує шифрування з traffic selectors (підмережа→підмережа). Він працює до тих пір, поки ви не додасте третю підмережу, потім четверту, потім хтось не захоче /32 для тестової VM, і раптом ви ведете політику в таблицях Excel.

Динамічна маршрутизація по тунелях: чисте перенаправлення, вищий рівень складності

BGP поверх IPsec (або GRE поверх IPsec) — найнадійніший спосіб переключення маршрутів між тунелями, бо протоколи маршрутизації вже розв’язують «який шлях життєздатний», якщо їм подавати правильні інтерфейсні та keepalive‑сигнали.

Коли використовувати:

У вас кілька сайтів або кілька префіксів.
Потрібне автоматичне перенаправлення без специфічних SD‑WAN можливостей.
Ви вмієте ним оперувати: моніторинг, фільтр маршрутів і контроль змін.

Коли не варто:

Ви — один офіс з одним віддаленим мережевим сегментом і без бажання займатися політикою маршрутизації.
Ви не можете гарантувати, що обидві сторони зможуть чисто запустити BGP (деякі керовані сервіси це обмежують).

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

Перевірки стану: доведіть, що шлях корисний, а не просто «в мережі»

Ключова проблема офісного резервування в тому, що більшість «dual WAN» налаштувань виявляють не ту відмову. Кабельний модем досі синхронізований, тому маршрутизатор думає, що все добре. Тим часом upstream‑маршрутизація чорнить трафік до VPN‑піра.

Що перевіряти

Underlay досяжність: Чи можете ви дістатися стабільної інтернет‑цілі через кожного провайдера? Використовуйте кілька цілей у різних мережах. Уникайте «пінгу шлюзу провайдера» як єдиного тесту.
Overlay досяжність: Чи можете ви дістатися чогось через тунель? Loopback‑IP на віддаленому фаєрволі ідеальний. Ще краще — сервісний порт (TCP/443 до health‑endpoint), який доводить більше, ніж ICMP.
Якість: Вимірюйте латентність і втрати пакетів. Визначте пороги, що відповідають вашим застосункам (голос, VDI, файлові ресурси).

Як зробити перевірки достовірними

Прив’язуйте перевірки до інтерфейсу/джерела для кожного провайдера, щоб перевіряти правильний шлях.
Використовуйте кілька перевірок і вимагайте послідовних відмов перед оголошенням «мертвий».
Обмежте частоту повернення (failback). Флапання між провайдерами — як раз шлях перетворити дрібну upstream‑проблему на повний outage.

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

Це практичні завдання, які можна виконати на Linux‑шлюзі VPN (або на хості для налагодження), щоб перевірити дизайн dual‑ISP VPN. Команди реалістичні. Виводи репрезентативні. Після кожного — що означає вивід і яке рішення прийняти.

Завдання 1: Підтвердити, що обидва WAN мають валідні маршрути

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan1 proto static metric 100
default via 198.51.100.1 dev wan2 proto static metric 200
10.10.0.0/16 dev lan0 proto kernel scope link src 10.10.0.1
203.0.113.0/24 dev wan1 proto kernel scope link src 203.0.113.20
198.51.100.0/24 dev wan2 proto kernel scope link src 198.51.100.20

Значення: Є два дефолтні маршрути; wan1 пріоритетніший через меншу метрику. Маршрут LAN присутній.

Рішення: Якщо ви хочете active/standby underlay — це правильно. Якщо планували active/active, потрібна політика маршрутизації або ECMP, а не просто два дефолти з метриками.

Завдання 2: Перевірити правила політико‑маршрутизації (якщо робите dual underlay probing або active/active)

cr0x@server:~$ ip rule show
0:	from all lookup local
1000:	from 203.0.113.20 lookup 100
1001:	from 198.51.100.20 lookup 200
32766:	from all lookup main
32767:	from all lookup default

Значення: Трафік, що походить із кожної WAN‑IP, використовує конкретну таблицю маршрутизації.

Рішення: Тримайте це, якщо потрібно прив’язувати перевірки (і частину тунельного трафіку) до правильного провайдера. Якщо відсутнє — ваш «wan2 probe» може тихо вийти через wan1 і збрехати вам.

Завдання 3: Підтвердити, що кожен WAN може дістатися публічної IP віддаленого VPN‑піра (прив’язка до інтерфейсу)

cr0x@server:~$ ping -I wan1 -c 3 192.0.2.10
PING 192.0.2.10 (192.0.2.10) from 203.0.113.20 wan1: 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=55 time=18.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=55 time=18.1 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=55 time=18.3 ms

--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 18.1/18.2/18.4/0.1 ms

Значення: Underlay до піра досяжний через wan1 з низькими втратами.

Рішення: Повторіть для wan2. Якщо wan2 не може дістатися піра — не звинувачуйте IPsec; спочатку виправте маршрутизацію, фільтрацію ISP або upstream‑проблеми.

Завдання 4: Перевірити, чи IKE слухає на обох WAN

cr0x@server:~$ sudo ss -lunp | grep -E ':(500|4500)\s'
UNCONN 0      0        0.0.0.0:500     0.0.0.0:*    users:(("charon",pid=1324,fd=12))
UNCONN 0      0        0.0.0.0:4500    0.0.0.0:*    users:(("charon",pid=1324,fd=13))

Значення: Демон IKE (приклад: strongSwan charon) слухає UDP/500 і UDP/4500 на всіх інтерфейсах.

Рішення: Якщо він прив’язаний лише до однієї IP, вторинний failover ніколи не спрацює. Виправте налаштування демона або системний фаєрвол.

Завдання 5: Перевірити стан IPsec‑тунелю (приклад strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-primary: #12, ESTABLISHED, IKEv2, rekeying in 46 minutes
  local  'office-fw' @ 203.0.113.20[4500]
  remote 'dc-fw' @ 192.0.2.10[4500]
  AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  vpn-primary-child: #34, INSTALLED, TUNNEL, reqid 1
    local  10.10.0.0/16
    remote 10.50.0.0/16
vpn-secondary: #0, CONNECTING, IKEv2
  local  'office-fw' @ 198.51.100.20[4500]
  remote 'dc-fw' @ 192.0.2.10[4500]

Значення: Перший тунель встановлений; вторинний намагається, але не піднятий.

Рішення: Якщо вторинний ніколи не встановлюється — перевірте, чи віддалений пір налаштований приймати другий тунель і чи NAT/фаєрвол не блокує його.

Завдання 6: Підтвердити, що маршрути до віддалених підмереж віддають перевагу первинному тунелю

cr0x@server:~$ ip route get 10.50.1.25
10.50.1.25 dev vti0 src 10.255.0.2 uid 0
    cache

Значення: Трафік до віддаленої мережі йде через vti0 (первинний тунель).

Рішення: Якщо він виходить напряму через wan1, ваш маршрутоорієнтований VPN фактично не працює. Виправте маршрути, VTI або traffic selectors.

Завдання 7: Довести overlay‑досяжність (пропробуйте remote loopback через тунель)

cr0x@server:~$ ping -c 3 10.50.255.1
PING 10.50.255.1 (10.50.255.1) 56(84) bytes of data.
64 bytes from 10.50.255.1: icmp_seq=1 ttl=63 time=21.9 ms
64 bytes from 10.50.255.1: icmp_seq=2 ttl=63 time=22.1 ms
64 bytes from 10.50.255.1: icmp_seq=3 ttl=63 time=22.0 ms

--- 10.50.255.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 21.9/22.0/22.1/0.1 ms

Значення: Data‑plane працює через тунель.

Рішення: Якщо underlay працює, але overlay не працює — зосередьтеся на IPsec selectors, політиках фаєрволу або маршрутизації на віддаленій стороні.

Завдання 8: Перевірити проблеми MTU/фрагментації за допомогою DF‑ping

cr0x@server:~$ ping -c 3 -M do -s 1472 10.50.255.1
PING 10.50.255.1 (10.50.255.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436

--- 10.50.255.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2051ms

Значення: Ефективний MTU вздовж тунелю — 1436. Ваш 1500‑байт пакет не проходить з DF.

Рішення: Защеміть TCP MSS (наприклад до 1360–1400 залежно від оверхеду) або встановіть MTU тунелю/LAN відповідно. Якщо ICMP блокується upstream, ви побачите чорні діри замість чистих помилок.

Завдання 9: Перевірити xfrm‑стан, щоб підтвердити встановлені SA (Linux IPsec)

cr0x@server:~$ sudo ip xfrm state
src 203.0.113.20 dst 192.0.2.10
	proto esp spi 0xc12f4a9d reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x4f9b... 128
src 192.0.2.10 dst 203.0.113.20
	proto esp spi 0x1a2b3c4d reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x0aa1... 128

Значення: ESP SA існують в обох напрямках для первинного тунелю.

Рішення: Якщо SA відсутні, тоді як IKE каже «established», можлива проблема з CHILD_SA переговором або конфлікт політик.

Завдання 10: Перевірити NAT‑Traversal і UDP‑інкапсуляцію на лінії

cr0x@server:~$ sudo tcpdump -ni wan1 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wan1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:04:11.120111 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f1), length 132
12:04:11.140225 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19a), length 132
12:04:12.120332 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f2), length 132
12:04:12.140447 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19b), length 132
12:04:13.120552 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f3), length 132
5 packets captured

Значення: ESP інкапсульовано в UDP/4500 і трафік йде в обох напрямках.

Рішення: Якщо ви бачите лише вихідні пакети — підозрюйте upstream‑фільтрацію, неправильний NAT або віддалена сторона не відповідає. Якщо бачите лише IKE/500 і немає 4500 за NAT — NAT‑T може бути неправильно погоджений.

Завдання 11: Підтвердити, що фаєрвол дозволяє IKE/IPsec на обох WAN

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iifname "wan1" udp dport { 500, 4500 } accept
    iifname "wan2" udp dport { 500, 4500 } accept
    iifname "lan0" accept
    counter reject with icmpx type admin-prohibited
  }
}

Значення: UDP/500 і UDP/4500 дозволені на обох WAN‑інтерфейсах.

Рішення: Якщо wan2 відсутній, вторинні переговори тунелю тихо впадуть. Виправте фаєрвол перед тим, як чіпати IPsec‑конфіги.

Завдання 12: Слідкувати за змінами маршрутів під час індукованої відмови

cr0x@server:~$ ip monitor route
Deleted default via 203.0.113.1 dev wan1 proto static metric 100
Added default via 198.51.100.1 dev wan2 proto static metric 200
Added 10.50.0.0/16 dev vti1 proto static metric 50
Deleted 10.50.0.0/16 dev vti0 proto static metric 10

Значення: Первинний дефолт і маршрут первинного тунелю були видалені; вторинний став активним і маршрут переключився на vti1.

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

Завдання 13: Підтвердити рівень додатка через VPN (TCP‑тест)

cr0x@server:~$ nc -vz -w 2 10.50.20.10 443
Connection to 10.50.20.10 443 port [tcp/https] succeeded!

Значення: Overlay може дістатися реального сервісу. Успіх лише по ICMP може приховувати фаєрвол чи MTU‑проблеми.

Рішення: Використовуйте це як ціль перевірки, коли важлива доступність застосунку. Якщо це падає під час failover, але ping працює — підозрюйте MSS/MTU, stateful‑інспекцію або асиметричну маршрутизацію.

Завдання 14: Перевірити симптоми асиметричної маршрутизації за допомогою conntrack

cr0x@server:~$ sudo conntrack -S
cpu=0 found=24872 invalid=36 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0

Значення: Маєте ненульові invalid пакети, що часто зростає при асиметричній маршрутизації або зміні шляху.

Рішення: Якщо invalid зростає під час failover — розгляньте active/standby замість active/active, або забезпечте симетрію маршрутизації політиками та послідовним NAT/обробленням стану.

Швидкий план діагностики

Коли VPN «перемикається», але користувачі все ще скаржаться, треба ізолювати, де саме знаходиться проблема: underlay (ISP), overlay (IPsec), маршрутизація (ваш пристрій) або віддалена сторона. Робіть це по порядку.

Перший крок: перевірка underlay (доведіть, що шлях провайдера придатний)

Перевірте лінк і IP‑адресацію на обох WAN (carrier up, DHCP/PPPoE, маршрути).
Пропробуйте кілька стабільних інтернет‑цілей для кожного WAN (пінг або TCP з прив’язкою до інтерфейсу). Якщо лише один провайдер деградує — не чіпайте VPN поки не впевнені.
Підтвердіть, що можете дістатися публічної IP віддаленого VPN‑піра з кожного WAN.

Другий: контрольний шар overlay (чи IKE веде переговори?)

Підтвердьте, що UDP/500 і UDP/4500 дозволені в обох напрямках.
Перегляньте логи IKE на предмет циклів переговорів, помилок аутентифікації або невідповідностей пропозицій.
Переконайтеся, що вторинний тунель налаштований на віддаленому пірі і він не блокує «лише відомий вихідний IP».

Третій: data‑plane overlay (чи пакети проходять?)

Пропінгуйте віддалений loopback або тестовий хост через тунель.
Зробіть TCP‑connect тест до реального сервісу через тунель.
Перевірте PMTU DF‑pingами і зажміть MSS при потребі.

Четвертий: маршрутизація і симетрія (куди насправді пішов трафік?)

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

П’ятий: віддалена сторона та залежності додатків

Підтвердіть, що віддалий фаєрвол має маршрути назад до офісних мереж через активний тунель.
Перевірте DNS, identity‑провайдери і будь‑які «допоміжні» проксі, що могли зафіксувати старий шлях.

Три корпоративні міні‑історії з реальної практики

Міні‑історія 1: Інцидент через неправильне припущення

В офісі були два провайдера. Слайд у презентації гордо казав «резервне з’єднання». Насправді: ISP2 був підключений і мав IP, але ніхто ніколи не тестував site‑to‑site VPN через нього, бо «фаєрвол це підтримує». Ця фраза мала б мати попереджувальний ярлик.

Одного вівторка ISP1 не впав цілком; він почав потроху дивитись. Вихідний трафік працював для деяких напрямків. Мережа VPN‑піра? Чорнилася upstream. Функція фаєрволу «виявлення мертвого шлюзу» продовжувала оголошувати лінк здоровим, бо він відповідав пінгом до next‑hop провайдера. Користувачі могли серфити, що зробило керівництво впевненим, що «проблема — команда VPN».

Команда вручну перевела трафік на ISP2. Тунель так і не піднявся. Віддалений пір дозволяв лише відомий публічний IP ISP1, а сертифікатна ідентичність була прив’язана до цього припущення. Вони побудували резервування на папері, але операційно це була єдина точка відмови з підпискою.

Вони виправили по‑справжньому: налаштували обидва тунелі на віддаленій стороні, використали стабільну IKE‑ідентичність, не прив’язану до однієї вихідної IP, і впровадили overlay‑проби до loopback віддаленого фаєрволу. Через два тижні вони симулювали відмову під час робочого дня і спостерігали, як тунелі поводились як дорослі.

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

Інша компанія захотіла «користуватися обома лініями, бо фінанси». Вони ввімкнули active/active з ECMP по двох IPsec VTI і потішалися, коли iperf у лабораторії показував більшу пропускну здатність.

У продакшні helpdesk почав отримувати тикети, що звучали ніби між іншим: переривання доступу до файлових шарів, однобічний звук у VoIP і «ERP крутиться нескінченно». Нічого повністю не падало. Все було трошки «привидно».

Причина — асиметрична маршрутизація в поєднанні зі stateful політиками на віддаленій стороні. Деякі потоки виходили через тунель A і поверталися через тунель B. Фаєрвол вважав їх недійсними і відкидав. Навіть коли пакети не відкидалися, спостерігалася перевпорядкування і сплески джиттера через різницю шляхів.

Виправлення було неспокусливе: повернення до active/standby для більшості трафіку, залишаючи active/active лише для кількох безстанових bulk‑потоків, і забезпечення симетрії політичною маршрутизацією там, де потрібно. Графіки пропускної здатності стали менш вражаючими. Користувачі перестали дзвонити. Оце і є KPI, що має значення.

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

Середній офіс мав dual ISP з двома IPsec тунелями до дата‑центру. Нічого складного: маршруто‑орієнтований VPN, primary/secondary, перевірки стану що пінгують віддалений loopback й TCP‑порт, плюс 60‑секундний hold‑down перед поверненням.

Вони також робили те, що ніхто не любить: щоквартальні навчання з відпрацюванням перемикання в вікні технічного обслуговування. Вони не просто відключали кабелі; симулювали часткові збої — інжекцію втрат, DNS‑збої, upstream‑маршрутні чорні діри — бо саме так реальні провайдери вас тестують, коли у вас є плани на вихідні.

Коли будівельна бригада відімкнула оптику (передбачувано, вічно), офіс втратив кілька секунд трафіку і продовжив роботу. Тунель переключився, маршрути оновилися, і система моніторингу сповістила чистим повідомленням «failover succeeded». Нікому не довелося SSH‑ти з телефону.

Післяінцидентний огляд був коротким: підтвердити таймінги, що тренування відображало реальність, відправити тікет провайдеру, повернутися до роботи. Нудне — це особливість.

Поширені помилки: симптом → корінна причина → виправлення

Це секція, яку читаєте, коли вже запізнюєтесь із чимось.

1) Симптом: ISP1 падає і тунель падає; тунель через ISP2 ніколи не піднімається

Корінна причина: Віддалений пір дозволяє лише один вихідний IP / лише один налаштований тунель / неправильна IKE‑ідентичність для вторинного.
Виправлення: Налаштуйте обидва тунелі на віддаленій стороні явно; використовуйте стабільний ID (FQDN або DN сертифіката), а не «мій публічний IP»; підтвердіть досяжність UDP/500 і UDP/4500 через ISP2.

2) Симптом: Тунель каже «up», але користувачі ні до чого не дістаються

Корінна причина: Контрольний канал встановлений; data‑plane зламаний через відсутні маршрути, неправильні traffic selectors або віддалену маршрутизацію.
Виправлення: Пропронгуйте віддалений loopback через тунель; перевірте, чи маршрут до віддаленої підмережі вказує на тунельний інтерфейс; перевірте маршрути віддаленої сторони назад до офісу.

3) Симптом: Відбулося перемикання, але SaaS працює, а внутрішні додатки — ні

Корінна причина: Лише VPN‑шлях зламаний (відсутня досяжність піра, ESP блокується або не перемкнувся overlay‑маршрут), тоді як загальний інтернет працює.
Виправлення: Underlay‑перевірте публічну IP піра з кожного провайдера; використовуйте overlay‑проби; не довіряйте «інтернет працює» як доказ, що VPN теж в порядку.

4) Симптом: Випадкові сайти або великі завантаження падають лише через VPN, особливо після перемикання

Корінна причина: MTU/PMTU‑чорна діра; ICMP заблокований; TCP MSS надто великий для інкапсульованого шляху.
Виправлення: Защеміть MSS на тунелі або LAN‑виході; встановіть MTU тунелю; дозволіть ICMP fragmentation‑needed де можливо; верифікуйте DF‑pingами.

5) Симптом: Active/active виглядає нормально, поки голосові дзвінки не починають звучати як роботи

Корінна причина: Джиттер/перевпорядкування шляхів; асиметрична маршрутизація; ECMP розподіляє потоки по шляхах різної якості.
Виправлення: Використовуйте керування за застосунком; прив’язуйте голос до найкращого лінку; або перестаньте вигадувати і запустіть active/standby.

6) Симптом: Флапання — часті перемикання кожні кілька хвилин

Корінна причина: Агресивні пороги перевірок; одна ціль перевірки; повернення без hold‑down.
Виправлення: Використовуйте кілька цілей перевірки; вимагайте послідовних відмов; додайте таймер утримання перед поверненням; налаштуйте пороги під толерантність ваших застосунків.

7) Симптом: Вторинний тунель піднімається, але зворотний трафік вмирає (односторонній трафік)

Корінна причина: Віддалена сторона все ще маршрутизує назад через первинний тунель; поширення маршруту затримується; асиметрія маршрутів + stateful фаєрвол відкидає.
Виправлення: Переконайтеся, що віддалий бік використовує пріоритети маршрутів відповідно до стану тунелів; якщо використовуєте BGP, верифікуйте withdraw/advertise; якщо статично — звʼяжіть маршрути зі статусом тунелю.

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

Корінна причина: Таймери рекі збігаються з нестабільністю лінії; невідповідні пропозиції; DPD занадто повільний/швидкий, що викликає повторні переговори.
Виправлення: Вирівняйте криптопропозиції; рознесіть таймери рекі; налаштуйте DPD; перевіряйте логи в вікна рекі.

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

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

Крок 1: Оберіть архітектуру

За замовчуванням: маршруто‑орієнтований IPsec, active/standby тунелі, перевірки data‑plane що керують змінами маршрутів.
Шлях оновлення: додайте динамічну маршрутизацію (BGP) поверх обох тунелів, коли у вас буде кілька префіксів/сайтів.
Уникайте: DNS‑«failover», скриптів, що редагують конфіги на льоту, і ECMP без розуміння симетрії та стану.

Крок 2: Зробіть ідентичності та конфігурацію стійкими до змін WAN

Використовуйте стабільні IKE‑ID (FQDN або сертифікати), а не «мій публічний IP».
Налаштуйте обидва тунелі явно на віддаленому пірі.
Задокументуйте потрібні порти і протоколи (UDP/500, UDP/4500; ESP якщо без NAT‑T).

Крок 3: Впровадьте перевірки стану, що вимірюють корисність

Underlay‑проби: 2–3 інтернет‑цілі на кожен WAN (з привʼязкою до інтерфейсу), не лише next‑hop провайдера.
Overlay‑проби: ping віддаленого loopback та TCP‑connect до внутрішнього сервісу.
Логіка рішення: послідовні відмови, пороги і hold‑down для повернення.

Крок 4: Звʼяжіть перевірки зі маршрутизацією, а не з надією

Трековані маршрути або метрики, що змінюються при падінні перевірок.
Чіткий порядок переваг: первинний, доки не доведено погане.
Якщо мусите робити active/active — впровадьте контролі симетрії і будьте готові дебажити падіння станів.

Крок 5: Проінженеруйте для MTU і рекі‑реальності

Встановіть MTU/MSS правильно одразу. Це не «приємна дрібниця».
Рознесіть таймери рекі, якщо платформа це дозволяє.
Тримайте логи достатньо довго, щоб побачити погодинні/щоденні патерни.

Крок 6: Моніторинг і оповіщення, що не кричать даремно

Сповіщайте про: тунель down, відмови overlay‑проб і частоту флапів.
Реєструйте: який провайдер активний, втрати/латентність проб, і зміни маршрутів.
Майте один сигнал «VPN failover succeeded»; це зменшує паніку і шум у тікетах.

Крок 7: Тестуйте, як дорослі

Тест повної втрати провайдера (link down).
Тест часткових відмов (drop UDP/4500, інжекція втрат, зірваний DNS).
Тест повернення (hold‑down і стабільність).

FAQ

1) Чи робити active/active чи active/standby для офісного VPN?

Active/standby, якщо у вас немає виміряної потреби в пропускній здатності, яку не покриває один лінк. Active/active додає проблем симетрії та стану, які дорого діагностувати.

2) Чи можна покладатися лише на DPD для failover?

Ні. DPD виявляє відгук піра, а не корисність застосунків. Вам також потрібні data‑plane‑проби через тунель і, бажано, TCP‑перевірка на рівні застосунку.

3) Чому мій фаєрвол каже, що тунель вгорі, але нічого не працює?

Бо IKE може бути встановлений, а маршрути, селектори або шлях повернення на віддалій стороні — некоректні. Завжди тестуйте overlay‑досяжність до відомої віддаленої IP/служби.

4) Яка найкраща ціль для перевірки overlay‑стану?

Loopback‑інтерфейс IP на віддалому VPN‑шлюзі (стабільний, завжди маршрутизований) плюс TCP‑проба до реального сервісу, котрий вам важливий (наприклад HTTPS на внутрішньому балансувальнику).

5) Чи потрібен мені BGP для доброго failover?

Не для одного офісу до одного сайту. Статичні маршрути з трекінгом можуть бути цілком надійними. Використовуйте BGP коли маєте кілька префіксів, кілька сайтів або втомилися керувати статичними маршрутами.

6) Наскільки швидким має бути failover?

Достатньо швидко, щоб користувачі не помітили, але досить повільно, щоб не флапати. На практиці: виявлення ~10–30 секунд для багатьох офісів і hold‑down для повернення 60–300 секунд. Налаштовуйте під спостережувану поведінку лінка.

7) Чому великі файли падають, а маленькі pings проходять?

Класична MTU/PMTU‑чорна діра. Маленькі ICMP‑пакети проходять, більші TCP‑сегменти — ні. Виправте зажим MSS і підтвердіть DF‑pingами.

8) Чи можна робити failover через зміну публічного DNS для VPN‑endpoint?

Можна, але це ненадійно. Кешування DNS і довгоживучі сесії зрадять вас. Використовуйте два тунелі і справжню логіку маршрутизації/перевірок.

9) Що робити, якщо у мого резервного провайдера CGNAT?

Це все ще можливо, якщо віддалений пір приймає NAT‑T зі змінними вихідними портами/адресами, але ризик вищий. Переважно мати реальний публічний IP для термінації VPN, або використовувати керований реле/термінатор у хмарі, яким ви володієте.

10) Як уникнути флапінгу при поверненні, коли ISP1 «майже повернувся»?

Додайте таймер hold‑down і вимагайте стійких здорових проб перед поверненням. Також перевіряйте кілька цілей; одне відновлене зʼєднання не означає, що інтернет справді в порядку.

Висновок: наступні кроки, які реально можна зробити цього тижня

Якщо хочете резервування офісного VPN, яке не потребує ручного догляду, перестаньте думати «про дві лінії» і почніть думати «про вимірювані, керовані шляхи». Побудуйте два тунелі, доведіть, що обидва працюють, і змусьте маршрутизатор/фаєрвол обирати на підставі data‑plane‑перевірок — не на підставі світлодіодів.

Практичні наступні кроки

Inventory reality: Підтвердіть, що обидва провайдера можуть дістатися публічної IP віддаленого VPN‑піра і що UDP/500/4500 проходять обома шляхами.
Stand up the secondary tunnel: Налаштуйте його на обох кінцях. Переконайтеся, що він встановлюється і може передавати трафік, перш ніж називати його «резервним».
Add overlay probes: Пропінгуйте віддалений loopback і робіть TCP‑проби до сервісу через тунель. Нехай маршрути слідують за результатами проб.
Fix MTU early: Тестуйте DF‑pingами, зажміть MSS і задокументуйте обрані значення.
Run a failover drill: Симулюйте відмову в контрольованому вікні, спостерігайте зміни маршрутів, підтвердіть вплив на користувачів і налаштуйте пороги, щоб припинити флапання.

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