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 в списке межсетевого экрана — это совпадение по протоколу, поэтому правило порта никогда её не покрывает. Если оператор использует нестандартный порт, следуйте документированной конфигурации на обоих концах, потому что клиент не может создать слушателя на сервере, выбрав знакомый номер.

Запишите, где остановилось согласование и была ли установлена дочерняя ассоциация безопасности, поскольку эта пара отделяет заблокированный путь от ошибки аутентификации или политики. Затем повторите тест с включённой проверкой сервера, потому что доступность — это не аутентификация. Этот последний шаг отделяет разрешённый порт от доверенного партнёра.

Похожие статьи