Waarom opnieuw importeren van een Client VPN-certificaat een nieuw eindpunt vereist

Een Client VPN-verbinding valt weg, het certificaat in ACM wordt vervangen, en er verandert niets. Het certificaatobject was nooit wat het eindpunt gebruikte. Een eindpunt slaat bij het aanmaken een koppeling naar een certificaat op, samen met de client-CA waartegen het valideert, het authenticatietype, de subnetten en de autorisatieregels, en geen van die koppelingen heeft een wijzigingsaanroep die een vervangend certificaat accepteert. De bytes achter een ARN vervangen is een wijziging aan het certificaat, niet aan het eindpunt dat ze vastlegde.

Het eindpunt slaat verwijzingen op, geen certificaten

Het mechanisme verdient een precieze formulering omdat het de hele storing verklaart. create-client-vpn-endpoint neemt een ARN van een servercertificaat en een ARN van een client-rootcertificaatketen, en het resulterende eindpunt bewaart die verwijzingen plus de authenticatieopties als vaste eigenschappen. De API biedt geen bewerking die het servercertificaat op een bestaand eindpunt vervangt.

U kunt de koppeling bevestigen zonder te gissen. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 drukt de ARN van het certificaat, de ARN van de client-rootketen, het authenticatietype, de client-CIDR en de bijbehorende subnetten af, dat is de volledige set eigenschappen die u zou moeten nabootsen. Voer het voor en na een nieuwe import uit en de uitvoer beweegt niet. Dat is het bewijs dat de nieuwe import nooit zou helpen.

Waarom een nieuwe import het eindpunt niet kan bereiken

Een nieuwe import schrijft een nieuw certificaatlichaam onder een bestaande ARN. Dat is een legitieme bewerking wanneer een certificaat bijna verloopt, en ACM accepteert die zolang de privésleutel overeenkomt en de keten valideert. Wat ze niet doet, is de validatie van het aanmaakmoment van het eindpunt opnieuw uitvoeren, dus de koppeling en het materiaal erachter blijven zoals ze waren toen het eindpunt werd gebouwd.

Daarom leest het symptoom ook als een netwerkstoring. De TLS-handshake mislukt of wordt gereset voordat de autorisatie ooit wordt beoordeeld, dus beveiligingsgroepen, routes en autorisatieregels lijken allemaal onschuldig, en dat zijn ze.

De keten maakt deel uit van het clientcertificaat

De tweede helft van de storing zit in het clientcertificaat, en die is makkelijker weg te schuiven. Een clientcertificaat moet worden geïmporteerd met de keten die het heeft uitgegeven, ook al toont het importformulier dat veld als optioneel. Zonder de keten kan het eindpunt geen pad bouwen van het clientcertificaat naar de client-root-CA waarmee het is geconfigureerd, en de verbinding eindigt in een zachte reset die klinkt als een firewall die pakketten laat vallen. openssl verify -CAfile root-ca.pem client.crt beantwoordt die vraag lokaal in een seconde, en het zou de eerste opdracht moeten zijn die u uitvoert.

Opnieuw importeren met de keten is een echte correctie voor die helft, en toch is ze op zichzelf niet genoeg. Zodra het ACM-object is gewijzigd, is het eindpunt met de oude koppeling het verkeerde ding om tegen te blijven testen. Beide stappen horen bij dezelfde reparatie, daarom is de tweedelige correctie geen tegenstrijdigheid.

Een eindpunt opnieuw aanmaken is een migratie

Een vervangend eindpunt aanmaken is een migratie, geen nieuwe poging, en het als een nieuwe poging behandelen is hoe teams met twee half geconfigureerde eindpunten eindigen. Het nieuwe eindpunt krijgt een nieuwe ID en, tenzij u dat plande, een nieuwe DNS-naam voor elke gebruiker. Houd het clientprofiel naar een naam wijzen in plaats van naar een adres, zodat de omwisseling een recordwijziging wordt en geen herverdeling.

De volgorde die dit veilig houdt is kort: maak het nieuwe eindpunt met dezelfde CIDR, subnetten en autorisatieregels, exporteer een vers profiel met aws ec2 export-client-vpn-client-configuration, en verifieer met één gebruiker. Pas daarna gaat het oude eindpunt eraf.

Het buiten gebruik stellen van het oude eindpunt heeft zijn eigen volgorde. Trek de clientcertificaten die u wilde uitfaseren in voordat u het verwijdert, want een nieuw eindpunt dat de oude CA nog vertrouwt blijft certificaten accepteren waarvan u dacht dat ze weg waren. Verwijder daarna het oude eindpunt en zijn autorisatieregels, zodat een verouderd profiel niet opnieuw verbinding kan maken met een doelsnetwerk waarvan u dacht dat het dicht was. Schrijf de ID van het oude eindpunt en de koppelingsidentificaties in het wijzigingsrecord, want een migratie die met het geheugen wordt vergeleken is hoe een werkend eindpunt twee keer wordt herbouwd.

Orden de diagnose

Scheid drie storingen voordat u enige configuratie wijzigt. De client kan TLS niet voltooien, de client voltooit TLS en is niet geautoriseerd, of de client maakt verbinding en bereikt geen bestemming. Certificaatkoppeling hoort bij de eerste, een autorisatieregel die het clientadres niet dekt bij de tweede, en een route of beveiligingsgroep bij de derde, waar het opnieuw aanmaken van een eindpunt bijna altijd de verkeerde zet is.

Een eindpunt dat maanden werkte en toen stopte, zonder wijziging van certificaat of beleid, is een apart geval. Het met identieke instellingen herbouwen kan de dienst herstellen, maar dat is een reden om de configuratie reproduceerbaar te houden, geen reden om bij elk incident te herbouwen.

Houd vier dingen onder versiebeheer zodat de volgende herbouw een diff is en geen improvisatie: de eindpuntparameters, de ARN's van certificaat en keten, de autorisatieregels en de client-CIDR. De documentatie over Client VPN-authenticatie vermeldt welk certificaat welke rol speelt, wat het waard is te controleren voordat u überhaupt aanneemt dat een certificaat het probleem is. Als een nieuwe import niets verandert en het eindpunt reset nog steeds, is de koppeling de verdachte en is het antwoord een nieuw eindpunt gebouwd uit de vastgelegde parameters. Als het eindpunt het nieuwe object wel oppikt, was de koppeling al correct en zit de fout in de clientketen of de autorisatielaag.