IKEv2/IPsec: коли це кращий вибір, ніж WireGuard або OpenVPN

Рамки рішення: що ви насправді обираєте

«VPN» — це не одне рішення. Це набір рішень:

• Поверхня клієнта: Ви хочете рідний клієнт ОС з налаштуваннями через MDM, чи сторонній застосунок, який потрібно розгортати, оновлювати і налагоджувати?
• Модель ідентичності: Ви бажаєте сертифікати, EAP (RADIUS/AD‑підтримка), ідентичність пристрою, політики на рівні користувача та чисте відкликання? Або спільний ключ і надія?
• Толерантність до ворожості мережі: Чи переживете ви NAT, captive portal, carrier‑grade NAT і роумінг Wi‑Fi без флапів тунелів?
• Оперативна видимість: Чи можете ви зафіксувати, інтерпретувати й аудитувати, що сталося о 3:00 ранку?
• Екосистема вендорів: Чи входять у ваш стек фаєрволи, балансувальники і засоби ідентичності, які вже «говорять IPsec» вільно?

WireGuard виграє за простотою та продуктивністю. OpenVPN виграє за «працює скрізь і ми вже це знаємо». IKEv2/IPsec перемагає, коли вам важлива інтеграція з підприємством, стабільність при роумінгу, політика та передбачувана операційна відповідність.

Ось прямолінійний евристик, який я використовую в продакшені:

• Якщо ви будуєте зручний для розробників оверлей між відомими кінцевими точками і можете керувати ключами чисто — почніть з WireGuard.
• Якщо потрібна максимальна сумісність з дивними застарілими клієнтами та сторонніми середовищами — OpenVPN все ще виправдовує себе.
• Якщо вам потрібні рідні клієнти, конфігурація через MDM, сильна інтеграція ідентичності та тунелі, які переживають роумінг — обирайте IKEv2/IPsec і не вибачайтесь за це.

Факти та історія, які реально важливі в продакшені

Декілька контекстних пунктів, які впливають на те, чому IKEv2/IPsec поводиться так, як сьогодні — і чому це часто «за замовчуванням» для підприємств.

1. IKEv2 створили, щоб замінити складність і крихкість IKEv1 (менше обміну повідомленнями, чіткіша машина станів). Ви це відчуваєте при налагодженні: менше «фольклору фази 1/фази 2», більше структурованих переговорів.
2. MOBIKE (Mobility and Multihoming) — це повноцінна функція в IKEv2. Вона створена для клієнтів, які переміщаються між мережами без розриву тунелю.
3. Прохідність через NAT (NAT‑T) стандартизувала UDP‑инкапсуляцію для IPsec, зробивши його працездатним через більшість споживчих NATів. Це не ідеально, але й не тимчасовий ластик на боці.
4. Багато постачальників ОС постачали IKEv2 як «рідний VPN», а OpenVPN/WireGuard трактували як сторонні. Це змінює все в управлінні парком: розповсюдження політик, сховища сертифікатів і забезпечення безпеки.
5. IPsec укорінився в мережевому обладнанні (фаєрволи, маршрутизатори, SD‑WAN бокси). Навіть коли UI болісний, історія міжоперабельності зріла.
6. Криптографічна гнучкість — реальна операційна річ: стекі IPsec давно підтримують багато алгоритмів і переговорів, що корисно, коли комплаєнс змінюється швидше, ніж розгортання кінцевих точок.
7. IKEv2 підтримує EAP‑методи (наприклад, EAP‑TLS, EAP‑MSCHAPv2) для аутентифікації користувачів; саме тому він є основою в підприємствах з RADIUS.
8. Perfect Forward Secrecy (PFS) — нормальна поведінка у сучасних IPsec‑профілях, і аудитори люблять, що це явне і стандартизоване, а не «повірте нам».

Є цитата, яку я тримаю при собі, коли хтось пропонує «кмітливу» VPN‑схему:

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

Де IKEv2/IPsec перемагає WireGuard і OpenVPN

1) Рідні клієнти і керування політиками через MDM (недооцінена суперсила)

У реальному світі «розгортання VPN» означає: ноутбуки під управлінням MDM, смартфони під умовним доступом і команда безпеки, яка хоче перевірку стану та ідентифікацію на основі сертифікатів. Рідні клієнти IKEv2 вбудовані у Windows, macOS, iOS та багато збірок Android. Це важливо, бо:

• Ви можете штовхати профілі через MDM без розгортання стороннього клієнта.
• Ви можете використовувати сховища сертифікатів ОС і ключі, захищені keychain/TPM.
• Ви можете використовувати функції платформи, як‑от Always On VPN (Windows) з IKEv2.
• Ви зменшуєте кількість оновлень клієнтів і випадків «VPN‑застосунок зламався після оновлення ОС».

