IPsec/IKEv2: пастка NAT‑Traversal, яка ламає VPN «сайт‑до‑сайту»

NAT‑T в одному реченні (і чому це боляче)

NAT traversal дозволяє IPsec працювати, коли будь-яка сторона знаходиться за NAT, інкапсулюючи ESP всередині UDP/4500, але найменша невідповідність у виявленні, портах, таймерах або фільтруванні перетворює «безпечний транспорт» на «безпечну тишу».

Ось основний біль: чистий IPsec ESP (protocol 50) не дружній до NAT, бо NAT потребує портів транспортного рівня, щоб відстежувати потоки. ESP їх не має. NAT‑T вирішує це, загортаючи ESP у UDP, даючи NAT те, на чому він може «ключуватись» (src/dst IP + src/dst port). Обгортка проста. Екосистема навколо — ні.

Коли NAT‑T ламається, воно зазвичай ламається так, що марнує ваш час:

• IKE SA піднімається (UDP/500 працює), але CHILD SA передають нуль байтів.
• Працює деякий час, а потім помирає після періоду простою (вичерпання NAT‑відображення).
• Падає лише в одному напрямку (асиметричне фільтрування, маршрутизація або невідповідність політик).
• Падає лише при великому трафіку (PMTUD/фрагментація/проблеми MTU).

Корисне правило: якщо бачите «тунель вгору, трафік відсутній», зупиніть розгляд криптопропозицій і почніть перевіряти NAT‑T і досяжність data‑plane.

Жарт №1: NAT як кішка: ігнорує стандарти, робить, що хоче, а ви все одно маєте його підтримувати.

Що фактично відбувається «по дроту»: IKEv2 + виявлення NAT + UDP інкапсуляція

Фази IKEv2, які важливі для NAT‑T

IKEv2 простіший, ніж IKEv1, але NAT‑складові й далі тонкі. Загальний потік:

1. IKE_SA_INIT: погоджує алгоритми, виконує Diffie‑Hellman, обмінюється nonces і виконує виявлення NAT.
2. IKE_AUTH: автентифікує пірів (PSK/сертифікати), встановлює IKE SA і створює перші CHILD SA(и).
3. Рекі ін CHILD SA: періодичне оновлення data‑plane SA.

Виявлення NAT здійснюється через NAT‑D payloads. Кожна сторона хешує те, що вона вважає 4‑туплом (адреси і порти). Якщо хеші не збігаються з тим, що бачить peer, сторони роблять висновок, що NAT на шляху й перемикаються на поведінку NAT‑T.

Порти: UDP/500, UDP/4500 і те, що люди забувають

Базово IKEv2 використовує UDP/500. Якщо виявлено NAT, тунель зазвичай переходить на UDP/4500 для IKE і для інкапсульованого ESP. Це означає:

• UDP/500 має працювати (принаймні для початкового узгодження).
• UDP/4500 має працювати для поточних IKE‑повідомлень і для data‑plane, коли використовується NAT‑T.
• Деякі пристрої починають на UDP/500, виявляють NAT, а потім продовжують на UDP/4500. Якщо ваш фаєрвол дозволяє 500, але не 4500, ви отримуєте класичну ситуацію «хендшейк начебто нормальний, трафік мертвий».

ESP vs NAT‑T інкапсуляція

Без NAT‑T data‑plane — це ESP (IP protocol 50). З NAT‑T data‑plane стає UDP/4500, що несе ESP. Це змінює те, що бачать проміжні пристрої:

• Станні фаєрволи тепер потребують UDP‑стану для потоку.
• Таймери conntrack тепер мають значення (UDP — «безстанний», але stateful NAT робить інакше).
• Деякі засоби безпеки погано інспектують UDP/4500 або агресивно його лімітують.

Тихий вбивця: таймери NAT‑відображень і keepalive

