Client VPN savienojums pārtrūkst, ACM sertifikāts tiek aizstāts, un nekas nemainās. Sertifikāta objekts nekad nav bijis tas, ko izmantoja galapunkts. Galapunkts izveides laikā saglabā saikni ar sertifikātu, kopā ar klienta CA, pret kuru tas validēs, autentifikācijas tipu, apakštīkliem un autorizācijas noteikumiem, un nevienai no šīm saiknēm nav izmaiņu izsaukuma, kas pieņemtu aizstājējsertifikātu. Baitu aiz ARN aizstāšana ir sertifikāta izmaiņa, nevis galapunkta, kas to fiksēja.

Galapunkts glabā atsauces, nevis sertifikātus

Mehānismu ir vērts formulēt precīzi, jo tas izskaidro visu kļūmi. create-client-vpn-endpoint ņem servera sertifikāta ARN un klienta saknes sertifikātu ķēdes ARN, un iegūtais galapunkts saglabā šīs atsauces kopā ar autentifikācijas opcijām kā fiksētas īpašības. API nepiedāvā operāciju, kas nomainītu servera sertifikātu esošā galapunktā.

Saikni varat apstiprināt, neuzminot. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 izdrukā sertifikāta ARN, klienta saknes ķēdes ARN, autentifikācijas tipu, klienta CIDR un saistītos apakštīklus, kas ir pilnā īpašību kopa, kas jums būtu jāatkārto. Palaidiet to pirms un pēc atkārtotas importēšanas, un izvade nekustas. Tas ir pierādījums, ka atkārtotā importēšana nekad nepalīdzētu.

Kāpēc atkārtota importēšana nevar sasniegt galapunktu

Atkārtota importēšana ieraksta jaunu sertifikāta pamattekstu zem esoša ARN. Tā ir likumīga operācija, kad sertifikāts ir tuvu derīguma beigām, un ACM to pieņems, ja privātā atslēga atbilst un ķēde validējas. Ko tā nedara, ir galapunkta izveides laika validācijas atkārtota palaišana, tāpēc saikne un materiāls aiz tās paliek tāds, kāds tas bija galapunkta būvēšanas laikā.

Tāpēc arī simptoms izskatās kā tīkla kļūme. TLS rokasspiediens neizdodas vai tiek atiestatīts, pirms autorizācija vispār tiek novērtēta, tāpēc drošības grupas, maršruti un autorizācijas noteikumi visi izskatās nevainīgi, un tādi arī ir.

Ķēde ir klienta sertifikāta daļa

Kļūmes otrā puse ir klienta sertifikātā, un to ir vieglāk atstāt novārtā. Klienta sertifikāts ir jāimportē kopā ar ķēdi, kas to izdeva, lai gan importēšanas veidlapa šo lauku parāda kā neobligātu. Bez ķēdes galapunkts nevar izveidot ceļu no klienta sertifikāta līdz klienta saknes CA, ar kuru tas bija konfigurēts, un savienojums beidzas ar mīkstu atiestatīšanu, kas izklausās kā ugunsmūris, kas izmet paketes. openssl verify -CAfile root-ca.pem client.crt atbild uz šo jautājumu lokāli sekundes laikā, un tai jābūt pirmajai komandai, ko palaižat.

Atkārtota importēšana ar ķēdi ir īsts labojums šai pusei, un tomēr vien tā nav pietiekama. Kad ACM objekts ir mainījies, galapunkts ar veco saikni ir nepareizais objekts, pret ko turpināt testēšanu. Abi soļi pieder pie tā paša remonta, tāpēc divdaļīgais labojums nav pretruna.

Galapunkta atkārtota izveide ir migrācija

Aizstājēja galapunkta izveide ir migrācija, nevis atkārtots mēģinājums, un izturēšanās pret to kā pret atkārtotu mēģinājumu ir ceļš, kā komandas nonāk pie diviem puslīdz konfigurētiem galapunktiem. Jaunais galapunkts iegūst jaunu ID un, ja to neplānojāt, jaunu DNS vārdu katram lietotājam. Turiet klienta profilu vērstu uz vārdu, nevis adresi, lai maiņa kļūtu par ieraksta izmaiņu, nevis pārdali.

Secība, kas to uztur drošībā, ir īsa: izveidojiet jauno galapunktu ar to pašu CIDR, apakštīkliem un autorizācijas noteikumiem, eksportējiet svaigu profilu ar aws ec2 export-client-vpn-client-configuration un pārbaudiet ar vienu lietotāju. Tikai pēc tam vecais galapunkts tiek noņemts.

Vecā galapunkta izņemšanai no ekspluatācijas ir sava secība. Atsauciet klienta sertifikātus, kurus grasījāties izņemt, pirms to dzēšat, jo jauns galapunkts, kas joprojām uzticas vecajai CA, turpina pieņemt sertifikātus, kurus uzskatījāt par pazudušiem. Pēc tam dzēsiet veco galapunktu un noņemiet tā autorizācijas noteikumus, lai novecojis profils nevarētu atkal pieslēgties mērķa tīklam, kuru uzskatījāt par slēgtu. Ierakstiet vecā galapunkta ID un saiknes identifikatorus izmaiņu reģistrā, jo migrācija, kas salīdzināta ar atmiņu, ir ceļš, kā strādājošs galapunkts tiek pārbūvēts divreiz.

Sakārtojiet diagnostiku

Atdaliet trīs kļūmes pirms jebkuras konfigurācijas maiņas. Klients nevar pabeigt TLS, klients pabeidz TLS un nav autorizēts, vai klients pieslēdzas un nevar sasniegt galamērķi. Sertifikāta saikne pieder pirmajai, autorizācijas noteikums, kas neaptver klienta adresi, otrajai, un maršruts vai drošības grupa trešajai, kur galapunkta atkārtota izveide gandrīz vienmēr ir nepareizais solis.

Galapunkts, kas darbojās mēnešiem un tad apstājās, bez sertifikāta vai politikas izmaiņām, ir atsevišķs gadījums. Tā pārbūve ar identiskiem iestatījumiem var atjaunot pakalpojumu, bet tas ir iemesls uzturēt konfigurāciju atkārtojamu, nevis iemesls pārbūvēt pie katra incidenta.

Turiet četras lietas versiju kontrolē, lai nākamā pārbūve būtu diff, nevis improvizācija: galapunkta parametrus, sertifikāta un ķēdes ARN, autorizācijas noteikumus un klienta CIDR. Client VPN autentifikācijas dokumentācija uzskaita, kurš sertifikāts spēlē kādu lomu, un to ir vērts pārbaudīt, pirms vispār pieņemt, ka sertifikāts ir problēma. Ja atkārtota importēšana neko nemaina un galapunkts joprojām atiestatās, aizdomās turamā ir saikne, un atbilde ir jauns galapunkts, kas būvēts no ierakstītajiem parametriem. Ja galapunkts tomēr pārņem jauno objektu, saikne jau bija pareiza, un kļūme ir klienta ķēdē vai autorizācijas slānī.

Saistītie raksti