Відключення Windows IKEv2: поширені помилки та надійні виправлення

Як Windows IKEv2 фактично відмовляє (щоб ви перестали гадати)

«Відключення IKEv2» — це не одна проблема. Це родина проблем, які на користувацькому рівні виглядають як «VPN обірвався».
Ваше завдання — розділити: помилки переговорів (не вдається підняти тунель), помилки живучості (тунель піднятий, потім помирає),
проблеми з маршрутизацією/MTU (тунель піднятий, трафік залипає), та проблеми з обліковими даними/сертифікатами (тунель працює, доки не потрібно оновити).

Рухомі частини, що мають значення у Windows

• RasClient: шар клієнта VPN у Windows. Коди помилок часто виходять звідси.
• IKEEXT: служба IKE і AuthIP IPsec Keying Modules. Якщо вона незадоволена, нічого хорошого не станеться.
• IPsec policy: пропозиції (шифрування/цілісність/група DH), строки життя та які селектори трафіку дозволені.
• Сертифікати: EKU, перевірка ланцюга, доступність CRL/OCSP і правильна ідентичність (SAN проти CN).
• NAT‑T: якщо ви за NAT (майже завжди), йдеться про UDP 4500. Блокування цього — класика.
• Rekey + DPD: світ «тримаємо живими», де тунелі вмирають, коли одна сторона вирішує, що інша зникла.
• Зміни мережевого профілю: роумінг Windows з Wi‑Fi на LTE — це тест на витривалість тунелю.

Що на практиці зазвичай означає «відключення»

Більшість реальних відключень у Windows IKEv2 потрапляють у кілька кошиків:

1. UDP 500/4500 блокується або спотворюється посеред сесії (готельний Wi‑Fi, captive portal, «безпечні» фаєрволи).
2. Несумісність при перевстановленні ключів (строки життя, пропозиції, PFS або таймінги NAT‑мапінгів) що викликає падіння кожні N хвилин.
3. Проблеми з ланцюгом/ідентичністю сертифікатів, що з’являються після ротації, зміни CA або простої відсутності CRL.
4. MTU/фрагментація, коли IKE працює, тунель «підключений», але реальний трафік зупиняється або скидається.
5. Маршрутизація/DNS із розділенням, коли тунель лишається, але користувач вважає, що він «впав», бо нічого не резолвиться.

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

Одне висловлення, яке варто повісити на стіну: «Сподівання — не стратегія.» — Vince Lombardi.
Операційні люди люблять його за те, що воно болісно точне.

Короткий жарт #1: Якщо ваш IKEv2 тунель відключається що 60 хвилин — вітаю, ваш VPN навчився брати перерву на обід.

Швидка інструкція діагностики

Це план «потрібен напрямок за п’ять хвилин». Він передбачає клієнт Windows + якийсь стандартний IKEv2‑сервер
(RRAS, strongSwan, Libreswan, Palo Alto, FortiGate, ASA, Azure VPN Gateway тощо). Назви регуляторів міняються; режими відмов — ні.

Спочатку: визначте, чи це «не вдається підключитися» чи «підключається, потім відключається»

• Не вдається підключитися: сфокусуйтеся на пропозиціях, сертифікатах, портах і ідентичності.
• Підключається, потім відключається: перевірте DPD, NAT‑мапінги, rekey, роумінг, MTU і проміжні коробки.

По‑друге: витягніть один журнал, що каже правду

У Windows найкращий перший крок — журнал RasClient (operational) плюс події IKEEXT.
Якщо дивитися лише помилку в GUI, ви обмулюєтеся в темряві.

По‑третє: підтвердіть стан шляху UDP 500/4500

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

По‑четверте: перевірте часи перевстановлення ключів та строки життя

Відключення через рівні інтервали кричать «несумісність строків життя» або «невдале rekey». Якщо це точно 30/60/120 хвилин,
не сперечайтеся — міряйте та зіставляйте з Phase 1 / Phase 2 lifetimes.

По‑п’яте: протестуйте шлях великих пакетів, щоб виявити MTU‑проблеми

Контрольний трафік IKE — крихітний. Ваш реальний трафік — ні. Якщо великі пакети фрагментуються або відкидаються, користувачі звертатимуться, як ніби VPN впав.
Це не VPN‑падіння, це проблема PMTU під маскою.

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

Роумінг — це зміна стану: нова IP, новий NAT, нові правила фаєрвола, новий DNS. IKEv2 може обробляти мобільність (MOBIKE) на деяких стекх,
але підтримка Windows залежить від сценарію й можливостей сервера. Розглядайте збої при роумінгу як окрему категорію.

Цікаві факти та трохи історії

Трохи контексту допоможе передбачити, де приховані проблеми. Ось конкретні відомості, що з’являються під час реальної діагностики.