NAT швидко забувають UDP‑відображення. Тридцять секунд — поширений випадок. Деякі ще коротші під навантаженням. IPsec‑тунелі тим часом можуть лежати в простій хвилинами — особливо резервні чи «тільки для адміністрування» site‑to‑site лінки. Результат: відображення випаровується, peer продовжує шифрувати UDP/4500 пакети в порожнечу, і ніхто вам не каже, поки не з’явиться новий трафік.

Виправлення зазвичай — keepalive або налаштування DPD/heartbeat. Не «зміцнюйте крипто». Не «переключайтесь на рекій кожні 5 хвилин». Тримайте NAT‑відображення живим або прийміть, що перший пакет після простою буде втрачено.

Чому фрагментація і MTU проявляються частіше з NAT‑T

NAT‑T додає UDP‑зовнішню накладну плату. IPsec додає ESP‑накладну плату. Якщо ви вже були впритул до MTU (MPLS, PPPoE, GRE, cloud VNets тощо), NAT‑T штовхає вас через межу.

Коли PMTUD заблоковано (ICMP фільтрується), великі пакети зникають. Малі ping’и працюють. SSH працює. Файлові передачі зависають. Бази даних гальмують при навантаженні. Саме тому «в мене пінгується» часто означає «я тестував лише 56 байтів».

Жарт №2: Єдине, що більш оптимістично, ніж «пінгується», — це «пінгується, отже це не мережа».

Цитата про надійність, бо ops має докази

Hope is not a strategy. — Gen. Gordon R. Sullivan

В термінах VPN: не надійтеся, що NAT‑T в порядку, бо тунель показує ESTABLISHED. Вимірюйте data‑plane.

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

Це порядок, який швидко знаходить реальні відмови. Він зумовлений тим, що найчастіше ламається в продакшні: фільтрування, стан NAT, маршрути/політики та MTU.

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

• Чи IKE на UDP/500 лише, або він переключився на UDP/4500?
• Чи data‑plane — ESP (proto 50), чи інкапсульований UDP/4500?

Якщо ви цього не знаєте, ви шукаєте в темряві. «Allow IPsec» — це не правило фаєрвола; це маркетингова фраза.

По‑друге: доведіть двосторонню досяжність UDP/4500 (не лише «відкрито»)

• Захоплення пакетів на обох пірів, дивлячись на вихідні та вхідні UDP/4500 пакети.
• Перевірте, що NAT‑пристрій підтримує відображення достатньо довго (таймери/keepalive).

По‑третє: підтвердьте селектори/політики та маршрути для захищених підмереж

• Чи збігаються traffic selectors (локальні/віддалені підмережі) на обох кінцях?
• Чи існує маршрут, що спрямовує захищені підмережі в інтерфейс/політику тунелю?
• Чи випадково не виконується NAT для трафіку, що має бути зашифрований?

По‑четверте: якщо «частина трафіку працює», йдіть прямо до MTU/MSS і фрагментації

• Тестуйте з DF встановленим і великими розмірами корисного навантаження.
• Шукайте ICMP «fragmentation needed», що блокується.
• При потребі клацніть MSS для TCP.

По‑п’яте: лише потім копайтесь у криптопропозиціях і таймерах рекі

Так, невідповідності пропозицій трапляються. Але помилки NAT‑T часто виникають після узгодження і виглядають як «крипто в порядку, data мертва». Розглядайте симптоми чесно.

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

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

Завдання 1: Підтвердити IKEv2 SA і чи використовується NAT‑T (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
IKE SAs:
corp-vpn[3]: ESTABLISHED 12 minutes ago, 203.0.113.10[gw-a]...198.51.100.20[gw-b]
corp-vpn[3]: IKEv2, rekeying in 46 minutes
corp-vpn[3]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
corp-vpn{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c3b8a9d2_i c9b6a331_o
corp-vpn{7}:  10.10.0.0/16 === 10.20.0.0/16

Що це означає: «ESP in UDP» підтверджує інкапсуляцію NAT‑T по UDP/4500 для data‑plane.

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

Завдання 2: Перевірити повідомлення в логах про виявлення NAT (strongSwan/charon)

cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | egrep -i "NAT|4500|encap|DPD" | tail -n 20
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] local host is behind NAT, sending keep alives
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] remote host is behind NAT
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] switching to NAT-T
Feb 04 09:12:41 gw-a charon[1123]: 11[IKE] sending keep alive to 198.51.100.20[4500]