WireGuard маленький і чистий, але на керованих кінцевих точках ви все ще розгортаєте програмне забезпечення (або покладаєтесь на вбудовану підтримку, яка не універсальна). OpenVPN майже завжди означає розгортання клієнта і набору конфігурацій, а потім роки відповіді на питання «яку версію у цього користувача?».

2) Стабільність при роумінгу з MOBIKE

Якщо ви підтримуєте мобільних користувачів, ваш VPN має переживати: офісний Wi‑Fi → LTE, готельний Wi‑Fi → tethering, зміну IP‑адрес, NAT rebinding і мережі, які мовчки видаляють неактивні UDP‑відповіді. IKEv2 з MOBIKE створений саме для цього. Він може оновлювати кінцеві точки і підтримувати SA живим без повного переговору заново.

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

3) Моделі аутентифікації в підприємстві: EAP + RADIUS + сертифікати

Модель ідентичності WireGuard — це публічні ключі. Це перевага, а не недолік — поки вам не потрібна ідентичність користувача, членство в групах, MFA‑гачки і чисте вилучення доступу під час звільнення з роботи.

IKEv2 блискуче підходить, коли вам потрібно:

• EAP‑TLS (найсильніший: сертифікати з обох сторін, без паролів у мережі)
• Аутентифікація через RADIUS з централізованою політикою та обліком
• Доступ на рівні користувача/пристрою через атрибути, групи та профілі сертифікатів

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

4) Комплаєнс і аудиторський наратив

Деякі організації мають відповісти на питання: «Які набори шифрів дозволені?», «Чи ми примушуємо PFS?», «Чи можемо довести ідентичність пристрою?», «Чи логувати початок/кінець сесії і ідентичність користувача?»

IKEv2/IPsec зазвичай акуратно вкладається в аудиторські наративи, бо словник політик стандартизований, реалізації зрілі, а екосистема приладів/ОС дає логи і контролі конфігурації у вигляді, який аудитори впізнають.

5) Сумісність із site‑to‑site і наявним мережевим обладнанням

Якщо ви вже маєте site‑to‑site IPsec між офісами, додавання віддаленого доступу IKEv2 часто повторно використовує:

• той самий PKI,
• той самий набір постачальників фаєрволів,
• ті самі операційні рукописи,
• той самий базовий крипто‑політик.

WireGuard може прекрасно робити site‑to‑site, але якщо ваш периметр прив’язаний до приладів і контролю змін, IPsec часто — шлях найменшого організаційного опору. Це не «політика». Це виживання.

6) Трафік‑інженерія і QoS у мережах, яким це важливо

У більших мережах ви зрештою захочете маркувати трафік, формувати його і спостерігати без здогадів. Реалізації IPsec часто інтегруються з обробкою DSCP, політичною маршрутизацією і інструментами корпоративного QoS. WireGuard простіший, але не має того самого «набір ручок і панелей» у команді мережі.

Короткий жарт #1: IPsec — як швейцарський армейський ніж: корисний, шанований і якимось чином завжди не вистачає тієї єдиної речі о 2‑й ночі.

Коли не варто використовувати IKEv2/IPsec

IKEv2/IPsec не «завжди кращий». Воно кращає, коли ваші обмеження відповідають його сильним сторонам.

Не обирайте IKEv2/IPsec, якщо вам потрібна крайня простота

Якщо команда маленька і ви хочете VPN, який можна пояснити на дошці за п’ять хвилин — WireGuard ваш друг. IPsec має більше рухомих частин: пропозиції, трансформи, SAs, час життя, EAP, сертифікати, NAT‑T. Це керовано, але не мінімально.

Не обирайте його, якщо ви за мережами, що блокують UDP

Багато IPsec‑середовищ працюють через UDP 500/4500. Деякі мережі блокують або пошкоджують їх. OpenVPN поверх TCP/443 іноді може пройти там, де IPsec не проходить. Це не рекомендація по продуктивності — це рекомендація по реальності.

Не обирайте його, коли підтримка платформ нестабільна

Рідні клієнти чудові — поки потрібно підтримувати платформи з дивними реалізаціями IKEv2 або обмеженими EAP‑методами. Якщо ви підтримуєте спеціальні вбудовані пристрої, OpenVPN або WireGuard може бути легше стандартизувати.

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

IKEv2 з EAP‑TLS і сертифікатами — відмінно. Воно також потребує, щоб ви вели PKI серйозно: процеси видачі, відкликання, моніторингу термінів та планів ротації. Якщо ваша практика сертифікатів — «поставимо нагадування в календарі на наступний рік», вам буде погано.

