Hvorfor ny import av et Client VPN-sertifikat krever et nytt endepunkt

En Client VPN-tilkobling bryter sammen, sertifikatet i ACM erstattes, og ingenting endres. Sertifikatobjektet var aldri det endepunktet brukte. Et endepunkt lagrer ved opprettelsen en tilknytning til et sertifikat, sammen med klient-CA-en det skal validere mot, autentiseringstypen, subnettene og autorisasjonsreglene, og ingen av disse tilknytningene har et endringskall som godtar et erstatningssertifikat. Å erstatte bytene bak en ARN er en endring av sertifikatet, ikke av endepunktet som fanget det.

Endepunktet lagrer referanser, ikke sertifikater

Mekanismen fortjener en presis formulering fordi den forklarer hele feilen. create-client-vpn-endpoint tar en ARN for et serversertifikat og en ARN for en klientrotsertifikatkjede, og endepunktet som oppstår beholder disse referansene pluss autentiseringsvalgene som faste egenskaper. API-flaten tilbyr ingen operasjon som bytter serversertifikatet på et eksisterende endepunkt.

Du kan bekrefte bindingen uten å gjette. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 skriver ut sertifikatets ARN, klientrotkjedens ARN, autentiseringstypen, klientens CIDR og de tilknyttede subnettene, som er hele settet med egenskaper du måtte gjenskape. Kjør den før og etter en ny import, og utdataene flytter seg ikke. Det er beviset på at den nye importen aldri kunne hjelpe.

Hvorfor en ny import ikke kan nå endepunktet

En ny import skriver en ny sertifikatkropp under en eksisterende ARN. Det er en legitim operasjon når et sertifikat nærmer seg utløp, og ACM godtar den så lenge den private nøkkelen stemmer og kjeden valideres. Det den ikke gjør, er å kjøre valideringen fra opprettelsen av endepunktet på nytt, så tilknytningen og materialet bak den forblir slik det var da endepunktet ble bygget.

Det er også derfor symptomet leses som en nettverksfeil. TLS-håndtrykket feiler eller tilbakestilles før autorisasjonen i det hele tatt vurderes, så sikkerhetsgrupper, ruter og autorisasjonsregler ser alle uskyldige ut, og det er de.

Kjeden er en del av klientsertifikatet

Den andre halvdelen av feilen ligger i klientsertifikatet, og den er lettere å avvise. Et klientsertifikat må importeres med kjeden som utstedte det, selv om importskjemaet viser feltet som valgfritt. Uten kjeden kan ikke endepunktet bygge en sti fra klientsertifikatet til klientrot-CA-en det ble konfigurert med, og tilkoblingen ender i en myk tilbakestilling som høres ut som en brannmur som slipper pakker. openssl verify -CAfile root-ca.pem client.crt svarer på det spørsmålet lokalt på et sekund, og det bør være den første kommandoen du kjører.

Ny import med kjeden er en reell rettelse for den halvdelen, og den er fortsatt ikke nok alene. Når ACM-objektet først er endret, er endepunktet med den gamle tilknytningen det gale å fortsette å teste mot. Begge trinnene hører til samme reparasjon, og derfor er den todelte rettelsen ikke en motsetning.

Å gjenopprette et endepunkt er en migrering

Å opprette et erstatningsendepunkt er en migrering, ikke et nytt forsøk, og å behandle det som et nytt forsøk er måten team ender opp med to halvkonfigurerte endepunkter. Det nye endepunktet får en ny ID og, med mindre du planla det, et nytt DNS-navn for hver bruker. Hold klientprofilen pekende på et navn i stedet for en adresse, slik at byttet blir en postendring i stedet for en ny distribusjon.

Rekkefølgen som holder dette trygt, er kort: opprett det nye endepunktet med samme CIDR, subnett og autorisasjonsregler, eksporter en fersk profil med aws ec2 export-client-vpn-client-configuration, og verifiser med én bruker. Først etter det tas det gamle endepunktet ned.

Avviklingen av det gamle endepunktet har sin egen rekkefølge. Tilbakekall klientsertifikatene du ville avvikle, før du sletter det, fordi et nytt endepunkt som fortsatt stoler på den gamle CA-en fortsetter å godta sertifikater du trodde var borte. Slett deretter det gamle endepunktet og fjern autorisasjonsreglene, slik at en utdatert profil ikke kan koble seg til et målnettverk du trodde var lukket. Skriv det gamle endepunktets ID og tilknytningsidentifikatorene i endringsposten, fordi en migrering sammenlignet med hukommelsen er måten et fungerende endepunkt blir gjenoppbygd to ganger.

Sett rekkefølge på diagnosen

Skil tre feil før du endrer noen konfigurasjon. Klienten kan ikke fullføre TLS, klienten fullfører TLS og er ikke autorisert, eller klienten kobler til og når ikke en destinasjon. Sertifikattilknytningen hører til den første, en autorisasjonsregel som ikke dekker klientadressen hører til den andre, og en rute eller sikkerhetsgruppe hører til den tredje, der det nesten alltid er feil trekk å gjenopprette et endepunkt.

Et endepunkt som virket i månedsvis og deretter stoppet, uten endring av sertifikat eller policy, er sitt eget tilfelle. Å bygge det på nytt med identiske innstillinger kan gjenopprette tjenesten, men det er en grunn til å holde konfigurasjonen reproduserbar, ikke en grunn til å bygge på nytt ved hver hendelse.

Hold fire ting under versjonskontroll slik at neste gjenoppbygging blir en diff og ikke en improvisasjon: endepunktets parametere, ARN-ene for sertifikatet og kjeden, autorisasjonsreglene og klientens CIDR. Dokumentasjonen for Client VPN-autentisering viser hvilket sertifikat som spiller hvilken rolle, noe det er verdt å sjekke før du i det hele tatt antar at et sertifikat er problemet. Hvis en ny import ikke endrer noe og endepunktet fortsatt tilbakestilles, er tilknytningen den mistenkte, og svaret er et nytt endepunkt bygget fra de registrerte parameterne. Hvis endepunktet faktisk tar opp det nye objektet, var tilknytningen allerede korrekt, og feilen sitter i klientkjeden eller autorisasjonslaget.