IKEv2 використовує UDP 500 і 4500: який із них несе дані?

Перший обмін і шлях, що несе дані, — не той самий потік. Перевірте обидва порти й пам'ятайте, що власний ESP — це номер протоколу, а не порт.

Відкриття UDP 500 у міжмережевому екрані дає тунелю змогу домовлятися, а потім з'єднання перестає пропускати трафік. Список портів був неповним, а не помилковим. IKEv2 починається на одному сокеті й у багатьох реальних розгортаннях продовжується на іншому, тоді як корисне навантаження може взагалі не бути портом. Читання етапів по порядку пояснює, якого правила бракує.

Два порти, дві задачі

IKEv2 починається з обміну ключами на UDP 500, де сторони автентифікуються й встановлюють асоціацію безпеки для тунелю. Наступний шлях даних — окреме питання: це може бути власний ESP, тобто номер IP-протоколу, а не порт, або трафік, інкапсульований в UDP на 4500. Розділяти ці речі під час перевірки міжмережевого екрана — означає відрізняти тунель, що домовляється, від тунелю, що працює. Один сокет несе керування, інший — корисне навантаження.

Тому правило, яке дозволяє лише 500, дає найзаплутаніший симптом у всій родині протоколів: узгодження проходить, а корисного нічого не відбувається. Стан показує партнера, журнал показує встановлену IKE SA, а застосунок усе одно отримує тайм-аут. Відсутній дозвіл стосується іншого потоку, ніж той, що щойно завершився успішно.

Чому 4500 взагалі існує

Багато пристроїв NAT не можуть передавати протокол, відмінний від TCP або UDP, а деякі переписують адреси так, що це ламає перевірку цілісності ESP. Інкапсуляція ESP в UDP вирішує обидві проблеми ціною додаткового заголовка й другого порту, який потрібно дозволити. Саме ця інкапсуляція є причиною існування другого порту.

Коли NAT виявлено, сам IKE також переходить на 4500, щоб увесь трафік ділив один шлях через транслятор. Чотирибайтовий маркер, що не є ESP, відрізняє керівні повідомлення від даних на цьому сокеті. Перехід — це рішення протоколу, а не вподобання адміністратора.

Де змінюється вихідний порт

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

Реалізації з підтримкою MOBIKE також можуть переходити на 4500 без виявленого NAT, а деякі розгортання навмисно нав'язують цей шлях. Тому бачити 4500 — це доказ рішення, а не доказ домашнього маршрутизатора.

Перевіряйте обидва потоки на кожній межі

Пройдіть три межі: мережу клієнта, будь-який проміжний міжмережевий екран і сервер. Кожній потрібні потоки, які документує розгортання, а не потоки зі статті про інший випадок.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

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

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

Схожі статті