Вибір архітектури: road warrior, site‑to‑site і «завжди увімкнено»

Віддалений доступ (road warrior) IKEv2

Це модель «користувачі підключаються звідусіль». Типові варіанти:

• Маршрутний VPN (переважно): призначити віртуальний IP клієнту, маршрутизувати мережі через тунель.
• Розділений тунель vs повний тунель: розділений зменшує навантаження та радіус ураження; повний тунель спрощує контроль безпеки, але збільшує залежність від доступності VPN.

З IKEv2 маршрутні налаштування зазвичай відчуваються операційно чистішими, ніж політично‑орієнтовані. Ви поменше будете налагоджувати «чому тільки ця підмережа ламається?».

Site‑to‑site IKEv2

Це класична територія IPsec. Якщо ваша організація вже має site‑to‑site тунелі, стандартизація на IKEv2 приносить послідовність і іноді кращу поведінку при відмовах.

У середовищах зі змішаними вендорами приділіть час сумісності пропозицій. Більшість «IPsec не працює» інцидентів — це фактично «несумісність пропозицій» з тонкою плівкою заперечення зверху.

Always‑on / тунель пристрою

IKEv2 часто лежить в основі «always‑on» корпоративних VPN‑стратегій, бо інтегрується з мережевими компонентами ОС під час завантаження і з ідентичністю пристрою. Це важливо для:

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

Аутентифікація та ідентичність: EAP, сертифікати, PSK і підводні міни

PSK: швидко, знайомо і зазвичай невірний дефолт

Pre‑shared keys привабливі, бо прості. Вони також створюють проблеми масштабу і безпеки у віддаленому доступі:

• Відкликання складне: ви змінюєте PSK і ламаєте всіх одразу.
• Розповсюдження стає проблемою обміну секретами.
• Аудит «хто використовував ключ» слабкий, якщо не додати інші механізми ідентифікації.

PSK підходить для строго контрольованих site‑to‑site тунелів з сильною операційною дисципліною. Для користувачів — використовуйте сертифікати і/або EAP.

EAP‑MS‑CHAPv2: працює, але ставте його як спадщину

EAP‑MS‑CHAPv2 поширений у корпоративних середовищах через інтеграцію з існуючими системами ідентичності. Але з точки зору безпеки це не золотий стандарт. Якщо можете — застосовуйте EAP‑TLS.

EAP‑TLS: опція «так, ми серйозно про безпеку»

EAP‑TLS дає сильну взаємну аутентифікацію за допомогою сертифікатів. Операційна перевага — чисте деопровізування: відкликай сертифікат — пристрій/користувач втратили доступ. Операційний ризик — управління життєвим циклом сертифікатів. Потрібно моніторити закінчення строків і автоматизувати оновлення де можливо.

Крипто‑пропозиції: стандартизуйте або страждайте

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

Короткий жарт #2: Найшвидший спосіб вивчити IPsec — неправильно налаштувати одну пропозицію; другий‑найшвидший — зробити це в продакшені.

Реальність операцій: моніторинг, налагодження та управління змінами

IKEv2/IPsec має репутацію «важко діагностувати». Частково це справедливо. Також багато команд намагаються запускати його без телеметрії. Не робіть цього.

Що моніторити

• Кількість підключень вгору/вниз та частота флапів по кожному ASN клієнта/типу мережі (шаблони Wi‑Fi vs мобільні швидко показують MTU і NAT‑проблеми).
• Відмови автентифікації, розбиті за причиною (сертифікат недійсний, помилка EAP, невідповідність пропозицій).
• Відкиди пакетів на UDP 500/4500 та ESP, особливо на фаєрволах/NAT‑пристроях.
• Базові показники затримки і пропускної здатності до відомих внутрішніх кінцевих точок.

Управління змінами: IPsec карає випадкові правки

WireGuard прощає: змінив peer, перезавантажив, готово. З IPsec зміни можуть розповсюджуватись:

• Зміни пропозицій вимагають згоди обох сторін.
• Зміни ланцюжка сертифікатів можуть ламати клієнтів, які кешували старий CA.
• Зміни поведінки NAT‑T можуть виявити фільтрацію шляхів.

Використовуйте поступові розгортання. Зберігайте відомі‑хороші профілі. Логуйте все. Ставте VPN як продакшн‑сервіс, а не як мережеву побічну задачу.

Практичні завдання з командами: що запускати, що це означає, що вирішувати

Нижче наведені конкретні завдання, які ви можете виконати на Linux‑шлюзі IKEv2/IPsec (припущено strongSwan) та навколишній інфраструктурі. Кожне завдання містить: команду, приклад виводу, як його читати і яке рішення прийняти.

