Prečo opätovný import klientského certifikátu Client VPN vyžaduje nový koncový bod
Koncový bod Client VPN si pri vytvorení zviaže certifikát. Opätovný import objektu v ACM toto zviazanie nemení, takže obnovenie znamená nový koncový bod.
Pripojenie Client VPN sa preruší, certifikát v ACM sa vymení a nič sa nezmení. Objekt certifikátu nikdy nebol to, čo koncový bod používal. Koncový bod si pri vytvorení uloží asociáciu s certifikátom spolu s klientskou CA, voči ktorej bude overovať, typom overovania, podsietami a pravidlami autorizácie, a žiadna z týchto asociácií nemá volanie na zmenu, ktoré by prijalo náhradný certifikát. Nahradenie bajtov za ARN je zmena certifikátu, nie koncového bodu, ktorý ho zachytil.
Koncový bod ukladá referencie, nie certifikáty
Mechanizmus sa oplatí sformulovať presne, pretože vysvetľuje celú poruchu. create-client-vpn-endpoint preberá ARN serverového certifikátu a ARN reťaze koreňových certifikátov klienta, a výsledný koncový bod si tieto referencie spolu s možnosťami overovania drží ako pevné vlastnosti. API neponúka operáciu, ktorá by na existujúcom koncovom bode vymenila serverový certifikát.
Väzbu môžete potvrdiť bez hádania. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 vypíše ARN certifikátu, ARN klientskej koreňovej reťaze, typ overovania, klientsky CIDR a pridružené podsiete, čo je celá sada vlastností, ktorú by ste museli zreprodukovať. Spustite ho pred opätovným importom a po ňom a výstup sa nepohne. To je dôkaz, že opätovný import nikdy nemohol pomôcť.
Prečo sa opätovný import nemôže dostať ku koncovému bodu
Opätovný import zapíše nové telo certifikátu pod existujúci ARN. Je to legitímna operácia, keď sa certifikát blíži k expirácii, a ACM ju prijme, ak súkromný kľúč sedí a reťaz sa overí. Čo však nerobí, je opätovné spustenie validácie z času vytvorenia koncového bodu, takže asociácia a materiál za ňou zostávajú také, aké boli pri stavbe koncového bodu.
Preto aj symptóm vyzerá ako sieťová porucha. Podanie rúk TLS zlyhá alebo sa resetuje skôr, než sa autorizácia vôbec vyhodnotí, takže bezpečnostné skupiny, trasy a pravidlá autorizácie vyzerajú všetky nevinne, a aj sú.
Reťaz je súčasťou klientskeho certifikátu
Druhá polovica poruchy je v klientskom certifikáte a je ľahšie ju odbiť. Klientsky certifikát sa musí importovať s reťazou, ktorá ho vydala, hoci formulár importu toto pole zobrazuje ako voliteľné. Bez reťaze koncový bod nedokáže zostaviť cestu od klientskeho certifikátu ku klientskej koreňovej CA, s ktorou bol nakonfigurovaný, a spojenie skončí mäkkým resetom, ktorý znie ako firewall zahadzujúci pakety. openssl verify -CAfile root-ca.pem client.crt odpovedá na túto otázku lokálne za sekundu a mal by to byť prvý príkaz, ktorý spustíte.
Opätovný import s reťazou je skutočná oprava pre túto polovicu a napriek tomu sám o sebe nestačí. Keď sa objekt v ACM zmenil, koncový bod s pôvodnou asociáciou je nesprávna vec, voči ktorej pokračovať v testovaní. Oba kroky patria k tej istej oprave, a preto dvojdielna oprava nie je rozpor.
Znovuvytvorenie koncového bodu je migrácia
Vytvorenie náhradného koncového bodu je migrácia, nie opakovanie pokusu, a brať to ako opakovanie je spôsob, akým tímy skončia s dvoma napoly nakonfigurovanými koncovými bodmi. Nový koncový bod dostane nové ID a, ak ste to neplánovali, nové meno DNS pre každého používateľa. Držte klientsky profil ukazujúci na meno, nie na adresu, aby sa výmena stala zmenou záznamu a nie prerozdelením.
Poradie, ktoré to drží v bezpečí, je krátke: vytvorte nový koncový bod s rovnakým CIDR, podsietami a pravidlami autorizácie, exportujte čerstvý profil cez aws ec2 export-client-vpn-client-configuration a overte na jednom používateľovi. Až potom sa starý koncový bod zvesí.
Vyradenie starého koncového bodu má svoje poradie. Odvolajte klientske certifikáty, ktoré ste chceli vyradiť, skôr než ho zmažete, pretože nový koncový bod, ktorý stále dôveruje starej CA, naďalej prijíma certifikáty, o ktorých ste si mysleli, že zmizli. Potom zmažte starý koncový bod a odstráňte jeho pravidlá autorizácie, aby sa zastaraný profil nemohol znova pripojiť k cieľovej sieti, ktorú ste považovali za zatvorenú. Zapíšte ID starého koncového bodu a identifikátory asociácií do záznamu o zmene, pretože migrácia porovnávaná s pamäťou je spôsob, akým sa funkčný koncový bod prestavia dvakrát.
Zoraďte diagnostiku
Oddeľte tri poruchy, kým zmeníte akúkoľvek konfiguráciu. Klient nemôže dokončiť TLS, klient dokončí TLS a nie je autorizovaný, alebo sa klient pripojí a nedosiahne cieľ. Asociácia certifikátu patrí k prvej, pravidlo autorizácie, ktoré nepokrýva adresu klienta, k druhej, a trasa alebo bezpečnostná skupina k tretej, kde je znovuvytvorenie koncového bodu takmer vždy nesprávny krok.
Koncový bod, ktorý mesiace fungoval a potom sa zastavil, bez zmeny certifikátu alebo politiky, je samostatný prípad. Prestavba s rovnakými nastaveniami môže obnoviť službu, ale to je dôvod držať konfiguráciu reprodukovateľnú, nie dôvod prestavovať pri každom incidente.
Držte štyri veci pod kontrolou verzií, aby ďalšia prestavba bola diff a nie improvizácia: parametre koncového bodu, ARN certifikátu a reťaze, pravidlá autorizácie a klientsky CIDR. Dokumentácia overovania Client VPN uvádza, ktorý certifikát hrá akú rolu, čo sa oplatí skontrolovať skôr, než vôbec predpokladáte, že problémom je certifikát. Ak opätovný import nič nezmení a koncový bod sa stále resetuje, podozrivá je asociácia a odpoveďou je nový koncový bod postavený zo zaznamenaných parametrov. Ak koncový bod nový objekt predsa len prevezme, asociácia už bola správna a porucha je v klientskej reťazi alebo v autorizačnej vrstve.