1. IKEv2 був стандартизований у 2005 році (RFC 4306). Він замінив складність IKEv1 чистішою моделлю обміну.
2. NAT‑traversal (NAT‑T) старший за більшість VPN‑рукбуків: практичний підхід «IPsec через NAT» став поширеним на початку 2000‑х і згодом стандартизований (RFC 3947/3948).
3. Стек VPN у Windows багаторівневий: RasClient керує профілями користувача, IKEEXT — IKE/IPsec. Діагностика тільки RasClient — як лагодити сховище, дивлячись на букву диска в GUI.
4. EAP vs сертифікатна автентифікація змінюють моделі відмов: EAP (наприклад EAP‑MSCHAPv2) часто падає через «облікові дані», сертифікатна автентифікація — через ланцюг/ідентичність/CRL. Один симптом — різні всесвіти.
5. UDP 4500 існує, бо NAT ламає IPsec: ESP (IP протокол 50) не дружить з NAT, тому NAT‑T інкапсулює ESP в UDP.
6. Dead Peer Detection (DPD) навмисно нетерплячий: він очищає стан швидко, коли пір зникає. На непевних мережах ця «фіча» стає вашим простоєм.
7. Коди помилок у Windows часто абстракції: помилки 809 і 812 можуть маскувати кілька корінних причин; журнали подій відкривають справжні статус‑коди IPsec/IKE.
8. Збої при rekey часто викликають проміжні коробки: крипточастина в порядку, але NAT‑мапінг закінчився, фаєрвол стер стан або DPI‑пристрій вирішив, що UDP 4500 підозрілий сьогодні.
9. Фрагментація IKEv2 існує, але це не магія: якщо шлях відкидає фрагменти або блокує ICMP занадто агресивно, ви отримаєте зависання.

Поширені помилки, що вони означають і що робити

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

Error 809: «The network connection between your computer and the VPN server could not be established»

Що зазвичай означає: IKE‑пакети не отримали працездатного зворотного шляху. Зазвичай UDP 500/4500 заблоковані, NAT‑T зламано або сервер не слухає.

Надійні виправлення:

• Підтвердіть, що UDP 500 і 4500 дозволені наскрізь (мережа клієнта, локальний фаєрвол, крайовий фаєрвол, security groups сервера).
• Переконайтеся, що сервер дійсно прив’язаний/слухає і не обмежений політикою (особливо для RRAS/Windows Server).
• Перевірте наявність подвійного NAT або агресивних таймаутів NAT; налаштуйте keepalive/DPD на стороні сервера, де можливо.
• Якщо ви використовуєте сертифікатну автентифікацію: підтвердіть, що клієнт довіряє ланцюгу сертифікатів сервера та що сервер подає правильний сертифікат.

Error 812: «The connection was prevented because of a policy configured on your RAS/VPN server»

Що зазвичай означає: автентифікація пройшла частково і далі політика відхилила підключення. Часто це NPS/RADIUS‑політика, членство в групі, невідповідність EAP або обмеження типу тунелю.

Надійні виправлення:

• Перевірте політику сервера для користувача/групи і типу тунелю IKEv2.
• Підтвердіть, що метод автентифікації (тип EAP) відповідає конфігурації клієнта.
• Перевірте відображення сертифікатів, якщо використовуються машинні/користувацькі сертифікати і сервер очікує конкретний EKU або шаблон subject.

Error 13801: «IKE authentication credentials are unacceptable»

Що зазвичай означає: невідповідність сертифікатної автентифікації: неправильна ідентичність, невірний EKU, відсутній приватний ключ, недовіра до ланцюга або проблеми з CRL/OCSP. Іноді також невідповідність PSK (якщо використовується).

Надійні виправлення:

• Перевірте, що клієнтський сертифікат має EKU «Client Authentication» і приватний ключ, а також що сервер довіряє видавцю CA.
• Перевірте, що серверний сертифікат має EKU «Server Authentication» і його ідентичність відповідає тому, що очікує клієнт (SAN — сучасна реальність).
• Переконайтеся, що точки розповсюдження CRL доступні з клієнта під час підключення (це б’є по дизайну «VPN потрібен, щоб дістатися до PKI»).

Error 0x800B0109 / «A certificate chain processed, but terminated in a root certificate which is not trusted»

Що зазвичай означає: клієнт не довіряє кореневому/проміжному CA, або сервер подав неповний ланцюг.

Надійні виправлення:

• Розгорніть правильні кореневі та проміжні сертифікати в сховище довіри клієнта.
• Виправте сервер, щоб він подавав проміжні сертифікати (поширена помилка на пристроях і деяких Linux‑стеках).

Відключення кожні 30/60/120 хвилин

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

Надійні виправлення:

• Синхронізуйте строки життя IKE SA і Child SA на обох сторонах (і запас для перевстановлення ключів).
• Увімкніть/перегляньте DPD і NAT keepalive; переконайтеся, що NAT‑мапінг не закінчується посеред сесії.
• Дослідіть проміжні коробки, що занадто агресивно випалюють UDP‑стани.

Підключено, але «деякі сайти не працюють» або «Teams обривається»

Що зазвичай означає: split tunneling маршрути, DNS або MTU. Тунель не впав; трафік неправильно маршрутизований або йде в чорну діру.

Надійні виправлення:

• Переконайтеся, що маршрути, встановлені профілем VPN, відповідають вашим намірам.
• Переконайтеся, що DNS‑сервери і пошуковий суфікс правильні, і що правила NRPT (якщо використовуються) коректні.
• Протестуйте PMTU і відрегулюйте MTU інтерфейсу або clamp MSS на шлюзі VPN, якщо є така можливість.

Короткий жарт #2: Усунення неполадок VPN — це просто мережі, але з більшою кількістю сертифікатів і менше друзів, які готові залишатися на дзвінку.

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

Це реальні завдання, які я використовую, коли хтось каже «Windows IKEv2 постійно відключається». Кожне містить команду,
типовий вивід, що це означає, і яке рішення приймається далі. Ви виконуватимете деякі на Windows, деякі — на VPN‑сервері.
Команди показані в консольному форматі; підлаштуйте імена хостів і інтерфейсів під ваше середовище.

Завдання 1: Підтвердити, що профіль VPN справді IKEv2 і не щось «допоміжне»

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'Corp-IKEv2' | Select-Object Name,TunnelType,AuthenticationMethod,SplitTunneling"
Name      TunnelType AuthenticationMethod SplitTunneling
----      ---------- -------------------- --------------
Corp-IKEv2 Ikev2      Eap                 True

Що це означає: Ви дійсно використовуєте IKEv2. Аутентифікація — EAP, split tunneling увімкнено.

Рішення: Якщо TunnelType не Ikev2, зупиніться. Спочатку виправте профіль. Якщо автентифікація — EAP, зосередьтеся на NPS/RADIUS і конфігурації EAP; якщо Certificate, фокусуйтеся на PKI.

Завдання 2: Витягнути помилки RasClient поблизу відключення

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-RasClient/Operational' -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Auto"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  20227 Error            CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2 which has failed. The error code returned on failure is 809.
12/27/2025 09:14:10  20226 Information      CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2.

Що це означає: GUI‑відключення підкріплене конкретним кодом помилки RasClient і міткою часу.

Рішення: Використайте мітку часу, щоб зіставити з журналами IKEEXT і логами сервера. Помилка 809 штовхає до перевірки шляху UDP/NAT‑T.

Завдання 3: Перевірити події IKEEXT на предмет помилок переговорів чи автентифікації

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-IKE/Operational' -MaxEvents 10 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  4653 Error            IKE failed to find valid machine certificate. Error 0x800B0109

Що це означає: Це не мережа. Це довіра/ланцюг сертифікатів.

Рішення: Припиніть чіпати правила фаєрвола. Виправте довіру CA, проміжні сертифікати та вибір сертифіката.

Завдання 4: Перевірити наявність клієнтського сертифіката і приватного ключа

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\CurrentUser\My | Select-Object Subject,HasPrivateKey,NotAfter,EnhancedKeyUsageList | Format-List"
Subject            : CN=alice, OU=Corp, O=Example
HasPrivateKey      : True
NotAfter           : 06/01/2026 12:00:00
EnhancedKeyUsageList : {Client Authentication (1.3.6.1.5.5.7.3.2)}

Що це означає: Сертифікат присутній, придатний і має правильний EKU.

Рішення: Якщо HasPrivateKey False або EKU відсутній/невірний — перевипустіть або виправте шаблон/політику. Якщо виглядає добре — переходьте до перевірки ланцюга і відповідності ідентичності.

Завдання 5: Підтвердити, що корінь/проміжні довірені на клієнті

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.Subject -like '*Example Root CA*'} | Select-Object Subject,Thumbprint,NotAfter"
Subject                 Thumbprint                                NotAfter
-------                 ----------                                --------
CN=Example Root CA      9A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B  01/01/2035 00:00:00

Що це означає: Кореневий CA присутній. Якщо використовуються проміжні, переконайтеся, що вони також встановлені (store Intermediate Certification Authorities).

Рішення: Якщо відсутні — розгорніть через GPO/MDM. Якщо присутні — перевірте, чи сервер відсилає проміжні коректно.