Завдання 1: Підтвердити, що демон IKE здоровий

cr0x@server:~$ systemctl status strongswan-starter
● strongswan-starter.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
     Loaded: loaded (/lib/systemd/system/strongswan-starter.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 08:11:02 UTC; 2h 14min ago
   Main PID: 1187 (starter)
      Tasks: 18 (limit: 9381)
     Memory: 21.4M
     CGroup: /system.slice/strongswan-starter.service
             ├─1187 /usr/lib/ipsec/starter
             └─1214 /usr/lib/ipsec/charon

Значення: Якщо не active (running), припиніть налагодження мережі і почніть налагодження сервісу.

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

Завдання 2: Переглянути останні помилки переговору IKE

cr0x@server:~$ journalctl -u strongswan-starter -n 80 --no-pager
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] received AUTHENTICATION_FAILED notify error
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] EAP method EAP_MSCHAPV2 failed
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] IKE_SA vpn-ra[12] state change: AUTHENTICATING => DESTROYING
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] no proposal chosen
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] peer supports: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] configured: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Значення: Два окремі режими відмов: помилка EAP‑аутентифікації і невідповідність крипто‑пропозицій (no proposal chosen).

Рішення: Виправляйте проблеми ідентичності (RADIUS/EAP) окремо від політики шифрів. Не «відкривайте всі шифри» в паніці; узгодьте пропозиції явно.

Завдання 3: Перелік встановлених SA і лічильники трафіку

cr0x@server:~$ sudo swanctl --list-sas
vpn-ra: #14, ESTABLISHED, IKEv2, 8f3a1b9c1b2e3a2d_i* 21a9de88c0d3b1aa_r
  local  'vpn.example' @ 203.0.113.10[4500]
  remote 'user@corp' @ 198.51.100.77[51234]
  AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 612s ago, rekeying in 41m
  vpn-ra{27}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1b2a3d4_i c9d8e7f6_o
  vpn-ra{27}:   10.10.50.21/32 === 10.0.0.0/16
  vpn-ra{27}:   in  1483920 bytes, 1240 packets
  vpn-ra{27}:   out 932481 bytes, 1102 packets

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

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

Завдання 4: Перевірити, що слухають UDP 500/4500

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

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

Рішення: Немає слухача → виправляйте конфігурацію/адресу прив’язки демона перш ніж міняти фаєрволи нагору по ланцюжку.

Завдання 5: Перевірити правила фаєрвола для портів IPsec

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500 } accept
    ip protocol icmp accept
    tcp dport 22 accept
    counter drop
  }
}

Значення: UDP 500/4500 дозволені. Якщо політика — drop і цих правил немає, ваш VPN ззовні виглядатиме «мертвим».

Рішення: Якщо відсутні — додайте явні правила. Не тимчасово ставте політику accept; ви забудете скасувати зміни.

Завдання 6: Підтвердити пересилання IP в ядрі та rp_filter

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1

Значення: Пересилання увімкнено (добре). Але строгий reverse‑path filter (rp_filter=1) може скидати тунельний трафік в асиметричних маршрутах.

Рішення: Якщо у вас кілька uplinkів, політична маршрутизація або складнощі NAT‑T — розгляньте rp_filter=2 (loose) на відповідних інтерфейсах і валідуючі захоплення пакетів.

Завдання 7: Перевірити маршрути для пулів клієнтів VPN

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.0.0.0/16 via 10.0.1.1 dev eth1
10.10.50.0/24 dev vti0 proto kernel scope link src 10.10.50.1

Значення: Пул клієнтів на vti0. Якщо внутрішні мережі не знають, як повернути трафік в 10.10.50.0/24, клієнти підключаться, але не отримають відповіді.

Рішення: Забезпечте маршрути повернення в ваших внутрішніх маршрутизаторах, або виконуйте NAT (усвідомлюючи наслідки для аудиту/безпеки).

Завдання 8: Перевірити правила NAT при розділеному/повному тунелі

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.10.50.0/24 -o eth1 -j MASQUERADE

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

Рішення: Використовуйте NAT лише якщо не можете додати маршрути повернення. Якщо вам важливі аудиторські сліди по користувачах — маршрутуйте правильно і уникайте NAT.

Завдання 9: Підтвердити, що ESP‑в‑UDP (NAT‑T) пакети приходять

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:21:11.205931 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048a), length 148
10:21:11.306102 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f2), length 132
10:21:11.406245 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048b), length 148
10:21:11.506311 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f3), length 132
10:21:11.606478 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048c), length 148

