Как читать первое сообщение обмена IKEv2 в перехвате пакетов

Перехваты, начатые в середине сеанса, — обычная причина, по которой след IKEv2 выглядит как шум: к моменту начала записи стороны уже обновляют ключи или обмениваются зашифрованными нагрузками. Начните вместо этого с новой попытки подключения, чтобы первое сообщение в файле было тем, которое открывает переговоры. Порядок чтения ниже это предполагает и отмечает точку, в которой пакет перестаёт что-либо доказывать о дальней стороне. Именно пропуск этого шага приводит к тому, что работающий туннель диагностируется как заблокированный порт.

Убедитесь, что вы смотрите на начальный обмен

Переговоры IKEv2 начинаются с IKE_SA_INIT, тип обмена 34, идентификатор сообщения 0. Инициатор выбирает ненулевой SPI, а SPI ответчика в этом первом запросе равен нулю и ненулевой в ответе. Эти три факта отличают новую попытку от обновления ключей или от сообщения IKE_AUTH, случайно оказавшегося в начале перехвата.

Поля заголовка читаемы, как и нагрузки предложения, обмена ключами и nonce. Читаемость не означает аутентификацию: ни одна из сторон не доказала личность на этом этапе, а закрытое значение Diffie-Hellman никогда не появляется в линии.

Печатайте поля таблицей, а не прокручивайте панель декодирования, потому что повторные передачи и несовпадающие SPI становятся очевидны в столбцах.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Читайте вывод парами. Запрос с идентификатором сообщения 0, за которым следует ответ с тем же идентификатором и ненулевым SPI ответчика, — это один обмен, даже если он появляется трижды, потому что запрос был передан повторно. Три одинаковых запроса — не три входа, и именно такое отношение приводит к выводу, что клиент крутится в цикле, тогда как он просто терпелив. Отсортируйте по идентификатору сообщения, затем по метке времени, и весь разговор сожмётся в короткий список попыток.

Прочитайте отказ раньше, чем успех

Ответ не является автоматически продвижением. Ответчик может ответить уведомлением cookie и ждать, что инициатор повторит попытку, либо INVALID_KE_PAYLOAD, назвав группу, которую он предпочёл бы принять. Оба приходят как корректно сформированные сообщения IKE, и оба выглядят как завершённый обмен для фильтра, который только считает пакеты.

Откройте нагрузку уведомления и прочитайте тип прежде всего остального. Вызов cookie означает, что ответчик защищается от поддельных адресов источника, и клиент должен отправить запрос заново с приложенным cookie. Недопустимая группа означает, что два предложения не совпадают, и никакое число повторов этого не изменит, пока не сдвинется конфигурация одной из сторон.

Только IKE_AUTH, второй обмен, несёт зашифрованную личность и нагрузки аутентификации. Поэтому завершённый IKE_SA_INIT говорит, что стороны согласны об алгоритмах и производных ключах, и совершенно ничего о том, будут ли приняты учётные данные. Ожидайте там тоже двух сообщений и ожидайте, что оба будут непрозрачны без ключей сеанса.

Порт 4500 — не один протокол

UDP 500 обычно несёт начальный обмен. После выполнения обнаружения NAT IKE переходит на 4500 и ставит перед каждым сообщением четырёхбайтовый нулевой маркер, не являющийся ESP. Инкапсулированный ESP на том же порту начинается, наоборот, с ненулевого SPI ESP, а однобайтовый NAT keepalive — третья форма, появляющаяся, когда больше ничего не происходит.

Фильтр, совпадающий только по порту, смешивает все три, и поэтому "на 4500 есть трафик" решает так мало. Разделите представление по протоколу, прежде чем делать выводы о дальней стороне.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Тишина описывает точку наблюдения

Запросы без ответов устанавливают ровно одну вещь: в этой точке перехвата ответ не появился. Фильтрация, маршрут, отправляющий ответ в другое место, недостижимый ответчик или ответчик, которому не нравится предложение, дают один и тот же пустой результат, и общая проверка UDP их не разделит.

ICMP-недостижимость — доказательство иного рода. Прочитайте цитированный пакет внутри него и определите, какое устройство его выпустило, потому что административный отказ маршрутизатора не является аутентифицированной ошибкой от дальней стороны.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Сопоставьте ту же попытку с журналами на стороне сервера там, где вам разрешено их читать. Пришёл ли запрос, ответила ли служба и где ответ остановился? Эти три ответа направят вас к проблеме пути или к проблеме политики, и они стоят меньше, чем четвёртая смена учётных данных.