Завдання 6: Перевірити, чи Windows намагається використовувати NAT‑T (UDP 4500), а не застряг на UDP 500

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecMainModeSA | Select-Object -First 5 LocalAddress,RemoteAddress,LocalPort,RemotePort,AuthMethod,EncryptionAlgorithm,IntegrityAlgorithm | Format-Table -Auto"
LocalAddress RemoteAddress LocalPort RemotePort AuthMethod EncryptionAlgorithm IntegrityAlgorithm
------------ ------------- --------- ---------- --------- ------------------- -----------------
10.50.12.34  203.0.113.10  4500      4500       EAP      AESGCM256           None

Що це означає: IKE SA на UDP 4500: NAT‑T використовується, що нормально для більшості клієнтських мереж.

Рішення: Якщо UDP 4500 ніколи не видно, підозрюйте невдале виявлення NAT або політику, що примушує лише UDP 500. Перевірте, щоб UDP 4500 дозволявся локальними та крайовими фаєрволами.

Завдання 7: Перевірити, чи Child SA стабільні і не періодично перевстановлюються

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecQuickModeSA | Select-Object -First 5 RemoteAddress,LocalSubnet,RemoteSubnet,KeyModule,EncryptionAlgorithm,IntegrityAlgorithm,SAIdleTime | Format-Table -Auto"
RemoteAddress LocalSubnet     RemoteSubnet      KeyModule EncryptionAlgorithm IntegrityAlgorithm SAIdleTime
------------- -----------     ------------      --------- ------------------- ----------------- ----------
203.0.113.10  10.50.12.34/32  10.0.0.0/8        IKEv2     AES256              SHA256            00:02:11

Що це означає: Quick Mode (Child SA) існує. Якщо ви бачите їх постійно створеними наново — це цикл rekey або проблеми з селекторами трафіку.

Рішення: Для rekey‑циклу: узгодьте строки життя/пропозиції та перевірте серверні логи. Для проблем селекторів: перевірте, які підмережі штовхаються/дозволені з обох боків.

Завдання 8: Перевірити MTU інтерфейсу і протестувати PMTU пінгами з «do not fragment»

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Select-Object InterfaceAlias,NlMtu,ConnectionState | Format-Table -Auto"
InterfaceAlias        NlMtu ConnectionState
--------------        ----- ---------------
Corp-IKEv2            1400  Connected

cr0x@server:~$ powershell -NoProfile -Command "ping 10.0.10.10 -f -l 1360"
Pinging 10.0.10.10 with 1360 bytes of data:
Reply from 10.0.10.10: bytes=1360 time=21ms TTL=62

Що це означає: MTU — 1400, і payload 1360 байт працює без фрагментації. Якщо це не вдається — у вас проблема з фрагментацією/PMTU.

Рішення: Якщо DF‑пінги з великим розміром не проходять — зменшіть MTU інтерфейсу VPN (або clamp MSS на шлюзі). Якщо тільки певні напрямки падають — підозрюйте проміжний фаєрвол, який відкидає фрагменти або ICMP.

Завдання 9: Підтвердити поведінку DNS та суфіксів під час сесії VPN

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto"
InterfaceAlias        ServerAddresses
--------------        ---------------
Ethernet              {192.168.1.1}
Corp-IKEv2            {10.0.0.53, 10.0.0.54}

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal-app.corp.example -Server 10.0.0.53 | Select-Object Name,IPAddress"
Name                     IPAddress
----                     ---------
internal-app.corp.example 10.0.20.15

Що це означає: Інтерфейс VPN має корпоративні DNS і резолв працює при безпосередньому запиті до них.

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

Завдання 10: Перевірити маршрути та чи присутні маршрути split‑tunnel і мають пріоритет

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Sort-Object DestinationPrefix | Select-Object DestinationPrefix,NextHop,RouteMetric | Format-Table -Auto"
DestinationPrefix NextHop      RouteMetric
---------------- --------      -----------
10.0.0.0/8        0.0.0.0      5
172.16.0.0/12     0.0.0.0      5
192.168.0.0/16    0.0.0.0      5

Що це означає: Маршрути split‑tunnel існують і прив’язані до інтерфейсу VPN.

Рішення: Якщо маршрути відсутні — проблема в конфігурації профілю або серверній політиці/пуші. Якщо метрики вищі за локальні маршрути — Windows може обирати неправильний шлях; відрегулюйте метрики обережно.

Завдання 11: Захоплення пакетів на Windows, щоб підтвердити поведінку UDP 500/4500 під час відключення

cr0x@server:~$ powershell -NoProfile -Command "netsh trace start capture=yes report=yes scenario=VPNClient maxsize=512 filemode=circular tracefile=C:\Temp\ikev2.etl"
Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Temp\ikev2.etl
Max Size:           512 MB
File Mode:          Circular

cr0x@server:~$ powershell -NoProfile -Command "netsh trace stop"
Merging traces ... done
Generating report ... done
Trace file and report:
C:\Temp\ikev2.etl
C:\Temp\ikev2.cab