Значення: Двонаправлений ESP‑в‑UDP трафік присутній. Якщо бачите вхідні, але не вихідні — підозрюйте еgress‑фаєрвол або маршрутизацію на шлюзі.

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

Завдання 10: Виявити проблеми MTU/фрагментації якомога раніше

cr0x@server:~$ ping -M do -s 1372 10.0.0.10 -c 3
PING 10.0.0.10 (10.0.0.10) 1372(1400) bytes of data.
1372 bytes from 10.0.0.10: icmp_seq=1 ttl=63 time=18.1 ms
1372 bytes from 10.0.0.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.0.0.10: icmp_seq=3 ttl=63 time=17.9 ms

--- 10.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Значення: Це тестує розмір корисного навантаження, який наближено відображає звичайні обмеження MTU після накладення IPsec‑заголовків. Якщо це падає, а менші pings працюють — у вас проблема MTU/PMTUD.

Рішення: Якщо тест не проходить — обмежте MSS (Завдання 11) або налаштуйте MTU інтерфейсу тунелю. Не звинувачуйте DNS зарані.

Завдання 11: Обмежити TCP MSS, щоб уникнути PMTUD‑чорної діри

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o vti0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 1
-A FORWARD -o vti0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: Обмеження MSS часто пом’якшує зламану фільтрацію ICMP і проблеми PMTUD, що проявляються як «сайти зависають, але пінг працює».

Рішення: Якщо додатки користувачів зависають при великих передаваннях — обмежте MSS і перетестуйте. Потім заплануйте коректне вирішення (дозвольте ICMP fragmentation‑needed, встановіть правильний MTU).

Завдання 12: Перевірити XFRM‑стан і політики в ядрі

cr0x@server:~$ sudo ip xfrm state
src 203.0.113.10 dst 198.51.100.77
  proto esp spi 0xc9d8e7f6 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0x3b... 128
  enc cbc(aes) 0x9f...
src 198.51.100.77 dst 203.0.113.10
  proto esp spi 0xc1b2a3d4 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xa1... 128
  enc cbc(aes) 0x11...

Значення: Ядро має активні ESP SA. Якщо charon каже «established», а XFRM‑стан відсутній — у вас розбіжність між контрольною і даною площиною.

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

Завдання 13: Перевірити невідповідність пропозицій зі сторони клієнта (захоплено на шлюзі)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 500 -vv -c 3
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)
IP 203.0.113.10.500 > 198.51.100.77.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload) notify(NO_PROPOSAL_CHOSEN)
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)

Значення: Шлюз відхилив пропозицію (NO_PROPOSAL_CHOSEN). Це не «мережа». Це невідповідність конфігурації.

Рішення: Узгодьте трансформи IKE/ESP. Уникайте широкого «включити все» у відповідь; визначте сумісну базу і дотримуйтеся її.

Завдання 14: Підтвердити DNS‑поведінку для клієнтів VPN (частий імпостор «VPN не працює»)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 5 (vti0)
      Current Scopes: DNS
           Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Значення: Інтерфейс тунелю має DNS‑сервери і пошуковий домен. Якщо клієнти можуть дістатися IP‑адрес, але не імен — неправильна роздача DNS або політика split‑DNS.

Рішення: Спочатку виправте роздачу DNS. Користувачам байдуже, що тунель «піднятий», якщо їхній браузер не може розв’язати внутрішні імена.

Завдання 15: Підтвердити доступність RADIUS і коди відповідей (коли використовується EAP)

cr0x@server:~$ sudo radtest alice 'CorrectHorseBatteryStaple' 10.0.0.20 0 testing123
Sent Access-Request Id 164 from 0.0.0.0:51682 to 10.0.0.20:1812 length 76
		User-Name = "alice"
		User-Password = "CorrectHorseBatteryStaple"
		NAS-IP-Address = 10.0.0.1
		NAS-Port = 0
		Message-Authenticator = 0x00
Received Access-Accept Id 164 from 10.0.0.20:1812 to 10.0.0.1:51682 length 44

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

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

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

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

По‑перше: це контрольна площина чи площина даних?

• Перевірка контрольної площини: Чи встановлені IKE SA? Використайте swanctl --list-sas. Якщо SA немає — ви в зоні автентифікації/пропозицій/фаєрвола.
• Перевірка площини даних: Якщо SA є — лічильники зростають? Якщо ні — ви в зоні маршрутизації/NAT/фаєрвола/XFRM.

По‑друге: доведіть, що пакети проходять через периметр

• Запустіть ss -lunp, щоб підтвердити слухачі UDP 500/4500.
• Запустіть tcpdump на WAN‑інтерфейсі для UDP 500/4500.
• Якщо вхідні є, але вихідні немає — перевіряйте локальний фаєрвол і маршрути; якщо немає ні тих, ні інших — перевіряйте апстрім‑фаєрвол/NAT.

