IPsec захищає мережеву взаємодію на третьому рівні моделі OSI через ненадійні публічні канали зв'язку. Створений в епоху, коли кожен мережевий вузол володів глобально маршрутизованою IPv4-адресою, IPsec використовує протокол Encapsulating Security Payload (ESP, протокол IP 50) для забезпечення конфіденційності, автентифікації джерела даних та захисту від повторного відтворення пакетів (anti-replay). Однак вичерпання пулу IPv4 призвело до повсюдного впровадження механізмів трансляції мережевих адрес і портів (NAT/PAT). Оскільки чистий протокол ESP функціонує безпосередньо над IP без транспортних портів 4-го рівня (TCP/UDP), проміжні шлюзи не здатні коректно відстежувати або демультиплексувати зворотний зашифрований трафік. Стандарти RFC 3947 («Negotiation of NAT-Traversal in the IKE») та RFC 3948 («UDP Encapsulation of IPsec ESP Packets») розв'язують цю фундаментальну колізію через загортання пакетів ESP у датаграми UDP через порт 4500.

Архітектура чистого ESP (помилка при проходженні PAT/NAT):
[IP-заголовок (Proto 50)] [ESP-заголовок: SPI (4B), Seq (4B)] [Зашифровані дані]
                        └──> Немає портів UDP/TCP! PAT не маршрутизує відповіді.

Інкапсульований ESP за RFC 3948 (порт UDP 4500):
[IP-заголовок (Proto 17)] [UDP-заголовок (Src 4500, Dst 4500)] [ESP] [Дані]
                        └──> Маршрутизовані порти L4 забезпечують відстеження стану.

Проблема трансляції мережевих портів PAT: чому чистий протокол ESP не працює через NAT

Розуміння необхідності використання механізму IPsec NAT-Traversal (NAT-T) вимагає детального аналізу обробки пакетів шлюзами трансляції з відстеженням стану.

Відсутність портів на транспортному рівні в заголовку ESP

Коли кілька приватних вузлів за офісним маршрутизатором або операторським шлюзом Carrier-Grade NAT (CGNAT) звертаються до віддалених серверів, шлюз перетворює їхні внутрішні адреси на єдину спільну публічну IP-адресу. Щоб ідентифікувати, якому саме клієнту належить зворотний пакет, транслятор призначає унікальний порт джерела 4-го рівня для кожної сесії TCP або UDP.

Протокол ESP оперує безпосередньо на рівні 3 під кодом протоколу 50. На відміну від TCP (протокол 6) чи UDP (протокол 17), ESP позбавлений концепції номерів портів. Перші 4 байти заголовка ESP містять індекс параметрів безпеки (Security Parameter Index, SPI) — 32-бітне значення, що обирається стороною-одержувачем для прив'язки до асоціації безпеки (SA):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data (Variable)                    |

Коли вихідний пакет ESP проходить крізь PAT, транслятор модифікує IP-адресу джерела, проте не може створити портовий запис у таблиці з'єднань. Коли надходить зворотний пакет ESP, пристрій PAT перевіряє заголовок: через відсутність порту призначення він не здатний визначити внутрішнього адресата. Спроби деяких маршрутизаторів аналізувати поле SPI («SPI passthrough») зазнають краху, якщо кілька клієнтів за одним NAT одночасно встановлюють тунелі до однакового віддаленого VPN-сервера.

Модифікація мережевого шляху та порушення контрольної суми TCP/UDP

Друга суттєва перешкода проявляється у транспортному режимі IPsec (Transport Mode). Алгоритми обчислення контрольних сум псевдозаголовків TCP та UDP перевіряють цілісність адрес відправника, отримувача, типу протоколу та довжини сегмента. Коли проміжний NAT змінює IP-адресу, оригінальна контрольна сума транспортного рівня стає невалідною. Оскільки корисне навантаження надійно зашифроване за допомогою ESP, транслятор NAT не може перерахувати контрольну суму. Після розшифрування на цільовому вузлі верифікація контрольної суми не проходить, і стек ядра операційної системи відкидає пакет без повідомлення.

Механізм RFC 3947 NAT-Discovery: автоматичне виявлення проміжних шлюзів

Для динамічного усунення несумісності з трансляцією адрес стандарт RFC 3947 (інтегрований в протокол IKEv2 RFC 7296) визначає процедуру виявлення NAT (NAT-Discovery, NAT-D) під час встановлення початкових асоціацій безпеки.

Корисне навантаження NAT-D та звірка хешів у фазі IKE_SA_INIT

На початковому етапі узгодження (IKE_SA_INIT) клієнт та сервер генерують пакети через стандартний порт UDP 500. Кожна сторона надсилає один або декілька корисних навантажень NAT-D (NAT-Detection). Кожне навантаження містить криптографічний хеш SHA-1 або SHA-256 від IP-адреси та порту учасника обміну:

$$\text{Хеш NAT-D} = \text{SHA-1}(\text{SPI}_i ,|, \text{SPI}_r ,|, \text{IP} ,|, \text{Port})$$

  1. Ініціатор обчислює хеш своєї локальної IP-адреси й порту та хеш відомої IP-адреси сервера, після чого відправляє обидва значення.
  2. Отримувач генерує власні локальні хеші від адреси, з якої фактично надійшов пакет, та адреси, куди він прибув.
  3. Якщо надіслані та згенеровані локально хеші повністю збігаються, прямий мережевий шлях вільний від трансляції адрес.
  4. Якщо виявлено невідповідність хешів, це слугує сигналом про наявність між вузлами проміжного пристрою NAT, який змінив зовнішню IP-адресу.

Перемикання портів: плавний перехід із UDP 500 на UDP 4500

Якщо перевірка NAT-D зафіксувала наявність NAT, протокол негайно ініціює перемикання портів (Port Floating). Починаючи з наступного запиту IKE_AUTH, обидві сторони переводять подальшу комунікацію з порту UDP 500 на порт UDP 4500.

Перенесення керуючого обміну на порт 4500 усуває конфлікти зі шлюзами, які блокують повторне відкриття UDP 500 для кількох локальних клієнтів або агресивно скидають сесії UDP 500 за тайм-аутом. Крім того, перехід на 4500 готує канал для подальшої передачі користувацьких зашифрованих даних через той самий порт.

Архітектура інкапсуляції RFC 3948: призначення 4-байтового маркера Non-ESP

Головна складність спільного використання порту UDP 4500 полягає в необхідності одночасного приймання як керуючих повідомлень IKE, так і зашифрованих даних ESP. RFC 3948 вирішує це завдання за допомогою витонченого механізму маркерів.

Демультиплексування керуючого трафіку IKE та корисного навантаження ESP

При надходженні пакета на порт UDP 4500 стек IPsec повинен миттєво визначити, чи містить датаграма керуюче повідомлення IKE (яке слід передати демону простору користувача), чи зашифрований пакет ESP (який слід спрямувати до криптографічного прискорювача ядра).

Для розмежування потоків використовується поле Non-ESP Marker завдовжки 4 байти:

Керуючий пакет IKE over UDP 4500 (містить маркер Non-ESP):
+---------------------------------------------------------------+
| UDP-заголовок (Порт джерела: XXXX, Порт призначення: 4500)    |
+---------------------------------------------------------------+
| Non-ESP Marker: 0x00000000 (4 нульові байти)                 |
+---------------------------------------------------------------+
| Заголовок IKEv2 (SPI ініціатора, SPI відповідача, прапорці)   |
+---------------------------------------------------------------+

Зашифрований пакет ESP over UDP 4500 (без нульового маркера):
+---------------------------------------------------------------+
| UDP-заголовок (Порт джерела: XXXX, Порт призначення: 4500)    |
+---------------------------------------------------------------+
| ESP SPI (32 біти, значення суворо ненульове: 0xXXXXXXXX)      |
+---------------------------------------------------------------+
| ESP Sequence Number (32 біти)                                 |
+---------------------------------------------------------------+
| Зашифрований корисний вантаж та код автентифікації ICV        |
+---------------------------------------------------------------+

Згідно зі специфікацією RFC 4303, перші 4 байти заголовка ESP займає поле SPI. За стандартом значення SPI 0x00000000 зарезервоване і ніколи не призначається дійсній асоціації безпеки. Якщо перші 4 байти після заголовка UDP дорівнюють нулю, ядро ідентифікує пакет як IKE і передає його сервісу керування тунелями. Якщо перші 4 байти відмінні від нуля, вони інтерпретуються як ESP SPI, і пакет розшифровується безпосередньо в ядрі операційної системи.

Робота NAT Keepalive та таймери таблиць трансляції з відстеженням стану

Транслятори NAT зберігають стан відкритих портів UDP у динамічних таблицях трансляцій. Якщо трафік через тунель тимчасово припиняється, шлюз видаляє запис після закінчення тайм-ауту неактивності (зазвичай від 30 до 120 секунд у мережах мобільних операторів). Після цього зворотні пакети з сервера перестають доходити до клієнта.

Щоб запобігти передчасному скиданню записів, RFC 3948 описує спеціальний механізм надсилання підтримувальних пакетів (NAT Keepalive). Клієнт періодично генерує мінімальну UDP-датаграму:

+-----------------------------------------------+
| IP-заголовок (Proto 17, адреси вузлів)        |
+-----------------------------------------------+
| UDP-заголовок (Src 4500, Dst 4500, Length 9)  |
+-----------------------------------------------+
| 0xFF (Один байт корисного навантаження)       |
+-----------------------------------------------+

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

Накладні витрати тунелювання, виявлення Path MTU та обмеження TCP MSS

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

