Proč nový import klientského certifikátu Client VPN vyžaduje nový koncový bod

Spojení Client VPN se přeruší, certifikát v ACM se vymění a nic se nezmění. Objekt certifikátu nikdy nebyl to, co koncový bod používal. Koncový bod si při vytvoření ukládá asociaci s certifikátem, spolu s klientskou CA, proti které bude ověřovat, typem ověřování, podsítěmi a pravidly autorizace, a žádná z těchto asociací nemá volání pro změnu, které by přijalo náhradní certifikát. Nahrazení bajtů za ARN je změna certifikátu, ne koncového bodu, který ho zachytil.

Koncový bod ukládá reference, ne certifikáty

Mechanismus stojí za přesnou formulaci, protože vysvětluje celou závadu. create-client-vpn-endpoint bere ARN certifikátu serveru a ARN řetězu kořenových certifikátů klienta a výsledný koncový bod si tyto reference spolu s možnostmi ověřování drží jako pevné vlastnosti. API nenabízí operaci, která by na existujícím koncovém bodu vyměnila certifikát serveru.

Vazbu můžete potvrdit bez hádání. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 vypíše ARN certifikátu, ARN klientského kořenového řetězu, typ ověřování, klientský CIDR a přidružené podsítě, což je celá sada vlastností, kterou byste museli zreprodukovat. Spusťte ho před novým importem a po něm a výstup se nehne. To je důkaz, že nový import nikdy nemohl pomoci.

Proč se nový import nemůže dostat ke koncovému bodu

Nový import zapíše nové tělo certifikátu pod existující ARN. To je legitimní operace, když se certifikát blíží expiraci, a ACM ji přijme, pokud soukromý klíč odpovídá a řetěz se ověří. Co však neudělá, je opětovné spuštění validace z doby vytvoření koncového bodu, takže asociace a materiál za ní zůstávají tak, jak byly při stavbě koncového bodu.

Proto i symptom vypadá jako síťová závada. TLS handshake selže nebo se resetuje dřív, než se autorizace vůbec vyhodnotí, takže skupiny zabezpečení, trasy a pravidla autorizace vypadají nevinně, a také jsou.

Řetěz je součástí klientského certifikátu

Druhá polovina závady je v klientském certifikátu a je snazší ji odbýt. Klientský certifikát se musí importovat s řetězem, který ho vydal, i když formulář importu toto pole zobrazuje jako volitelné. Bez řetězu koncový bod nedokáže sestavit cestu od klientského certifikátu ke klientské kořenové CA, se kterou byl nakonfigurován, a spojení skončí měkkým resetem, který vypadá jako firewall zahazující pakety. openssl verify -CAfile root-ca.pem client.crt odpovídá na tuto otázku lokálně za sekundu a měl by to být první příkaz, který spustíte.

Nový import s řetězem je skutečná oprava pro tuto polovinu a přesto sám o sobě nestačí. Jakmile se objekt v ACM změní, koncový bod s původní asociací je špatná věc, proti které pokračovat v testování. Oba kroky patří ke stejné opravě, a proto dvoudílná oprava není rozpor.

Znovuvytvoření koncového bodu je migrace

Vytvoření náhradního koncového bodu je migrace, ne opakování pokusu, a brát to jako opakování je způsob, jak týmy skončí se dvěma napůl nakonfigurovanými koncovými body. Nový koncový bod dostane nové ID a, pokud jste s tím nepočítali, nové jméno DNS pro každého uživatele. Držte klientský profil ukazující na jméno, ne na adresu, aby se výměna stala změnou záznamu, a ne přerozdělením.

Pořadí, které to drží v bezpečí, je krátké: vytvořte nový koncový bod se stejným CIDR, podsítěmi a pravidly autorizace, exportujte čerstvý profil pomocí aws ec2 export-client-vpn-client-configuration a ověřte na jednom uživateli. Teprve potom se starý koncový bod sundá.

Vyřazení starého koncového bodu má své pořadí. Odvolejte klientské certifikáty, které jste chtěli vyřadit, než ho smažete, protože nový koncový bod, který stále důvěřuje staré CA, dál přijímá certifikáty, o nichž jste mysleli, že zmizely. Pak starý koncový bod smažte a odstraňte jeho pravidla autorizace, aby se zastaralý profil nemohl znovu připojit k cílové síti, kterou jste považovali za zavřenou. Zapište ID starého koncového bodu a identifikátory asociací do záznamu o změně, protože migrace porovnávaná s pamětí je způsob, jak se funkční koncový bod přestaví dvakrát.

Seřaďte diagnostiku

Oddělte tři závady, než změníte jakoukoli konfiguraci. Klient nemůže dokončit TLS, klient dokončí TLS a není autorizován, nebo se klient připojí a nemůže dosáhnout cíle. Asociace certifikátu patří k první, pravidlo autorizace, které nepokrývá adresu klienta, ke druhé, a trasa nebo skupina zabezpečení ke třetí, kde je znovuvytvoření koncového bodu téměř vždy špatný krok.

Koncový bod, který měsíce fungoval a pak se zastavil, bez jakékoli změny certifikátu nebo politiky, je samostatný případ. Přestavba se stejnými nastaveními může obnovit službu, ale to je důvod držet konfiguraci reprodukovatelnou, ne důvod přestavovat při každém incidentu.

Držte čtyři věci pod kontrolou verzí, aby příští přestavba byla diff a ne improvizace: parametry koncového bodu, ARN certifikátu a řetězu, pravidla autorizace a klientský CIDR. Dokumentace ověřování Client VPN uvádí, který certifikát hraje jakou roli, což stojí za kontrolu dřív, než vůbec předpokládáte, že problémem je certifikát. Pokud nový import nic nezmění a koncový bod se pořád resetuje, podezřelá je asociace a odpovědí je nový koncový bod postavený ze zaznamenaných parametrů. Pokud koncový bod nový objekt přeci jen převezme, asociace už byla správná a závada je v klientském řetězu nebo v autorizační vrstvě.