По‑третє: полюйте на тихі вбивці (MTU, DNS, асиметрія)

• MTU: симптоми: «SSH працює, але сайти зависають», «великі завантаження зависають». Використовуйте DF‑ping тести і застосуйте MSS‑clamp як тимчасовий захід.
• DNS: «підключено, але нічого не працює» часто означає «підключено, але не резолвиться». Підтвердіть DNS‑сервери і поведінку split‑DNS.
• Асиметрична маршрутизація: трафік тунелю йде по одному інтерфейсу, а повертається по іншому і відкидається rp_filter або апстрім‑фаєрволами.

По‑четверте: перевірте, що продуктивність не через CPU/крипто

• Перегляньте навантаження CPU на шлюзі під навантаженням.
• Переконайтеся, що AES‑NI / апаратне прискорення крипто увімкнено, якщо застосовне.
• Перевірте, що ви не робите непотрібних шарів інкапсуляції (подвійний NAT, подвійний тунель).

Поширені помилки (симптом → корінь проблеми → виправлення)

1) «Підключено», але немає доступу до внутрішніх підмереж

Симптом: Клієнт показує підключено; внутрішні сервіси таймаутять; шлюз показує SA встановлені.

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

Виправлення: Додайте маршрути в внутрішніх маршрутизаторах для пулу клієнтів через VPN‑шлюз; перевірте через ip route і лічильники в swanctl --list-sas. NAT — лише як останній засіб.

2) Часті перепідключення при роумінгу (Wi‑Fi ↔ LTE)

Симптом: Тунель падає при зміні IP; користувачі скаржаться на мобільних мережах.

Корінь: MOBIKE відключено або не підтримується в профілі; проблеми з NAT rebinding; агресивні налаштування DPD.

Виправлення: Увімкніть MOBIKE, відрегулюйте DPD/keepalives, щоб зберегти NAT‑мапи, перевірте логи, що адреси оновлюються, а не відбувається повна реаутентифікація.

3) «No proposal chosen» після оновлення політики безпеки

Симптом: Миттєвий провал на IKE_SA_INIT; логи показують no proposal chosen.

Корінь: Сузіли політики на шлюзі і клієнтах — часто після відключення SHA1/старих груп DH без оновлення клієнтів.

Виправлення: Визначте матрицю сумісності по версіях ОС. Розгортайте зміни профілю клієнтів перед суворішою політикою сервера. Тримайте одну перехідну пропозицію тимчасово з датою видалення.

4) Працює в деяких мережах, не працює в готельному/гостьовому Wi‑Fi

Симптом: Користувачі підключаються з дому/мобільних, але не з певних Wi‑Fi.

Корінь: UDP 500/4500 блоковано або пошкоджено; captive portal заважає; симетричні NAT‑випадки.

Виправлення: Підтвердіть через tcpdump, чи приходять пакети. Якщо блоковано — розгляньте запасний шлях (іноді OpenVPN/TCP — практичний вихід) або розгорніть VPN‑шлюз у більш дозволеному для egress місці.

5) Повільна пропускна здатність після «загартування безпеки»

Симптом: Тунелі підключаються; пропускна здатність падає вдвічі; CPU на шлюзі підскакує.

Корінь: Обрані CPU‑витратні алгоритми або вимкнено апаратне прискорення; надмірні рефренки ключів.

Виправлення: Віддавайте перевагу сучасним AEAD‑суїтам як AES‑GCM; переконайтеся, що апаратне прискорення увімкнено; розумно збільшіть інтервали ре‑ключування.

6) Випадкові зависання при великих завантаженнях

Симптом: Дрібні пакети працюють; великі трансфери зависають; деякі програми працюють, інші — ні.

Корінь: MTU/PMTUD‑чорна діра — ICMP «fragmentation needed» блокується десь.

Виправлення: Обмежте MSS як тимчасову міру; потім виправте PMTUD, дозволивши ICMP і встановивши правильний MTU на інтерфейсах тунелів.

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

Симптом: Деякі користувачі можуть досягати обмежених мереж; інші не можуть отримати доступ, який їм потрібен.

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

Виправлення: Нормалізуйте відображення політик. Логуйте застосовані групи/ACL для кожної сесії. Ставте авторизацію VPN на рівні авторизації застосунків: явна, версіонована, переглядана.

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

Міні‑історія 1: Інцидент через хибне припущення

Вони мігрували віддалений доступ з застарілого пристрою на новий Linux‑шлюз з IKEv2. Пілотні користувачі були задоволені. Пропускна здатність — відмінна. Вікно змін закрилося оплесками і новим віджетом у дашборді.