Що це означає: NAT виявлено; демон перейшов на NAT‑T і відправляє keepalives.

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

Завдання 3: Перевірити локальні прослуховувані сокети (демон зв’язаний правильно?)

cr0x@server:~$ sudo ss -ulnp | egrep ':500|:4500'
UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=10))
UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=11))

Що це означає: IKE‑демон слухає на UDP/500 і UDP/4500.

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

Завдання 4: Перевірити правила фаєрвола для UDP/500 та UDP/4500 (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '/table inet filter/,/}/p' | egrep -n "udp dport (500|4500)|ip protocol esp|drop"
24: udp dport { 500, 4500 } accept
31: ip protocol esp accept
78: counter drop

Що це означає: Цей хост‑фаєрвол дозволяє IKE і NAT‑T, плюс raw ESP. Добре.

Рішення: Якщо ви бачите UDP/500 дозволений, але не UDP/4500, додайте 4500. Якщо бачите лічильники drop, захопіть трафік і уточніть правила.

Завдання 5: Підтвердити, що пакети приходять на UDP/4500 (tcpdump)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:14:02.112233 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 92
09:14:12.112998 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 92
09:14:22.113554 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 300

Що це означає: Існує двосторонній UDP/4500 трафік. Принаймні транспортний шлях живий.

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

Завдання 6: Підтвердити, що захищений трафік шифрується (XFRM state)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0xc9b6a331 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 256 bits
	anti-replay context: seq 0x0000002a, oseq 0x0
	lifetime current: 780s, bytes 12480, packets 104
src 198.51.100.20 dst 203.0.113.10
	proto esp spi 0xc3b8a9d2 reqid 1 mode tunnel
	lifetime current: 780s, bytes 9800, packets 91

Що це означає: Лічильники пакетів і байтів зростають. Шифрування відбувається в ядрі.

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

Завдання 7: Перевірити селектори політик (XFRM policy)

cr0x@server:~$ sudo ip xfrm policy
src 10.10.0.0/16 dst 10.20.0.0/16
	dir out priority 3750 ptype main
	tmpl src 203.0.113.10 dst 198.51.100.20 proto esp reqid 1 mode tunnel
src 10.20.0.0/16 dst 10.10.0.0/16
	dir in priority 3750 ptype main
	tmpl src 198.51.100.20 dst 203.0.113.10 proto esp reqid 1 mode tunnel

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

Рішення: Якщо ваші реальні мережі /24, а політика /16 (або навпаки), ви отримаєте дивні часткові відмови. Виправте селектори, щоб вони відповідали реальним маршрутам і області шифрування.

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

cr0x@server:~$ ip route get 10.20.5.10 from 10.10.5.10
10.20.5.10 from 10.10.5.10 dev eth0  src 203.0.113.10  uid 0
    cache

Що це означає: У політично основному IPsec трафік часто все одно маршрутизується «звично» (наприклад, через eth0) і підбирається XFRM‑політикою. Це нормально.

Рішення: Якщо маршрут вказує кудись несподівано (неправильний egress, невірний вихідний IP), виправте маршрути/вибір джерела. Невірний вихідний IP може зламати виявлення NAT і матч селекторів.

Завдання 9: Згенерувати трафік і дивитися, як рухаються лічильники (ping + XFRM)

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

--- 10.20.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.9/22.1/22.3/0.2 ms

Що це означає: Data‑plane працює для малих пакетів.

Рішення: Негайно протестуйте MTU з DF і більшими розмірами. «Малий ping працює» — це не успіх; це пастка.

Завдання 10: Тест MTU/фрагментації з DF встановленим

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 1372(1400) bytes of data.
ping: local error: message too long, mtu=1392

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

Що це означає: Ефективний path MTU менший, ніж очікувалося (тут 1392). IPsec/NAT‑T накладні зменшили його. Якщо ICMP блокується далі, ви можете бачити мовчазні відкидання замість локальної помилки.

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

Завдання 11: Перевірити правила TCP MSS (приклад iptables)

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

Що це означає: MSS‑clamping увімкнений на переадресованих TCP SYN пакетах.

Рішення: Якщо у вас MTU‑чорні діри і ви не можете виправити ICMP, додайте MSS‑clamping на шлюзі і повторно протестуйте передачі файлів та TLS‑handshakes.

Завдання 12: Підтвердити, що NAT не застосовується до захищених підмереж (iptables NAT table)

cr0x@server:~$ sudo iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE

Що це означає: Це буде NAT‑ити весь трафік з 10.10.0.0/16, що виходить через eth0, включно з трафіком, який має бути зашифрований до 10.20.0.0/16.

Рішення: Додайте виняток для NAT для призначення VPN перед MASQUERADE, або звужте правило MASQUERADE так, щоб виключити віддалену захищену підмережу.

Завдання 13: Інспект conntrack таймаути для UDP/4500

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Що це означає: UDP‑«з’єднання» йде швидко в таймаут (30s для невідповідних потоків). Це може вбити idle NAT‑T тунелі, якщо keepalive занадто рідкісні.

Рішення: Краще налаштувати IKE keepalives/DPD; регулювання conntrack‑таймаутів може допомогти, але вплине на весь хост і може мати непередбачувані наслідки.

Завдання 14: Перевірити, щоб налаштування rekey/DPD не викликали самостійних флапів (strongSwan status)

cr0x@server:~$ sudo swanctl --list-conns | sed -n '/corp-vpn/,/}/p'
corp-vpn: IKEv2, dpd_delay=30s, dpd_timeout=120s, rekey_time=1h
  local:  203.0.113.10
  remote: 198.51.100.20
  local_ts: 10.10.0.0/16
  remote_ts: 10.20.0.0/16

Що це означає: DPD налаштовано. Інтервал рекі — розумний.

Рішення: Якщо бачите надто агресивний DPD (наприклад, delay 5s, timeout 15s) на шумному WAN, ви будете самі флапати тунель. Підганяйте під реальний лінк.

Завдання 15: Доведіть, чи UDP/4500 блокується вище по ланцюжку (nmap UDP scan з обережністю)

cr0x@server:~$ sudo nmap -sU -p 500,4500 198.51.100.20
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-04 09:22 UTC
Nmap scan report for 198.51.100.20
Host is up (0.021s latency).

PORT     STATE         SERVICE
500/udp  open|filtered isakmp
4500/udp open|filtered nat-t-ike

Nmap done: 1 IP address (1 host up) scanned in 2.49 seconds

Що це означає: Результати UDP‑скану неоднозначні («open|filtered» — поширене явище). Це не доводить, що порт відкритий, але каже, що хост досяжний і не відправляє ICMP port‑unreachable.

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

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

1) «IKE SA встановлено, але трафік не проходить»