Що це означає: Ви захопили сценарій VPNClient. Це часто достатньо, щоб побачити, чи пакети перестають відправлятися, перестають повертатися або виникають ICMP‑помилки.

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

Завдання 12: Перевірити служби Windows, що мають бути активні (RasMan, IKEEXT)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RasMan,IKEEXT | Format-Table Name,Status,StartType -Auto"
Name   Status Running StartType
----   ------ ------- ---------
RasMan Running         Manual
IKEEXT Running         Manual

Що це означає: Потрібні служби працюють. Якщо вони перезапускаються або падають — ви отримаєте «випадкові» падіння VPN, що не пов’язані з мережею.

Рішення: Якщо якась служба зупинена або флапає — перевірте системні події, оновлення драйверів і втручання ПЗ безпеки. Виправте це перед налаштуванням IPsec.

Завдання 13: На Linux‑сервері VPN перевірити, чи слухає він і бачити IKE‑рукопотискання

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

Що це означає: strongSwan’s charon прив’язаний до UDP 500/4500. Якщо ці порти не відкриті — клієнти падатимуть з симптомами на зразок 809.

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

Завдання 14: На сервері підтвердити, що фаєрвол дозволяє UDP 500/4500

cr0x@server:~$ sudo nft list ruleset | egrep -n 'udp dport (500|4500)'
42: udp dport 500 accept
43: udp dport 4500 accept

Що це означає: Фаєрвол сервера дозволяє IKE/NAT‑T.

Рішення: Якщо відсутні — додайте правила. Якщо присутні — підозрюйте upstream фаєрволи або security groups. Якщо відкритий лише один порт — виправте обидва.

Завдання 15: На strongSwan перевірити живі SA і таймінги rekey

cr0x@server:~$ sudo swanctl --list-sas
ikev2-corp: #12, ESTABLISHED, IKEv2, 3b1c2d3e4f...
  local  'vpn.corp.example' @ 203.0.113.10[4500]
  remote 'alice' @ 198.51.100.27[52344]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, rekeying in 41 minutes
  child: corp-net, #25, INSTALLED, TUNNEL, ESP:AES_GCM_16_256, rekeying in 9 minutes

Що це означає: Видно таймери rekey. Якщо відключення збігаються з моментами «rekeying in …», ви знайшли тригер.

Рішення: Якщо rekey не вдається — синхронізуйте строки життя/пропозиції, перевірте фрагментацію/MTU і проаналізуйте поведінку NAT. Якщо rekey працює, але тунель падає під час роумінгу — налаштуйте MOBIKE/DPD.

Завдання 16: Спостерігати логи в реальному часі під час шторму перепідключень (сервер)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" -f
Dec 27 09:14:11 vpn charon[1123]: 12[IKE] peer supports MOBIKE
Dec 27 09:14:41 vpn charon[1123]: 12[IKE] sending DPD request
Dec 27 09:14:46 vpn charon[1123]: 12[IKE] DPD response received
Dec 27 09:15:12 vpn charon[1123]: 12[IKE] retransmit 1 of request with message ID 7
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] giving up after 5 retransmits
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] deleting IKE_SA ikev2-corp[12] between 203.0.113.10[ vpn.corp.example ]...198.51.100.27[ alice ]

Що це означає: DPD почав працювати, потім почалися ретрансляції, потім SA видалено. Класичний шлях або розрив NAT.

Рішення: Дослідіть таймаут NAT, зміни мережі клієнта або фільтрацію UDP 4500. Налаштуйте DPD/keepalive менш агресивно і перевірте поведінку при роумінгу.

Три міні‑історії з корпоративного світу

Інцидент 1: Неправильне припущення («Це IKEv2, отже роумінг працює автоматично»)

Середня компанія впровадила IKEv2 замість SSTP для віддалених працівників. Пілотній групі сподобалося. Потім розгортання дісталося команді продажу,
людському уособленню «завжди рухається». Скарги були послідовні: підключаються на домашньому Wi‑Fi, йдуть на зустріч, перемикаються на хот‑спот телефону,
і VPN тихо помирає. Користувачі казали, що це «випадкові відключення», бо збій не відбувався відразу. Він відбувався через п’ять хвилин,
коли NAT‑мапінг пройшов і DPD вирішив, що пір помер.

Мережева команда припускала, що IKEv2 означає MOBIKE і безшовний роумінг. Це зрозуміле — і в реальних сценаріях неправильне. Windows IKEv2
плюс обрана конфігурація шлюзу не поводилися як мобільний клієнт VPN. Тунель нормально підключався, але після зміни IP сервер продовжував посилати
на старий tuple, поки SA не помер. Тоді Windows намагався встановити заново, іноді вдаючись, іноді застрягаючи за captive portal.