Два дні потому хелпдеск отримав хвилю: «VPN підключається, але нічого не вантажиться». Не всі — лише користувачі в певному офісі і кілька на конкретних ISP. Статус тунелю виглядав нормально. SA були встановлені. Байти текли. Команда припустила «це DNS», бо це завжди DNS, поки не виявиться інше.

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

Коли хтось прослідив один потік наскрізь, картина стала ясною: SYN пакети доходили, SYN‑ACK йшли на дефолтний шлюз і там вмирали. Додали маршрути в ядрі мережі, перевірили на крайових маршрутизаторах і інцидент зник.

Урок не в тому, що «маршрутизація складна». Урок: знайте, чи ваш попередник вирішував проблему через NAT, і не видаляйте таку поведінку без заміни залежності.

Міні‑історія 2: Оптимізація, що обернулась проти

Інша компанія мала чисте розгортання IKEv2 з EAP‑TLS і керованими сертифікатами. Продуктивність була прийнятною, але хтось захотів більше. Хтось помітив спайки CPU на шлюзі і вирішив «оптимізувати» крипто‑настройки і таймери ре‑ключування.

Зміни були з добрими намірами: коротші часи життя для «кращої безпеки» і перемик на іншу пропозицію, яка виглядала сильнішою на папері. Ніхто не виміряв витрат CPU. Ніхто не перевірив, які алгоритми використовують апаратне прискорення. Зробили це в п’ятницю, бо «це лише конфіг».

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

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

Урок: крипто‑налаштування — це налаштування продуктивності. Змінюйте їх як індекси БД: з бенчмарками, поетапним розгортанням і планом відкату.

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

Одна організація тримала IKEv2 для віддаленого доступу і site‑to‑site з сертифікатами від внутрішнього CA. Нічого надзвичайного. Магія була в нудних речах: вони відстежували терміни сертифікатів, мали алерти і автоматизоване оновлення на керованих пристроях.

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

У них цього не було. Вони мали задокументований план розгортання ланцюга довіри: спочатку штовхати новий root/intermediate на кінцеві точки, перевіряти довіру через MDM‑комплаєнс, потім оновляти шлюзи, щоб презентувати новий ланцюг. Після того, як телеметрія показала, що більшість пристроїв довіряють новому CA — відкликали старий intermediate.

Ротація пройшла з мінімальним шумом. Без простоїв. Без масової повторної реєстрації. Найкращий комплімент — тиша від хелпдеску.

Урок: управління життєвим циклом сертифікатів — це не паперова робота; це інженерія доступності.

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

Вибір IKEv2/IPsec (контрольний список для рішення)

1. Чи потрібні вам рідні клієнти і конфігурація через MDM? Якщо так — схиліться в бік IKEv2.
2. Чи потрібна ідентичність на рівні користувача з централізованою політикою (RADIUS/AD) і хорошими аудиторськими слідами? Якщо так — IKEv2.
3. Чи у вас роумінгова‑важка робоча сила і ви хочете стабільні тунелі при змінах мережі? Якщо так — вимагайте MOBIKE і тестуйте його.
4. Чи ваше середовище ворожне до UDP 500/4500? Якщо так — плануйте запасну стратегію (або перегляньте вибір протоколу).
5. Чи можете ви управляти PKI дисципліновано (видача, оновлення, відкликання, алерти про строки)? Якщо ні — виправте це спочатку або оберіть модель, що відповідає реальності.

План розгортання в продакшн (покроково)

1. Визначте матрицю сумісності: підтримувані версії ОС, EAP‑методи, набори шифрів і часи життя.
2. Оберіть ідентичність: EAP‑TLS якщо можливо; інакше EAP через RADIUS з MFA. Уникайте PSK для VPN користувачів.
3. Побудуйте еталонний шлюз: увімкніть логування, експортуйте метрики, контроль доступу до захоплень пакетів.
4. Реалізуйте маршрутизацію свідомо: вирішіть routed vs NATed трафік клієнтів і документуйте маршрути повернення.
5. План MTU: встановіть MTU тунелю, дозволіть ICMP fragmentation‑needed і додавайте MSS‑clamp тільки як тимчасовий захід.
6. Поетапне розгортання клієнтів: внутрішній пілот, потім один відділ, потім широке розгортання. Тримайте старий VPN, поки показник флапів стабільний.
7. Chaos‑тестування (легке): роумінг між Wi‑Fi і LTE, suspend/resume ноутбуків, тест captive portal мереж.
8. Runbooks: задокументуйте ваш Швидкий план діагностики і хто відповідає за який шар (мережа/безпека/endpoint).
9. Дриль ротації: відрепетируйте оновлення сертифікатів і відкат конфігурації шлюзу.