Симптом: Контрольна площина піднімається. Лічильники data‑plane лишаються нульовими.

Корінь проблеми: UDP/4500 заблокований (або ESP заблокований, коли NAT‑T вимкнено). Або селектори не співпадають, тож пакети не доходять до XFRM.

Виправлення: Підтвердьте «ESP in UDP» (або ні) у виводі SA, потім дозвольте UDP/4500 двосторонньо. Перевірте XFRM‑селектори відповідно до реальних підмереж і що є винятки NAT.

2) «Працює деякий час, потім вмирає після простою»

Симптом: Після 5–30 хвилин бездіяльності перший новий потік таймаутиться; тунель може потім відновитись.

Корінь проблеми: Вичерпання NAT‑відображення для UDP/4500; keepalive/DPD занадто повільні; upstream UDP‑стан таймаутиться.

Виправлення: Увімкніть NAT keepalive / IKEv2 liveness checks, налаштуйте їх частіше, ніж найкоротший NAT‑таймаут на шляху. Якщо не знаєте таймаут, проектуйте під 20–30 секунд.

3) «Один напрямок працює, інший — ні»

Симптом: Сайт A може дістати Site B, але не навпаки (або працюють лише деякі підмережі).

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

Виправлення: Порівняйте traffic selectors на обох кінцях; перевірте таблиці маршрутів; переконайтесь у відсутності перекриттів; перевірте правила фаєрвола в обох напрямках; підтвердьте інкапсуляцію і захоплення tcpdump на обох кінцях.

