Zakaj ponovni uvoz odjemalskega potrdila Client VPN zahteva novo končno točko

Povezava Client VPN se prekine, potrdilo v ACM se zamenja in nič se ne spremeni. Predmet potrdila nikoli ni bil tisto, kar je uporabljala končna točka. Končna točka ob ustvarjanju shrani povezavo s potrdilom, skupaj z odjemalskim CA, glede na katerega bo preverjala, vrsto preverjanja pristnosti, podomrežji in pravili dovoljenj, in nobena od teh povezav nima klica za spremembo, ki bi sprejel nadomestno potrdilo. Zamenjava bajtov za ARN je sprememba potrdila, ne končne točke, ki ga je zajela.

Končna točka shranjuje sklice, ne potrdil

Mehanizem velja natančno formulirati, ker pojasnjuje celotno okvaro. create-client-vpn-endpoint sprejme ARN strežniškega potrdila in ARN verige korenskih potrdil odjemalca, nastala končna točka pa te sklice skupaj z možnostmi preverjanja pristnosti hrani kot fiksne lastnosti. API ne ponuja operacije, ki bi na obstoječi končni točki zamenjala strežniško potrdilo.

Povezavo lahko potrdite brez ugibanja. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 izpiše ARN potrdila, ARN odjemalske korenske verige, vrsto preverjanja pristnosti, odjemalski CIDR in povezana podomrežja, kar je celoten nabor lastnosti, ki bi jih morali poustvariti. Zaženite ga pred ponovnim uvozom in po njem, izpis pa se ne premakne. To je dokaz, da ponovni uvoz nikoli ne bi pomagal.

Zakaj ponovni uvoz ne more doseči končne točke

Ponovni uvoz zapiše novo telo potrdila pod obstoječi ARN. To je zakonita operacija, ko je potrdilo blizu izteka, in ACM jo bo sprejel, če se zasebni ključ ujema in se veriga preveri. Česar pa ne naredi, je ponovno izvajanje preverjanja iz časa ustvarjanja končne točke, zato povezava in gradivo za njo ostaneta takšna, kakršna sta bila ob gradnji končne točke.

Zato se tudi simptom bere kot omrežna okvara. Rokovanje TLS spodleti ali se ponastavi, preden se dovoljenje sploh oceni, zato varnostne skupine, poti in pravila dovoljenj izgledajo nedolžni, in tudi so.

Veriga je del odjemalskega potrdila

Druga polovica okvare je v odjemalskem potrdilu in jo je lažje odpisati. Odjemalsko potrdilo je treba uvoziti z verigo, ki ga je izdala, čeprav obrazec za uvoz to polje prikazuje kot neobvezno. Brez verige končna točka ne more zgraditi poti od odjemalskega potrdila do odjemalskega korenskega CA, s katerim je bila nastavljena, povezava pa se konča v mehki ponastavitvi, ki se sliši kot požarni zid, ki spušča pakete. openssl verify -CAfile root-ca.pem client.crt na to vprašanje odgovori lokalno v sekundi, in to bi moral biti prvi ukaz, ki ga zaženete.

Ponovni uvoz z verigo je prava poprava za to polovico in vendar sama po sebi ni dovolj. Ko se predmet v ACM spremeni, je končna točka s staro povezavo napačna stvar, glede na katero nadaljevati s preizkušanjem. Oba koraka sodita k isti popravi, zato dvodelna poprava ni protislovje.

Ponovno ustvarjanje končne točke je selitev

Ustvarjanje nadomestne končne točke je selitev, ne ponovni poskus, in obravnavanje tega kot ponovnega poskusa je pot, po kateri ekipe končajo z dvema napol nastavljenima končnima točkama. Nova končna točka dobi novo ID in, če tega niste načrtovali, novo ime DNS za vsakega uporabnika. Držite odjemalski profil usmerjen na ime in ne na naslov, da zamenjava postane sprememba zapisa in ne prerazporeditev.

Vrstni red, ki to ohranja varno, je kratek: ustvarite novo končno točko z istim CIDR, podomrežji in pravili dovoljenj, izvozite svež profil z aws ec2 export-client-vpn-client-configuration in preverite z enim uporabnikom. Šele nato se stara končna točka odstrani.

Umik stare končne točke ima svoj vrstni red. Prekličite odjemalska potrdila, ki ste jih nameravali umakniti, preden jo izbrišete, ker nova končna točka, ki še zaupa staremu CA, še naprej sprejema potrdila, za katera ste mislili, da so izginila. Nato izbrišite staro končno točko in odstranite njena pravila dovoljenj, da se zastarel profil ne more znova povezati s ciljnim omrežjem, za katero ste mislili, da je zaprto. Zapišite ID stare končne točke in identifikatorje povezav v zapis sprememb, ker je selitev, primerjana s spominom, pot, po kateri se delujoča končna točka znova zgradi dvakrat.

Uredite diagnozo

Ločite tri okvare, preden spremenite katero koli konfiguracijo. Odjemalec ne more dokončati TLS, odjemalec dokonča TLS in ni pooblaščen, ali odjemalec se poveže in ne doseže cilja. Povezava s potrdilom pripada prvi, pravilo dovoljenj, ki ne pokriva odjemalskega naslova, drugi, pot ali varnostna skupina pa tretji, kjer je ponovno ustvarjanje končne točke skoraj vedno napačna poteza.

Končna točka, ki je delovala mesece in se nato ustavila, brez spremembe potrdila ali politike, je ločen primer. Njena ponovna gradnja z enakimi nastavitvami lahko obnovi storitev, vendar je to razlog za ohranjanje konfiguracije ponovljive, ne razlog za ponovno gradnjo ob vsakem incidentu.

Držite štiri stvari pod nadzorom različic, da bo naslednja ponovna gradnja diff in ne improvizacija: parametre končne točke, ARN potrdila in verige, pravila dovoljenj in odjemalski CIDR. Dokumentacija preverjanja pristnosti Client VPN navaja, katero potrdilo igra katero vlogo, kar velja preveriti, preden sploh domnevate, da je potrdilo težava. Če ponovni uvoz ne spremeni ničesar in se končna točka še vedno ponastavlja, je sumljiva povezava in odgovor je nova končna točka, zgrajena iz zabeleženih parametrov. Če končna točka vendarle prevzame novi predmet, je bila povezava že pravilna in okvara je v odjemalski verigi ali plasti dovoljenj.