Як NAT traversal загортає ESP у UDP
ESP не має портів, тому NAT traversal загортає його в UDP на 4500. Перевірте обмін керування та інкапсульований шлях даних як два окремі етапи.
Два клієнти за одним маршрутизатором спілкуються з одним шлюзом IPsec, і один постійно відпадає, а інший тримається. Рідний ESP — це IP-протокол 50 без портів, тому транслятору нема за що зачепити відображення, коли кілька клієнтів ділять одну адресу. NAT traversal закриває цю прогалину, загортаючи ESP в UDP на 4500, і цей заголовок пояснює більшість наступних симптомів. Він також указує на пристрій, який треба змінити.
Чому площина даних переходить на порт 4500
Під час налаштування IKEv2 порівнює адреси й порти, які кожна сторона вважає використовуваними, обмінюючись хешами у своїх сповіщеннях про виявлення NAT. Коли хеші не збігаються, десь на шляху стоїть транслятор, і обидві сторони переводять захищений трафік на інкапсуляцію UDP. Тому сеанс, що зіткнувся з транслятором, виглядає інакше, ніж той, що не зіткнувся.
Обгортка — це конверт, а не зміна протоколу: ESP зберігає свій заголовок, перевірку цілісності та шифрування, а UDP надає лише ті порти, які потрібні транслятору. Порт 500 несе обмін IKE; 4500 несе інкапсульовані дані після виявлення і часто пізніші повідомлення IKE. Жоден із портів не робить потік TCP-з'єднанням, і саме це припущення вводить в оману більшість тих, хто читає захоплення.
Перевірте два етапи по черзі
Спочатку доведіть обмін керування, потім шлях даних, і тримайте обидва окремо у своїх нотатках. Захоплення, що показує трафік на 500 і ніколи на 4500, зазвичай означає, що шлях даних фільтрується, тож виправлення належить правилу брандмауера, а не клієнту.
Спостерігайте за обома портами за допомогою tcpdump -ni any 'udp port 500 or udp port 4500' і читайте таблицю трансляції на маршрутизаторі, поки сеанс активний. Таблиця показує вихідний порт, який шлюз реально побачить, а захоплення на ноутбуці розходиться з нею навмисно: ноутбук вважає 500, тоді як шлюз бачить 4500 із трансльованим вихідним портом, і обидва мають рацію. Той самий потік до і після трансляції:
client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500
Симптоми, які пояснює обгортка, і два, яких вона не пояснює
Маршрутизатор, який дозволяє обмін керування і блокує інкапсульовані дані дає звіт «тунель піднято, але нічого не проходить». Таблиці відображень спливають, тому простому сеансу потрібен трафік підтримки, який сторони надсилають навмисно, і ці пакети не є перевірками здоров'я. Коли кілька клієнтів за одним шлюзом падають разом, дослідіть трансляцію цього шлюзу і будь-яку стару функцію пропускання. Обгортка не пояснює застосунок, що падає в кожного клієнта після підняття тунелю, ні попередження про сертифікат на сторінці блокування; і те, і те лежить вище цього рівня.
Читайте таблицю відображень одразу для двох клієнтів: якщо обидва показують той самий трансльований порт, пристрій не розділяє їх так, як вимагає шлюз. Режим пропускання, що віддає рідний ESP лише одному хосту, не еквівалентний обслуговуванню кількох трансльованих клієнтів, хоча постачальники описують обидва як дружні до IPsec. Подвійний NAT додає шар відображень і ще одну точку спливання, але не рве вихідні з'єднання автоматично.
Трафік підтримки заслуговує окремого рядка в настанові з експлуатації, бо саме він тримає шлях відповіді відкритим у періоди простою. Увімкніть його там, де постачальник це документує, і перевіряйте його першим, коли сеанс помирає після кількох хвилин тиші, а не під час першого використання.
Змініть власника відображення, потім повторіть тест
Дотримуйтеся підтримуваних налаштувань NAT traversal на обох сторонах, а не вгадуйте порт. Правка локального вихідного порту на одному клієнті не може змінити службу, що слухає на іншому кінці, і зазвичай ламає вже побудоване відображення. Якщо клієнт стоїть за пристроєм, яким ви не керуєте, зміна належить його власнику.
Після будь-якої зміни повторіть обидві перевірки етапів і підтвердьте, що пакет даних проходить, а не лише що екран стану став зеленим. Тримайте кортежі, вивід таблиці відображень і зміну правила в одній нотатці, щоб наступна людина не починала заново з обміну керування. Нотатки strongSwan про NAT traversal охоплюють налаштування інкапсуляції та підтримки за обома етапами.