Зошто повторното импортирање на сертификат за 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 наведува кој сертификат игра која улога, што вреди да се провери пред воопшто да претпоставите дека сертификатот е проблемот. Ако повторното импортирање не менува ништо и крајната точка и понатаму се ресетира, сомнителното е поврзувањето и одговорот е нова крајна точка изградена од запишаните параметри. Ако крајната точка сепак го преземе новиот објект, поврзувањето веќе било точно и дефектот е во клиентскиот ланец или слојот за авторизација.