strongSwan ESP-in-UDP: коли немає NAT, який треба виявити

Виявлення NAT знаходить трансляцію адрес, а не політику міжмережевого екрана. З'єднанню майданчика без NAT усе одно може знадобитися явний вибір ESP-in-UDP.

Виявлення NAT відповідає на одне питання: чи змінилися адреси або порти в дорозі? Воно не відповідає, чи пропускає міжмережевий екран протокол IP 50. Шлюзи майданчика без будь-якої трансляції можуть і далі стояти за політикою, що відкидає native ESP, і цю вимогу треба налаштувати, а не виявити. Механізм — ESP-in-UDP, і це рішення, а не запасний варіант, що з'являється сам.

Виявлення — це арифметика над адресами, а не перевірка міжмережевого екрана

IKEv2 переносить корисні навантаження виявлення NAT з хешами адрес і портів джерела та призначення. Кожна сторона порівнює отримане з тим, що бачить локально, і розбіжність повідомляє їй, що щось транслювало пакет. Ніщо в цьому обміні не перевіряє, чи передає маршрутизатор посередині протокол 50.

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

Отже, інкапсуляція — це властивість з'єднання, яке ви налаштовуєте, а не результат, який сторони узгоджують із поведінки мережі.

Як encap змінює обмін

У сучасному розгортанні strongSwan, керованому через swanctl.conf, параметр encap = yes на з'єднанні впливає на обмін виявлення NAT так, що обидві сторони використовують інкапсуляцію UDP для ESP. Захищені пакети потім ідуть усередині UDP, зазвичай на порту 4500, і обидва кінці мають домовитися про цю схему.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Цей фрагмент належить усередину справжнього визначення з'єднання і не є повним профілем майданчика. Залиште адреси партнера, автентифікацію та селектори трафіку child, які ви вже використовуєте; єдиний доданий ключ змінює те, як пакуються захищені дані, а не що вони захищають.

Посібник strongSwan із NAT-traversal описує цю поведінку, включно із взаємодією з плаваючим портом, коли використовується MOBIKE.

Використовуйте параметр, що належить вашому backend

У strongSwan два backend конфігурації, і ключ різниться між ними. swanctl.conf з'єднання приймає encap, а застаріле ipsec.conf з'єднання приймає forceencaps. Якщо вставити ключове слово одного backend в інший, вийде конфігурація, яка завантажується без скарг і нічого не змінює, що гірше за помилку.

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

Застосуйте зміну через власника з'єднання і відновіть асоціацію в контрольованому вікні. Уже встановлений child зберігає поточну інкапсуляцію, доки його не замінять, тому сама лише правка файлу не доводить, що нова схема використовується.

Перевіряйте упаковані дані, а не лише порт

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

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP виглядає як протокол IP 50 і зовсім не схожий на UDP. Упакований ESP виглядає як UDP-дейтаграми на 4500, корисне навантаження яких не IKE. Трафік IKE на тому самому порту не є доказом інкапсуляції, бо MOBIKE може перенести IKE туди, поки шлях даних залишається native, тому читайте навантаження, а не номер порту.

Майте на увазі й MTU шляху. Обгортка додає накладні витрати, і шлях, що ніс native ESP, може потребувати коригувань, коли пакети зростають. Потрібна обробка ICMP уже має бути частиною проєкту; інкапсуляція не усуває цієї залежності.

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

Схожі статті