4) «Ping працює, SMB/HTTPS/передачі файлів зависають»

Симптом: Малі пакети проходять; великі пакети застрягають або скидаються.

Корінь проблеми: MTU‑чорна діра через IPsec + NAT‑T; PMTUD зламаний; ICMP фільтрується; NAT неправильно обробляє фрагментацію.

Виправлення: Тестуйте з DF, клацайте MSS і/або встановіть менший MTU на відповідних інтерфейсах. Також дозвольте необхідні типи ICMP, якщо ваша безпекова політика це дозволяє.

5) «Тунель флапає під час рекі, особливо за NAT»

Симптом: Періодичні відключення, що збігаються з таймерами рекі; логи показують ретрансміти і зміну CHILD SA.

Корінь проблеми: Колізії рекі, нестабільність NAT, жорстке pinholing фаєрвола або агресивний DPD, що взаємодіє з транзитною втратою пакетів.

Виправлення: Зсунути таймери рекі, уникати надто коротких термінів життя, налаштувати DPD і переконатися, що UDP/4500 не підлягає rate‑limit або коротким conntrack‑таймаутам.

6) «Все ламається після зміни ISP/modem/router»

Симптом: Ті самі конфіги, новий доступний пристрій — NAT‑T тепер не працює.

Корінь проблеми: Новий пристрій робить symmetric NAT, зміни в поведінці збереження портів або «оптимізує» UDP агресивно. Деякі також блокують UDP/4500 за замовчуванням.

Виправлення: Розмістіть VPN‑шлюз на публічній IP або у режимі bridge; інакше налаштуйте keepalives і перевірте пропуск UDP/4500 явно.

7) «Cloud VPN каже connected; on‑prem не бачить inbound»

Симптом: Хмара щаслива; on‑prem показує IKE вгору; inbound data‑plane відсутній.

Корінь проблеми: On‑prem edge дозволяє вихідні, але не вхідні UDP/4500; або NAT не зберігає порти; або security group неповні.

Виправлення: Перевірте симетричні правила з обох сторін. Зробіть захоплення на WAN‑інтерфейсі on‑prem, щоб довести, чи доходять інкапсульовані пакети.

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

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

У них був site‑to‑site VPN між невеликим офісом і центральним DC. Він працював роками. Потім офіс переїхав на інший поверх і отримав «просте» оновлення мережі: новий канал ISP, новий edge‑фаєрвол і акуратний VLAN‑редизайн, який зробив діаграми підручниковими.

У понеділок тунель піднявся. Моніторинг бачив IKE встановленим і оголосив перемогу. Але ERP‑трафік був мертвий. Першою реакцією вендора було звичне: «Схоже на ваш фаєрвол». Першою реакцією мережевої команди було теж звичне: «Тунель вгору, то це не ми». Ця патова ситуація з’їла півдня.

Неправильне припущення було тонким: вони вважали, що оскільки UDP/500 дозволено і IKE узгодився, NAT‑T «просто запрацює». На новому фаєрволі UDP/4500 не був дозволений вхідний за замовчуванням. Пристрій дозволяв вихідні. Отже офіс міг ініціювати, а DC не міг надійно відправляти назад інкапсульований трафік після рекі та періодів простою.

