Как отличить фрагментацию IKEv2 от проблемы с цепочкой сертификатов

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

Два механизма фрагментации, один симптом

У IKEv2 есть собственное расширение фрагментации, определённое в RFC 7383, которое делит защищённые сообщения IKE на меньшие сообщения IKE. Стороны договариваются об этой возможности, а сообщение собирается реализацией IKE, а не уровнем IP.

Обычная фрагментация IP — это другой механизм с другим режимом отказа. Маршрутизатор между сторонами фрагментирует большую датаграмму либо отбрасывает её и возвращает сообщение ICMP, которое может так и не дойти до отправителя. Некоторые сети молча отбрасывают фрагменты, а некоторые промежуточные устройства обрабатывают первый фрагмент, но не остальные. С точки зрения приложения все три случая выглядят одинаково.

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

Прочитайте обмен, который не удался

Ищите переход, а не ошибку. Журнал, показывающий, что первый обмен отправлен и получил ответ, а затем ничего, говорит вам, что следующее сообщение так и не завершилось. Временно повысьте уровень журнала и сравните сообщаемые размеры на обеих сторонах.

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

Меняйте путь, а не сертификат

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

Если рукопожатие завершается на втором пути, цепочка сертификатов в порядке, а переменная — первый путь. Если оно одинаково не удаётся на обоих, прекратите проверять сети и посмотрите на сами сообщения. Это единственное сравнение убирает примерно половину возможных объяснений.

Измерьте обмен, прежде чем что-либо менять

Получите размер цепочки и размер пути. Оба числа ограничивают то, что может отправить рукопожатие, и оба дешево измерить:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Первые два дают число сертификатов и размер файла, что является разумным показателем того, насколько большим будет сообщение аутентификации. Проверка ping сообщает, переживает ли датаграмма такого размера путь, а счётчики интерфейса показывают, были ли фрагменты отброшены на вашей стороне. В Windows эквивалентная проверка — это ping с флагом do-not-fragment и явным размером полезной нагрузки.

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

Исправляйте тот уровень, который действительно сломан

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

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

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