Hvorfor genimport af et Client VPN-certifikat kræver et nyt slutpunkt

En Client VPN-forbindelse bryder sammen, certifikatet i ACM erstattes, og intet ændrer sig. Certifikatobjektet var aldrig det, slutpunktet brugte. Et slutpunkt gemmer ved oprettelsen en tilknytning til et certifikat sammen med den klient-CA, det vil validere imod, godkendelsestypen, undernettene og autorisationsreglerne, og ingen af disse tilknytninger har et ændringskald, der accepterer et erstatningscertifikat. At erstatte bytes bag en ARN er en ændring af certifikatet, ikke af det slutpunkt, der fangede det.

Slutpunktet gemmer referencer, ikke certifikater

Mekanismen fortjener en præcis formulering, fordi den forklarer hele fejlen. create-client-vpn-endpoint tager en ARN til et servercertifikat og en ARN til en klientrodcertifikatkæde, og det resulterende slutpunkt beholder disse referencer plus godkendelsesindstillingerne som faste egenskaber. API-overfladen tilbyder ingen handling, der udskifter servercertifikatet på et eksisterende slutpunkt.

Du kan bekræfte bindingen uden at gætte. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 udskriver certifikatets ARN, klientrodkædens ARN, godkendelsestypen, klientens CIDR og de tilknyttede undernet, hvilket er det fulde sæt egenskaber, du ville skulle genskabe. Kør den før og efter en genimport, og outputtet flytter sig ikke. Det er beviset på, at genimporten aldrig kunne hjælpe.

Hvorfor en genimport ikke kan nå slutpunktet

En genimport skriver et nyt certifikatlegeme under en eksisterende ARN. Det er en legitim handling, når et certifikat er tæt på udløb, og ACM accepterer den, så længe den private nøgle matcher, og kæden validerer. Det, den ikke gør, er at køre slutpunktets validering fra oprettelsen igen, så tilknytningen og materialet bag den forbliver, som det var, da slutpunktet blev bygget.

Det er også derfor symptomet lyder som en netværksfejl. TLS-håndtrykket fejler eller nulstilles, før autorisationen overhovedet vurderes, så sikkerhedsgrupper, ruter og autorisationsregler alle ser uskyldige ud, og det er de.

Kæden er en del af klientcertifikatet

Den anden halvdel af fejlen ligger i klientcertifikatet, og den er lettere at afvise. Et klientcertifikat skal importeres med den kæde, der udstedte det, selvom importformularen viser det felt som valgfrit. Uden kæden kan slutpunktet ikke bygge en sti fra klientcertifikatet til den klientrod-CA, det blev konfigureret med, og forbindelsen ender i en blød nulstilling, der lyder som en firewall, der taber pakker. openssl verify -CAfile root-ca.pem client.crt besvarer det spørgsmål lokalt på et sekund, og det bør være den første kommando, du kører.

Genimport med kæden er en rigtig rettelse for den halvdel, og det er stadig ikke nok i sig selv. Når først ACM-objektet er ændret, er slutpunktet med den gamle tilknytning det forkerte at blive ved med at teste imod. Begge trin hører til samme reparation, og derfor er den todelte rettelse ikke en modsætning.

At genskabe et slutpunkt er en migrering

At oprette et erstatningsslutpunkt er en migrering, ikke et nyt forsøg, og at behandle det som et nyt forsøg er måden, hvorpå teams ender med to halvkonfigurerede slutpunkter. Det nye slutpunkt får et nyt ID og, medmindre du planlagde det, et nyt DNS-navn til hver bruger. Hold klientprofilen pegende på et navn i stedet for en adresse, så udskiftningen bliver en postændring i stedet for en ny udrulning.

Den rækkefølge, der holder det sikkert, er kort: opret det nye slutpunkt med samme CIDR, undernet og autorisationsregler, eksportér en frisk profil med aws ec2 export-client-vpn-client-configuration, og verificér med én bruger. Først derefter tages det gamle slutpunkt ned.

Afviklingen af det gamle slutpunkt har sin egen rækkefølge. Tilbagekald de klientcertifikater, du ville afvikle, før du sletter det, fordi et nyt slutpunkt, der stadig stoler på den gamle CA, fortsætter med at acceptere certifikater, du troede var væk. Slet derefter det gamle slutpunkt, og fjern dets autorisationsregler, så en forældet profil ikke kan genoprette forbindelsen til et målnetværk, du troede var lukket. Skriv det gamle slutpunkts ID og tilknytningsidentifikatorerne i ændringsposten, fordi en migrering sammenlignet med hukommelsen er måden, hvorpå et fungerende slutpunkt bliver genopbygget to gange.

Sæt rækkefølge på diagnosen

Adskil tre fejl, før du ændrer nogen konfiguration. Klienten kan ikke fuldføre TLS, klienten fuldfører TLS og er ikke autoriseret, eller klienten opretter forbindelse og kan ikke nå en destination. Certifikattilknytning hører til den første, en autorisationsregel, der ikke dækker klientens adresse, hører til den anden, og en rute eller sikkerhedsgruppe hører til den tredje, hvor det næsten altid er det forkerte træk at genskabe et slutpunkt.

Et slutpunkt, der virkede i månedsvis og derefter stoppede, uden ændringer af certifikat eller politik, er sin egen sag. At genopbygge det med identiske indstillinger kan genoprette tjenesten, men det er en grund til at holde konfigurationen reproducerbar, ikke en grund til at genopbygge ved hver hændelse.

Hold fire ting under versionskontrol, så den næste genopbygning er en diff i stedet for en improvisation: slutpunktets parametre, certifikat- og kæde-ARN’er, autorisationsreglerne og klientens CIDR. Dokumentationen for Client VPN-godkendelse angiver, hvilket certifikat der spiller hvilken rolle, hvilket er værd at tjekke, før du overhovedet antager, at et certifikat er problemet. Hvis en genimport ikke ændrer noget, og slutpunktet stadig nulstilles, er tilknytningen den mistænkte, og svaret er et nyt slutpunkt bygget ud fra de registrerede parametre. Hvis slutpunktet faktisk samler det nye objekt op, var tilknytningen allerede korrekt, og fejlen ligger i klientkæden eller autorisationslaget.