Що це виправило — не героїка, а два захоплення пакетів і одна неприємна зустріч. tcpdump на WAN офісу показав вихідні UDP/4500. Захоплення на DC‑edge показало нічого, що приходить. Коли є такі докази, дискусія закінчується. Додали симетричні правила для UDP/4500, увімкнули keepalives на шлюзі офісу — і тунель перестав брехати.

Міні‑історія 2: «Оптимізація», що відбилася назад

Інша компанія мала глобальний mesh VPN, і хтось вирішив «зменшити шум». Побачили періодичні NAT keepalive і DPD‑запити і вирішили подовжити таймери — менше трафіку, менше CPU, менше логів. Звучало відповідально. Також це зламало реальність.

Їхні edge NAT‑пристрої, особливо в маленьких офісах, мали агресивні UDP‑таймаути. З довшими інтервалами keepalive відображення NAT вимерли під час тихих періодів. Наступна хвиля бізнес‑трафіку впиралася в мертве відображення. Віддалений peer ретрансував. DPD зрештою оголошував peer мертвим. Таймінги рекі зрушували. З боку додатку це виглядало як випадкові 30–90‑секундні відключення кілька разів на день.

Оскільки тунель часто самостійно відновлювався, перша інстинктивна думка була звинуватити ISP або «хмару». Але захоплення показали, що віддалений шлюз сумлінно відправляв UDP/4500 пакети на адресу/порт, які NAT більше не форвардив. Зовні нічого не «впало». Стан зник.

Виправлення — відкликати оптимізацію і погодитися на трохи шуму keepalive як ціну роботи за NAT. Також встановили політику: якщо міняти таймери liveness, потрібно валідувати їх відносно найкоротшого NAT‑таймауту у флоті, а не найкращого. Нудний тунель став надійним. В опсах — нудне це функція.

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

Фінансова організація мала суворий change control і дратівну звичку: кожна зміна мережі вимагала pre‑change і post‑change capture для критичних лінків. Інженери бурчали. Ніхто не любить театру процесів. Але цей театр виявився тим самим театром, в якому ви ловите лиходія до третього акту.

Планували апгрейд фаєрвола на віддаленому сайті. До зміни зняли 60‑секундний pcap на WAN‑інтерфейсі і прикріпили його до запису зміни. Після апгрейду тунель піднявся — але call‑center додаток почав падати на великі відповіді. Малі тести проходили. Вендор казав «не ми». Апп‑команда казала «мережа». Ви знаєте цей рефрен.

Оскільки у них були before/after pcap, вони змогли порівняти. Після‑запис показав UDP/4500 пакети більші, ніж до того, і показав зміну у поводженні з фрагментацією. Новий фаєрвол агресивніше скидaв IP‑фрагменти на WAN‑стороні. Це не була проблема IKE; це була проблема data‑plane.

Виправлення було теж нудне: клацнули TCP MSS і підлаштували MTU інтерфейсу, щоб врахувати накладні IPsec/NAT‑T. Тунель не просто відновився — він припинив генерувати дивні випадкові відмови. Процес, який всі висміювали, дав найкоротший звіт про відмову за квартал.

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

Побудуйте правильно (новий site‑to‑site за NAT)

1. Визначте модель: Якщо можете уникнути NAT — уникайте. По можливості розмістіть хоча б один peer на стабільній публічній IP.
2. Відкрийте потрібний трафік: Дозвольте UDP/500 і UDP/4500 двосторонньо. Якщо іноді запускаєте без NAT‑T, також дозволіть ESP (IP proto 50). Будьте явними.
3. Виберіть розумні lifetimes: Не рекі кожні кілька хвилин, якщо не любите пейджинг.
4. Увімкніть liveness: Налаштуйте DPD і NAT keepalives. Підлаштуйте під найгірший NAT‑таймаут, який ви очікуєте, а не під найкращий.
5. Плануйте MTU: Припускайте накладні. Перевіряйте з DF. Впроваджуйте MSS‑clamping, якщо не контролюєте ICMP енд‑ту‑енд.
6. Запишіть селектори: Локальні/віддалені підмережі і перевірте, що вони не перекриваються з іншими сайтами.
7. Впровадьте винятки NAT: Трафік до VPN не має NAT‑итись перед шифруванням.
8. Додайте моніторинг data‑plane: Не лише «тунель вгору». Вимірюйте успішні потоки, лічильники байтів і затримки/джиттер.