Виправлення не вимагало нового набору шифрів. Вони додали дві операційні зміни: (1) коротші, адекватні інтервали DPD з невеликою паузою,
і (2) явні вказівки в профілі Always On VPN тригерити перепідключення при зміні мережі. Також оновили скрипти служби підтримки: «Якщо ви щойно змінили мережу, відключіться/підключіться ще раз»
стало робочим обходом замість народної магії. Стабільність покращилася, бо система була спроектована для роумінгу, а не надії на нього.

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

Інцидент 2: Оптимізація, що обернулась проти («Давайте зменшимо строки життя для кращої безпеки»)

Інша організація вирішила «затвердити» свій VPN, агресивно зменшивши строки життя IPsec. Коротші строки можуть бути прийнятні.
Але вони перестаралися і зробили це асиметрично: команда шлюзу поміняла строки Child SA, Windows‑профілі залишилися майже за замовчуванням,
і ніхто не перевірив поведінку rekey під навантаженням.

Далі сталося передбачуване. Кількість rekey‑ів зросла. CPU на шлюзі піднявся, але не настільки, щоб хтось помітив.
Потім з’явилася справжня проблема: користувачі відключалися через регулярні інтервали протягом робочого дня. Не всі одночасно — лише достатньо,
щоб створити постійну чергу підтримки. Хелпдеск звинувачував Wi‑Fi. Wi‑Fi команда звинувачувала VPN. VPN команда казала «Windows як завжди».

Пакетні захоплення показали, що обмін rekey починався, потім одна сторона не приймала пропозицію. Іноді працювало, іноді ні, залежно від того,
яка інстанція SA потрапляла першою на невідповідність. Також чим частіше ви робите rekey, тим більше залежите від стабільності шляху, свіжості UDP‑станів
і коректності фрагментації. Іншими словами: ви перетворили надійну систему на таку, що вимагає ідеальних умов.

Виправлення було нудним і ефективним: узгодити строки життя, встановити розумні запаси пере‑ключування і тримати криптосuites сучасними, але не екзотичними.
Вони відновили більші Child SA lifetimes і використали розклад rekey, який не навантажував контрольну площину. Безпека суттєво не постраждала;
надійність різко покращилася. У виробництві заходи безпеки, що штовхають користувачів обходити VPN, — це не заходи безпеки. Це марні бажання.

Інцидент 3: Нудна практика, що врятувала день (дисциплінована ротація сертифікатів)

Велика компанія ротацувала issuing CA і серверні сертифікати як частину модернізації PKI. Зазвичай це момент, коли VPNи вмирають.
Сертифікати не складні; екосистеми сертифікатів складні. CRL рухаються. Проміжні змінюються. Старі клієнти панікують.
Хтось завжди забуває про проміжний сертифікат десь.

Ця команда зробила одну непоказну річ: вони підтримували канарний набір профілів VPN і клієнтів, прив’язаний до тестового шлюзу.
Канарний набір перевіряв довіру ланцюга, EKU і відповідність ідентичності за тиждень до загального переключення.
Також у них був письмовий відкат: «відновити попередній серверний сертифікат + бандл проміжних», з часовим вікном і чіткою відповідальністю.

У день вирубки канарні клієнти виявили проблему: клієнти на гостьовому Wi‑Fi не могли дістатися до нових CRL‑точок.
Без доступу до CRL Windows відмовився довіряти новому сертифікату, і помилка виглядала як загальна IKE‑помилка автентифікації.
Канарка врятувала їх від розгортання сертифікату, що вимагав VPN для перевірки сертифікату, потрібного для використання VPN. Так, це звучить так само циклічно, як і є.

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

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

Цей розділ навмисно різкий. Більшість «відключень Windows IKEv2» повторюються, бо команди наступають на одні й ті ж граблі.
Ось типові випадки, прив’язані до спостережуваних симптомів.

1) Симптом: Error 809 в деяких мережах, але не в інших

Корінна причина: UDP 4500 блокується або обробляється; captive portal; «безпечний» Wi‑Fi фільтрує; або upstream NAT/фаєрвол швидко витісняє UDP‑стани.

Виправлення: Забезпечте прохід UDP 500/4500. Якщо ви не можете контролювати мережу, збільшіть keepalive/DPD толерантність і надайте fallback (іноді SSTP — прагматичний запас).

2) Симптом: Підключається нормально, потім відключається за сталим інтервалом

Корінна причина: несумісність строків життя або невдале rekey; закінчення NAT‑мапінгу; DPD надто агресивний; CPU‑спайки шлюзу під час хвилі rekey.

Виправлення: Узгодьте строки життя і пропозиції; налаштуйте DPD/keepalive; перевірте потужність шлюзу; уникайте надто коротких строків життя без вагомих підстав.

3) Симптом: Error 13801 після змін сертифікатів

Корінна причина: неправильний EKU, відсутній приватний ключ, недовіра ланцюга, невідповідність ідентичності (SAN) або відмови перевірки відкликання.

