Защо повторното импортиране на клиентски сертификат за 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 изброява кой сертификат каква роля играе и си струва да се провери, преди изобщо да предположите, че сертификатът е проблемът. Ако повторното импортиране не променя нищо и крайната точка продължава да се нулира, заподозряната е връзката и отговорът е нова крайна точка, изградена от записаните параметри. Ако крайната точка все пак поеме новия обект, връзката вече е била правилна и причината е в клиентската верига или в слоя за оторизация.