Змінюйте без зламання (апгрейди фаєрвола, заміни ISP, зміни підмереж)

1. Зніміть захоплення UDP/500 і UDP/4500 до зміни (30–60 секунд у робочому трафіку).
2. Зафіксуйте поточний стан SA, селектори і налаштування MTU/MSS.
3. Після зміни спочатку підтвердьте прослуховувані порти і правила фаєрвола.
4. Перетестуйте малим ping і DF‑ping.
5. Перевірте, що XFRM‑лічильники або еквівалентні вендор‑лічильники зростають, коли ви генеруєте трафік.
6. Лише потім регулюйте таймери/пропозиції, якщо узгодження не вдається.

Коли все горить (чекліст інциденту)

1. Чи відбувається узгодження на UDP/500? Чи відбувається перемикання на UDP/4500?
2. Чи бачать обидві сторони вхідні UDP/4500 у capture?
3. Чи зростають байт‑лічильники на SA?
4. Чи селектори співпадають з реальними підмережами? Чи є перекриття?
5. Чи є NAT‑виняток? Чи з’явилися нові правила MASQUERADE?
6. Чи проходять великі DF‑пінги? Якщо ні — клацніть MSS зараз і заплануйте глибшу роботу по MTU.
7. Перевірте недавні зміни ISP/CPE, що могли ввести подвійний NAT або нове фільтрування.

Цікаві факти та історія, якими можна оперувати

• NAT не був частиною початкового дизайну IP. Він став популярним у 1990‑х як прагматична відповідь на виснаження IPv4 та політику адресації.
• Класичний IPsec ESP не має портів. NAT‑пристрої зазвичай відстежують потоки за портами, тому ESP (IP protocol 50) за своєю суттю ворожий до NAT.
• NAT‑T стандартизувало підхід «ESP у UDP». Основна ідея проста: загорнути ESP, щоб NAT міг відстежувати це як будь‑який UDP‑потік.
• UDP/4500 — звичний порт для NAT‑T. UDP/500 використовується для IKE; NAT‑T зазвичай переходить на UDP/4500 після виявлення NAT.
• IKEv2 поліпшив структуру повідомлень і надійність. У порівнянні з IKEv1, IKEv2 менш бароковий і зазвичай краще поводиться при втраті пакетів — але все ще залежить від поведінки мережевого шляху.
• Деякі NAT — «симетричні», і це має значення. Симетричний NAT може зламати припущення про збереження портів і доступність ззовні, особливо коли кілька тунелів або peer‑ів ділять адресу.
• PMTUD‑збої старіші за NAT‑T. Але NAT‑T підвищує накладну, через що латентні MTU‑проблеми проявляються частіше і болючіше.
• DPD і keepalives — це операційні інструменти, а не опціональні «фішки». Вони існують тому, що проміжні пристрої таймаутять стан, і тому «тиха відмова» поширена в інтернеті.
• Cloud VPN часто приховує складність за статусом «connected». Такий статус зазвичай відображає здоров’я IKE контрольної площини, а не те, чи проходить ваші конкретні підмережі реальний трафік.

FAQ

1) Якщо IKEv2 показує ESTABLISHED, чому я не можу пройти трафік?

Тому що контрольна площина і data‑plane — різні речі. IKE може вдались на UDP/500, тоді як UDP/4500 або ESP заблоковані, селектори не співпадають, маршрути неправильні або MTU‑чорні діри з’їдають великі пакети.