Виправлення: Перевірте EKU, ланцюг і ідентичність з обох боків. Переконайтеся, що проміжні подаються. Переконайтеся, що CRL/OCSP доступні без VPN.

4) Симптом: «Підключено», але внутрішні сайти тайм‑аутять; малі пінги працюють, завантаження падають

Корінна причина: MTU‑чорна діра, блокування фрагментації, занадто великий MSS або PMTU‑discover зламаний через блокування ICMP.

Виправлення: Зменшіть MTU на інтерфейсі VPN; clamp MSS на шлюзі; дозвольте необхідний ICMP (принаймні fragmentation‑needed), де це можливо.

5) Симптом: Доступні лише деякі підмережі, інші мертві

Корінна причина: відсутні/неправильні маршрути split tunneling; селектори трафіку не включають потрібні підмережі; накладення адрес з домашніми мережами.

Виправлення: Виправте штовхані маршрути/TS; уникайте накладання RFC1918 діапазонів; якщо уникнути накладання неможливо — використайте NAT на VPN або переробіть адресацію.

6) Симптом: Відключення корелюють зі сном/гібернацією або закриттям кришки

Корінна причина: енергозбереження NIC, сон системи руйнує UDP‑стан, або VPN‑клієнт некоректно відновлюється.

Виправлення: Налаштуйте політики живлення для корпоративних пристроїв; переконайтеся, що Always On VPN тригерить перепідключення; розгляньте відключення агресивного енергозбереження NIC через політику.

7) Симптом: Працює по Ethernet, падає по Wi‑Fi

Корінна причина: Wi‑Fi блокує UDP 4500, має особливості ізоляції клієнтів, або стек захисту кінцевої точки фільтрує відмінно по різних інтерфейсах.

Виправлення: Підтвердьте за допомогою захоплення пакетів; перевірте локальні профілі фаєрвола (Public vs Private); відрегулюйте політики кінцевої точки для UDP 500/4500.

8) Симптом: Сервер показує ретрансляції, клієнт показує «authentication failed»

Корінна причина: повідомлення втрачаються під час обміну; фрагментація IKE‑повідомлень; MTU або проміжні коробки відкидають; іноді великі ланцюги сертифікатів роздувають IKE‑повідомлення.

Виправлення: Зменшіть розмір ланцюга сертифікатів; увімкніть підтримку фрагментації IKE на сервері; виправте MTU; припиніть сліпо блокувати фрагменти/ICMP.

9) Симптом: Після вмикання «сильнішої» криптографії деякі клієнти падають

Корінна причина: невідповідність пропозицій; старі збірки Windows або деякі пристрої не підтримують обрані набори так, як ви думаєте.

Виправлення: Використовуйте консервативний сучасний базовий набір (AES‑GCM, SHA2 PRF, DH group 14/19+ за потреби) і перевіряйте на тестовому кільці перед розгортанням.

Контрольні списки / покроковий план

Покроково: стабілізувати хитке розгортання Windows IKEv2

1. Зберіть мітки часу й симптоми. Отримайте точний час відключення, тип мережі (домашній Wi‑Fi, LTE, офіс) і чи періодичність є.
2. Спочатку витягніть RasClient + IKE журнали. Якщо журнал вкаже на сертифікат/автентифікацію — зупиніться там. Якщо вказує на 809/транспорту — переходьте до перевірки шляху.
3. Переконайтеся, що служби (RasMan/IKEEXT) не флапають. Якщо флапають — виправте стабільність кінцевої точки перед налаштуваннями мережі.
4. Підтвердьте досяжність UDP 500/4500. З уражених мереж. Не припускайте, що те, що працює в офісі, працює в готелі.
5. Перевірте, чи NAT‑T фактично використовується. Якщо клієнти за NAT (вони зазвичай), вам потрібен стабільний UDP 4500.
6. Узгодьте пропозиції та строки життя. Обидві сторони мають погоджені параметри. Пере‑ключуйте не так часто, щоб створити DDoS на контрольну площину.
7. Рано тестуйте MTU. DF‑пінг і реальні потоки. Виправте чорні діри перш ніж сперечатися про маршрути.
8. Підтвердіть DNS і маршрути. Переконайтеся, що корпоративні імена резолвяться через корпоративний DNS і що потрібні підмережі йдуть через VPN.
9. Тести роумінгу. Перемикайте мережі під час безперервного ping/SSH/RDP і спостерігайте. Якщо ламається — вирішіть, чи підтримувати роумінг або задокументувати обмеження.
10. Впровадьте канарки. Пілотуйте профілі й зміни сертифікатів на невеликому кільці перед широким розгортанням.
11. Задокументуйте мережі «відомо погані». Деякі мережі блокують UDP 4500. Плануйте fallback або свідомо приймайте обмеження.
12. Автоматизуйте збір логів для служби підтримки. Однорядковий скрипт, що експортує RasClient і IKE журнали, заощадить години на кожному тікеті.

