Waarom die herinvoer van ’n Client VPN-sertifikaat ’n nuwe eindpunt vereis

’n Client VPN-verbinding breek, die sertifikaat in ACM word vervang, en niks verander nie. Die sertifikaatobjek was nooit die ding wat die eindpunt gebruik het nie. ’n Eindpunt stoor by skepping ’n assosiasie met ’n sertifikaat, saam met die kliënt-CA waarteen dit sal valideer, die verifikasietipe, die subnetwerke en die magtigingsreëls, en nie een van daardie assosiasies het ’n wysig-oproep wat ’n vervangingsertifikaat aanvaar nie. Om die bytes agter ’n ARN te vervang is ’n verandering aan die sertifikaat, nie aan die eindpunt wat dit vasgelê het nie.

Die eindpunt stoor verwysings, nie sertifikate nie

Die meganisme is die moeite werd om presies te stel, want dit verduidelik die hele mislukking. create-client-vpn-endpoint neem ’n bediener-sertifikaat-ARN en ’n kliëntwortel-sertifikaatketting-ARN, en die resulterende eindpunt hou daardie verwysings plus die verifikasiopsies as vaste eienskappe. Die API-oppervlak bied geen bewerking wat die bediener-sertifikaat op ’n bestaande eindpunt omruil nie.

Jy kan die binding bevestig sonder om te raai. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 druk die sertifikaat-ARN, die kliëntwortelketting-ARN, die verifikasietipe, die kliënt-CIDR en die geassosieerde subnetwerke, wat die volledige stel eienskappe is wat jy sou moes herproduseer. Hardloop dit voor en ná ’n herinvoer en die uitset beweeg nie. Dit is die bewys dat die herinvoer nooit sou help nie.

Waarom ’n herinvoer nie by die eindpunt kan uitkom nie

’n Herinvoer skryf ’n nuwe sertifikaatliggaam onder ’n bestaande ARN. Dit is ’n wettige bewerking wanneer ’n sertifikaat naby verval is, en ACM sal dit aanvaar solank die private sleutel ooreenstem en die ketting valideer. Wat dit nie doen nie, is om die eindpunt se skeppingstyd-validering weer te hardloop, so die assosiasie en die materiaal daaronder bly soos dit was toe die eindpunt gebou is.

Dit is ook waarom die simptoom soos ’n netwerkfout lees. Die TLS-handdruk misluk of stel terug voordat magtiging ooit geëvalueer word, so sekuriteitsgroepe, roetes en magtigingsreëls lyk almal onskuldig, en dit is hulle.

Die ketting is deel van die kliëntsertifikaat

Die tweede helfte van die mislukking is in die kliëntsertifikaat, en dit is makliker om af te maak. ’n Kliëntsertifikaat moet ingevoer word saam met die ketting wat dit uitgereik het, selfs al wys die invoervorm daardie veld as opsioneel. Sonder die ketting kan die eindpunt nie ’n pad bou van die kliëntsertifikaat na die kliëntwortel-CA waarmee dit opgestel is nie, en die verbinding eindig in ’n sagte terugstelling wat lees soos ’n vuurmuur wat pakkette laat val. openssl verify -CAfile root-ca.pem client.crt beantwoord daardie vraag plaaslik in ’n sekonde, en dit behoort die eerste opdrag te wees wat jy hardloop.

Herinvoer saam met die ketting is ’n regte oplossing vir daardie helfte, en dit is steeds nie op sigself genoeg nie. Sodra die ACM-objek verander het, is die eindpunt met die ou assosiasie die verkeerde ding om teen te bly toets. Beide stappe hoort by dieselfde herstel, en daarom is die tweedelige oplossing nie ’n teenstrydigheid nie.

Om ’n eindpunt te herskep is ’n migrasie

Om ’n vervangingseindpunt te skep is ’n migrasie, nie ’n herprobeerslag nie, en om dit as ’n herprobeerslag te behandel, is hoe spanne met twee halfopgestelde eindpunte eindig. Die nuwe eindpunt kry ’n nuwe ID en, tensy jy daarvoor beplan het, ’n nuwe DNS-naam vir elke gebruiker. Hou die kliëntprofiel na ’n naam wys eerder as na ’n adres, sodat die omruiling ’n rekordverandering word in plaas van ’n herverspreiding.

Die volgorde wat dit veilig hou, is kort: skep die nuwe eindpunt met dieselfde CIDR, subnetwerke en magtigingsreëls, voer ’n vars profiel uit met aws ec2 export-client-vpn-client-configuration, en verifieer met een gebruiker. Eers daarna kom die ou eindpunt af.

Om die ou eindpunt uit diens te onttrek het sy eie volgorde. Herroep die kliëntsertifikate wat jy bedoel het om te onttrek voordat jy dit uitvee, want ’n nuwe eindpunt wat steeds die ou CA vertrou, bly sertifikate aanvaar wat jy gedink het weg is. Vee dan die ou eindpunt uit en verwyder sy magtigingsreëls, sodat ’n verouderde profiel nie weer aan ’n teikennetwerk kan koppel wat jy gedink het toe is nie. Skryf die ou eindpunt-ID en die assosiasie-identifiseerders in die veranderingsrekord, want ’n migrasie wat teen geheue vergelyk word, is hoe ’n werkende eindpunt twee keer herbou word.

Orden die diagnose

Skei drie mislukkings voordat jy enige opstelling verander. Die kliënt kan TLS nie voltooi nie, die kliënt voltooi TLS en is nie gemagtig nie, of die kliënt koppel en kan nie ’n bestemming bereik nie. Sertifikaatassosiasie hoort by die eerste, ’n magtigingsreël wat nie die kliëntadres dek nie hoort by die tweede, en ’n roete of sekuriteitsgroep hoort by die derde, waar die herskep van ’n eindpunt amper altyd die verkeerde skuif is.

’n Eindpunt wat maande lank gewerk het en toe stop, sonder enige sertifikaat- of beleidsverandering, is ’n geval op sy eie. Om dit met identiese instellings te herbou kan die diens herstel, maar dit is ’n rede om die opstelling herproduseerbaar te hou, eerder as ’n rede om by elke voorval te herbou.

Hou vier dinge in weergawebeheer sodat die volgende herbou ’n diff is in plaas van ’n improvisasie: die eindpuntparameters, die sertifikaat- en ketting-ARN's, die magtigingsreëls en die kliënt-CIDR. Die Client VPN-verifikasiedokumentasie lys watter sertifikaat watter rol speel, wat die moeite werd is om na te gaan voordat jy aanvaar dat ’n sertifikaat hoegenaamd die probleem is. As ’n herinvoer niks verander nie en die eindpunt stel steeds terug, is die assosiasie die verdagte en is die antwoord ’n nuwe eindpunt wat uit die opgetekende parameters gebou is. As die eindpunt wel die nuwe objek optel, was die assosiasie reeds korrek en sit die fout in die kliëntketting of die magtigingslaag.