Чому повторний імпорт сертифіката 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 перелічує, який сертифікат відіграє яку роль, і це варто перевірити, перш ніж узагалі припускати, що проблема в сертифікаті. Якщо повторний імпорт нічого не змінює, а кінцева точка досі скидається, підозрюваний — зв'язок, і відповідь — нова кінцева точка, збудована із зафіксованих параметрів. Якщо кінцева точка все ж приймає новий об'єкт, зв'язок уже був правильний, і несправність у клієнтському ланцюжку або шарі авторизації.