Додавання 8-байтового заголовка UDP знижує ефективний максимальний розмір блоку передачі (MTU). На стандартному каналі Ethernet з MTU 1500 байтів:

  • Службові витрати чистого IPv4 ESP коливаються в діапазоні від 50 до 60 байтів залежно від алгоритмів шифрування (AES-GCM-128 або комбінація AES-CBC-256 з HMAC-SHA256).
  • Інкапсуляція в UDP додає ще 8 байтів, збільшуючи сумарні накладні витрати тунелю до 62–72 байтів.
  • Внутрішній параметр TCP MSS слід коригувати (MSS Clamping) зі стандартного значення 1460 байтів до діапазону 1360–1380 байтів.

Якщо не застосовувати примусове коригування MSS, великі пакети фрагментуватимуться. Оскільки багато проміжних операторських маршрутизаторів скидають фрагментовані пакети IP, помилки в конфігурації MTU призводять до зависання сесій TCP і падіння швидкості передачі даних.

Стійкість у корпоративних мережах CGNAT: інтеграція з архітектурою RiceGuard

У сервісі VPNRice захищене ядро RiceGuard реалізує протокол RFC 3948 NAT-T для забезпечення стабільного зв'язку в умовах жорстких обмежень мобільних операторів та багаторівневих корпоративних екранів.

Архітектура RiceGuard Zero-Trust NAT-T:
Мобільний клієнт / Віддалений термінал
  │  (За шлюзом Carrier-Grade NAT / Dual NAT)
  │  Надсилає IKE_SA_INIT через порт UDP 500
  ▼
Автоматична перевірка NAT-D
  │  - Фіксує зміну зовнішнього кортежу IP
  │  - Виконує плавне перемикання на UDP 4500
  │  - Додає 4-байтні маркери Non-ESP для керуючих запитів
  ▼
Високопродуктивний шлюз RiceGuard
  │  - Приймає інкапсульовані кадри ESP over UDP 4500
  │  - Обробляє асоціації SAD через механізм XFRM у ядрі
  │  - Динамічно регулює частоту пакетів keepalive
  ▼
Захищена корпоративна магістраль / Доступ до мережі
  1. Детерміноване перемикання портів: RiceGuard автономно визначає наявність NAT під час початкової фази узгодження, перемикаючись на UDP 4500 для захисту від фільтрації порту 500 на рівні інтернет-провайдерів.
  2. Адаптивні інтервали Keepalive: Замість фіксованих пауз система динамічно налаштовує частоту відправлення підтримувальних пакетів залежно від типу операторської мережі, зберігаючи заряд акумулятора мобільних пристроїв.
  3. Апаратне демультиплексування в ядрі: Завдяки інтеграції з політиками сокетів XFRM у Linux, зашифровані пакети опрацьовуються криптографічними модулями апаратного прискорення безпосередньо в просторі ядра.

Діагностика та верифікація: перевірка сокетів NAT-T та бази SAD у ядрі Linux

Мережеві інженери можуть контролювати параметри активних тунелів NAT-T на шлюзах Linux за допомогою стандартного інструментарію.

Перевірка стану прослуховування сокетів UDP 4500

Перевірте наявність відкритих мережевих сокетів сервісу IPsec на портах 500 та 4500:

# Перевірка сокетів UDP для служб IKE та NAT-T
ss -uan '( sport = :500 or sport = :4500 )'

Зразок виводу:

State    Recv-Q    Send-Q       Local Address:Port        Peer Address:Port
UNCONN   0         0                  0.0.0.0:500              0.0.0.0:*
UNCONN   0         0                  0.0.0.0:4500             0.0.0.0:*

Перевірка бази станів XFRM у ядрі щодо параметрів інкапсуляції UDP

Перегляньте стан Security Association Database (SAD) у ядрі Linux для підтвердження параметрів інкапсуляції:

# Відображення активних параметрів безпеки IPsec та інкапсуляції
ip xfrm state show

Фрагмент конфігурації:

src 198.51.100.2 dst 203.0.113.1
	proto esp spi 0xc7a41289 reqid 1 mode tunnel
	replay-window 64 flag af-unspec
	auth-trunc hmac(sha256) 0x6e7a... 128
	enc cbc(aes) 0x4f12...
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	sel src 0.0.0.0/0 dst 0.0.0.0/0

Директива encap type espinudp однозначно вказує, що ядро операційної системи інкапсулює вихідний трафік ESP у датаграми UDP з портами 4500 і коректно обробляє вхідні кадри, гарантуючи стабільний зв'язок через проміжні шлюзи.

Специфікація RFC 3948 стала ключовим етапом розвитку захищених протоколів, забезпечивши надійне використання IPsec у сучасному інтернеті з поширеною трансляцією адрес. Інкапсуляція ESP в UDP та впровадження маркерів Non-ESP гарантують високу продуктивність тунелів у корпоративних та операторських мережах.

Щоб розгорнути стійкі тунелі нульової довіри для безперешкодного проходження корпоративних шлюзів, Завантажити VPNRice.