Day‑2 операційний чекліст

1. Моніторити флапи тунелів, відмови автентифікації і успішність підключення по користувачах.
2. Алертувати про закінчення термінів сертифікатів (шлюз і клієнтські CA).
3. Щоквартально переглядати крипто‑політику та можливості клієнтів (щоб уникнути «no proposal chosen» в сюрприз).
4. Тестувати з принаймні двох ворожих мереж (гостьовий Wi‑Fi, мобільний хот‑спот) для виявлення фільтрації egress.
5. Тримати один відомо‑робочий клієнтський профіль у сховищі (на відновлення).

ЧаПи

Чи є IKEv2/IPsec «більш безпечним» за WireGuard?

Не автоматично. WireGuard має меншу площу атаки і сучасний набір крипто. IKEv2/IPsec може бути надзвичайно безпечним при правильній конфігурації. Справжній відмінник часто — це інтеграція ідентичності та політик, а не сире криптографічне порівняння.

Чому IKEv2 здається більш надійним для корпоративних ноутбуків?

Тому що ОС володіє стеком клієнта: він інтегрований зі сховищами сертифікатів, переходами мереж і політиками управління пристроєм. Менше сторонніх компонентів — менше дивних поломок після оновлень ОС.

Яка одна найкраща причина обрати IKEv2 замість OpenVPN?

Рідна підтримка клієнтів плюс корпоративні моделі аутентифікації (EAP/RADIUS/сертифікати) з передбачуваним контролем політики. OpenVPN робить багато чого, але ви платите «податок на управління клієнтом».

Яка одна найкраща причина обрати IKEv2 замість WireGuard?

Коли вам потрібна ідентичність користувача/пристрою та централізована політика, яка інтегрується в корпоративні IAM‑потоки, плюс комфорт стандартної взаємодії IPsec з існуючим обладнанням.

Чи варто використовувати PSK для віддаленого доступу IKEv2?

Загалом ні. PSK важко безпечно ротувати в масштабі і він поганий для аудиту на рівні користувача. Використовуйте EAP‑TLS або EAP через RADIUS з MFA.

Чи потрібно дозволяти ESP (IP протокол 50) через фаєрвол?

Не обов’язково. Багато розгортань покладаються на NAT‑T (UDP 4500), яке інкапсулює ESP в UDP. Якщо ви контролюєте обидві сторони і уникаєте NAT, може використовуватись нативний ESP, але практичний шлях — UDP 4500.

Чому я бачу «no proposal chosen» і як це зупинити?

Це означає, що клієнт і сервер не можуть узгодити алгоритми і параметри IKE/ESP. Виправте, стандартизувавши суїти і розгорнувши клієнтські профілі перед посиленням політики сервера.

Тунель піднятий, але веб‑додатки зависають — яка ймовірна причина?

MTU/PMTUD‑чорні діри. Великі пакети відкидаються мовчки. Перевірте DF‑ping і пом’якшіть проблему обмеженням MSS, поки не виправите ICMP/MTU.

Чи підходить IKEv2 для одночасного site‑to‑site і віддаленого доступу?

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

Що логувати для комплаєнсу, не захлинувшись в шумі?

Логуйте події аутентифікації (успіх/помилка з причиною), призначені віртуальні IP, ідентифікатори застосованих політик/ACL і початок/кінець сесій. Уникайте повних логів пакетів, крім випадків інцидентів.

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

Якщо ви обираєте між IKEv2/IPsec, WireGuard і OpenVPN — припиніть сперечатися в абстрактах. Приймайте рішення з огляду на ті обмеження, які створюють простої:

1. Інвентаризуйте клієнтів (версії ОС, стан управління, шаблони роумінгу). Якщо потрібні рідні клієнти + MDM — IKEv2 виходить на передній план.
2. Оберіть модель ідентичності, якою зможете керувати роками. Якщо можете запустити EAP‑TLS з нормальною гігієною PKI — робіть це.
3. Визначте та опублікуйте крипто‑суїти і тримайте їх навмисно нудними. Потім тестуйте на всіх підтримуваних платформах.
4. Вирішіть заздалегідь routed vs NATed для віддаленого доступу, документуйте маршрути повернення і не змінюйте випадково історію безпеки/аудиту.
5. Прийміть Швидкий план діагностики як вашу оперативну пам’ять: контрольна площина vs площина даних, доведення периметра, потім MTU/DNS/асиметрія.

Обирайте протокол, який ви зможете експлуатувати чисто. Найкращий VPN — той, який не перетворює вашу мережеву команду на частинучасових детективів.