Почему повторный импорт сертификата Client VPN требует новой конечной точки

Соединение Client VPN обрывается, сертификат в ACM заменяется, и ничего не меняется. Объект сертификата никогда не был тем, что использовала конечная точка. Конечная точка при создании сохраняет связь с сертификатом, вместе с клиентским CA, относительно которого она будет проверять, типом аутентификации, подсетями и правилами авторизации, и ни у одной из этих связей нет вызова изменения, который принимает заменяющий сертификат. Замена байтов за ARN — это изменение сертификата, а не конечной точки, которая его зафиксировала.

Конечная точка хранит ссылки, а не сертификаты

Механизм стоит сформулировать точно, потому что он объясняет весь сбой. create-client-vpn-endpoint принимает ARN серверного сертификата и ARN цепочки корневых сертификатов клиента, и полученная конечная точка хранит эти ссылки вместе с параметрами аутентификации как фиксированные свойства. API не предлагает операции, которая заменяет серверный сертификат у существующей конечной точки.

Связь можно подтвердить без догадок. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 выводит ARN сертификата, ARN корневой цепочки клиента, тип аутентификации, CIDR клиента и связанные подсети — полный набор свойств, которые вам пришлось бы воспроизвести. Запустите до и после повторного импорта, и вывод не сдвинется. Это и есть доказательство, что повторный импорт не мог помочь.

Почему повторный импорт не может достичь конечной точки

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

Поэтому и симптом выглядит как сбой сети. Рукопожатие TLS не удаётся или сбрасывается ещё до того, как авторизация будет оценена, поэтому группы безопасности, маршруты и правила авторизации выглядят невиновными, и они таковы.

Цепочка является частью клиентского сертификата

Вторая половина сбоя — в клиентском сертификате, и её легче отбросить. Клиентский сертификат нужно импортировать вместе с цепочкой, которая его выпустила, хотя форма импорта показывает это поле как необязательное. Без цепочки конечная точка не может построить путь от клиентского сертификата до корневого клиентского CA, с которым она настроена, и соединение заканчивается мягким сбросом, который звучит как межсетевой экран, отбрасывающий пакеты. openssl verify -CAfile root-ca.pem client.crt отвечает на этот вопрос локально за секунду, и это должна быть первая команда, которую вы запускаете.

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

Пересоздание конечной точки — это миграция

Создание заменяющей конечной точки — это миграция, а не повторная попытка, и относиться к ней как к повторной попытке — это путь, которым команды приходят к двум наполовину настроенным конечным точкам. Новая конечная точка получает новый ID и, если вы это не спланировали, новое DNS-имя для каждого пользователя. Держите клиентский профиль указывающим на имя, а не на адрес, чтобы переключение стало изменением записи, а не перераспределением.

Порядок, который это оберегает, короток: создайте новую конечную точку с тем же CIDR, подсетями и правилами авторизации, экспортируйте свежий профиль с помощью aws ec2 export-client-vpn-client-configuration и проверьте на одном пользователе. Только после этого старая конечная точка снимается.

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

Упорядочьте диагностику

Разделите три отказа, прежде чем менять любую конфигурацию. Клиент не может завершить TLS, клиент завершает TLS и не авторизован, или клиент подключается и не достигает назначения. Связь с сертификатом относится к первому, правило авторизации, не покрывающее адрес клиента, — ко второму, а маршрут или группа безопасности — к третьему, где пересоздание конечной точки почти всегда неверный шаг.

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

Держите четыре вещи под контролем версий, чтобы следующая пересборка была diff, а не импровизацией: параметры конечной точки, ARN сертификата и цепочки, правила авторизации и CIDR клиента. Документация по аутентификации Client VPN перечисляет, какой сертификат какую роль играет, и это стоит проверить до того, как предполагать, что проблема вообще в сертификате. Если повторный импорт ничего не меняет и конечная точка по-прежнему сбрасывается, подозреваемый — связь, и ответ — новая конечная точка, собранная из записанных параметров. Если конечная точка всё же принимает новый объект, связь уже была правильной, и неисправность в клиентской цепочке или слое авторизации.