Операційний чек‑лист: перед змінами на шлюзі

• Чи є тестовий клієнт і канарний шлюз?
• Чи відомі нинішні IKE/Child строки життя і пропозиції з обох сторін?
• Чи перевірено доступність CRL/OCSP ззовні VPN?
• Чи є у вас захоплення пакетів з одного випадку помилки?
• Чи можете швидко відкотити (знімок конфігурації/експорт)?

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

• Перевірте підключення, відключення, перепідключення.
• Перевірте тривалий трафік (10–30 хвилин) і слідкуйте за rekey‑поведінкою.
• Протестуйте великі передачі і DF‑пінги.
• Якщо ви заявляєте підтримку роумінгу — протестуйте Wi‑Fi ↔ LTE.
• Переконайтеся, що хелпдеск має нові кроки «що збирати».

FAQ

1) Чому Windows IKEv2 частіше відключається в готелях або на гостьовому Wi‑Fi?

Такі мережі часто блокують або агресивно тайм‑аутять UDP‑потоки, особливо UDP 4500. IPsec NAT‑T виглядає для деяких пристроїв як «невідомий UDP‑трафік».
Captive portals також викликають тихі зміни шляху, що ламають існуючі NAT‑мапінги. Підтвердіть це журналами і трасою.

2) Чи завжди помилка 809 — це проблема фаєрвола?

Зазвичай це проблема доступності, але «доступність» включає поведінку NAT, upstream‑фільтрацію та навіть локальне фільтрування кінцевої точки.
Розглядайте 809 як «IKE не встановив працездатний шлях», а далі перевіряйте UDP 500/4500 і стан прослуховування сервера.

3) Який найшвидший спосіб визначити, чи це сертифікати?

Перевірте журнал Microsoft-Windows-IKE/Operational на предмет помилок ланцюга й облікових даних (наприклад 0x800B0109) біля часу збою.
Якщо такі є — припиніть налаштування портів і почніть перевіряти EKU, довіру ланцюга та доступність відкликання.

4) Чому він відключається рівно щогодини?

Це майже завжди поведінка rekey/строків життя або таймаут стану, що збігається з таймером. Узгодьте IKE SA і Child SA lifetimes,
і перевірте, чи не закінчується NAT‑мапінг у той же час. Серверні логи з показом спроб rekey — ваші друзі.

5) Чи слід зменшувати строки життя IPsec заради «кращої безпеки»?

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

6) Підключено, але внутрішні DNS імена не резолвляться — чому тунель виглядає добре?

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

7) Чи справді MTU‑проблеми виглядають як відключення?

Так. Додатки тайм‑аутять, сесії скидаються, голосові виклики деградують, і користувачі кажуть «VPN впав», бо це єдиний відомий їм важіль.
Тестуйте DF‑пінги і реальні передачі. Виправте MTU/MSS/ICMP і ви «виправите відключення», яких насправді не було.

8) Чи може ПЗ захисту кінцевої точки викликати відключення IKEv2?

Безумовно. Вбудовані фаєрволи, «мережева інспекція» та драйвери, що впливають на VPN, можуть відкидати або затримувати UDP 4500,
блокувати трафік перевірки сертифікатів або перезапускати служби. Якщо ви бачите флапи служб або тільки деякі машини постраждали — досліджуйте стек кінцевої точки.

9) Чи split tunneling частіше спричиняє нестабільність?

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

Висновок: наступні кроки, що тримаються

Відключення Windows IKEv2 перестають бути таємничими, коли ви ставитеся до них як до будь‑якого виробничого інциденту:
класифікуйте збій (підняття тунелю vs живучість vs трафік), витягніть правильні журнали і перевірте нудні основи
(UDP 500/4500, строки життя/rekey, сертифікати, MTU, маршрути, DNS).

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

• Зробіть двокомандний пакет підтримки: експортуйте RasClient + IKE operational події за вікном помилки.
• Запустіть тест, сфокусований на rekey: тримайте тунель підключеним через щонайменше два цикли rekey під реальним трафіком.
• Впровадьте план тестування MTU і встановіть відомий‑добрий MTU/MSS для вашого парку пристроїв.
• Прийміть канарне кільце для змін профілів VPN і сертифікатів. Це нудно. Працює.
• Ясно вирішіть, чи підтримуєте ви роумінг і ворожі мережі — і задокументуйте очікувану поведінку.

Мета — не VPN, що підключається у вашій лабораторії. Мета — VPN, що залишається підключеним у реальному світі, де NATи тайм‑аутяться,
Wi‑Fi брешуть і сертифікати закінчуються в найневдаліший момент.