2) Чи завжди потрібно відкривати ESP (IP protocol 50)?

Якщо ви завжди використовуєте NAT‑T, data‑plane — це UDP/4500, а не raw ESP. Але багато середовищ можуть переключатися залежно від виявлення NAT або конфігурації, тому дозволяти ESP іноді корисно. Реальна відповідь: перевіряйте, що саме використовують ваші пірі, і пишіть правила фаєрвола відповідно.

3) Чи можу я запускати NAT‑T, навіть якщо NAT немає?

Часто так, залежно від реалізації. Але примусове використання NAT‑T скрізь додає накладні й піддає вас UDP‑фільтруванню/conntrack‑поведінці. Використовуйте його, коли треба; не вірте в це як у забобон.

4) Чому тунель помирає лише після простою?

NAT і stateful фаєрволи таймаутять UDP‑стан. Без частих keepalive відображення зникає. Наступний пакет йде на порт, який уже не форвардиться.

5) Який інтервал keepalive мені використовувати?

Менший за найкоротший NAT‑таймаут, який ви очікуєте на шляху. У змішаних корпоративних середовищах зазвичай приймають ~20–30 секунд. «Правильне» значення таке, що тримає відображення живим без зайвого шуму. Якщо гадаєте — обирайте консервативно і перевіряйте.

6) Чому малі ping’и працюють, а додатки падають?

MTU/фрагментація. NAT‑T + IPsec зменшують ефективний MTU. Якщо PMTUD зламаний, великі пакети зникають. Виправлення — MSS‑clamp і/або MTU‑налаштування, а також дозвол ICMP, якщо дозволяє політика.

7) Який найшвидший спосіб довести, що UDP/4500 блокується?

Захоплення на обох кінцях. Якщо бачите вихідні UDP/4500 з одного піру й нічого не приходить на інший — шлях фільтрує або неправильно маршрутизує. Захоплення перемагають думки.

8) Чи важливий double NAT?

Так. Він може змінювати портові відображення, скорочувати таймаути і вводити симетричну NAT‑поведінку. Якщо не можете позбутися double NAT, зазвичай потрібні агресивніші keepalive і жорстка симетрія правил фаєрвола.

9) Чи агресивні таймери рекі корисні для безпеки?

Безпека не покращується, якщо тунель непридатний до використання. Розумні терміни життя з стабільною поведінкою кращі, ніж постійні рекі, що викликають втрати пакетів, колізії та флапи — особливо за NAT.

10) Як правильно моніторити site‑to‑site IPsec тунель?

Моніторте data‑plane успіх: періодичні синтетичні транзакції між реальними хостами/підмережами, плюс лічильники байтів SA і події retransmit/DPD. «IKE вгору» необхідно, але не достатньо.

Наступні кроки, які вам варто зробити

1. Переписати інвентар тунелів і зафіксувати для кожного: чи використовує NAT‑T (UDP/4500), які підмережі захищені і які таймери keepalive/DPD налаштовані.
2. Зробити правила UDP/4500 явними на кожному фаєрволі між пірми. «IPsec дозволено» — це не аудит‑дружнє твердження.
3. Додати одну перевірку data‑plane на тунель: малий ping, DF‑ping поруч з MTU і TCP‑транзакція (HTTPS або подібне). Алертуйте про падіння, а не про «відсутність SA».
4. Виправити MTU превентивно: впровадьте MSS‑clamping на шлюзах, де не контролюєте ICMP і де тунелі перетинають непередбачувані мережі.
5. Припиніть «оптимізувати» keepalive, якщо не виміряли NAT‑таймаути енд‑ту‑енд. Якщо зменшуєте частоту, робіть це з доказами і планом відкату.
6. Коли відбуваються інциденти, починайте з capture. 30‑секундний pcap на кожному WAN‑інтерфейсі закінчує суперечки швидше за будь‑яке запрошення на зустріч.

Якщо ви зробите це, NAT‑T знову стане нудною деталлю — саме там йому й місце.