Pse riimportimi i një certifikate Client VPN kërkon një pikë fundore të re

Një lidhje Client VPN prishet, certifikata në ACM zëvendësohet dhe asgjë nuk ndryshon. Objekti i certifikatës nuk ishte kurrë ai që përdorte pika fundore. Pika fundore ruan në krijim një asociim me një certifikatë, bashkë me CA-në e klientit kundrejt së cilës do të vërtetojë, llojin e vërtetimit, nënrrjetet dhe rregullat e autorizimit, dhe asnjë prej këtyre asociacioneve nuk ka një thirrje ndryshimi që pranon një certifikatë zëvendësuese. Zëvendësimi i bajtëve pas një ARN është një ndryshim në certifikatë, jo në pikën fundore që e kaptoi.

Pika fundore ruan referenca, jo certifikata

Mekanizmi meriton të formulohet me saktësi, sepse shpjegon të gjithë dështimin. create-client-vpn-endpoint merr një ARN të certifikatës së serverit dhe një ARN të zinxhirit të certifikatave rrënjë të klientit, dhe pika fundore që rezulton i mban ato referenca bashkë me opsionet e vërtetimit si veti fikse. API-ja nuk ofron asnjë operacion që ndërron certifikatën e serverit në një pikë fundore ekzistuese.

Mund ta konfirmoni lidhjen pa hamendësuar. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 printon ARN-në e certifikatës, ARN-në e zinxhirit rrënjë të klientit, llojin e vërtetimit, CIDR-në e klientit dhe nënrrjetet përkatëse, që është grupi i plotë i vetive që do t'ju duhej të riprodhoni. Ekzekutojeni para dhe pas një riimportimi dhe dalja nuk lëviz. Kjo është prova se riimportimi nuk do të ndihmonte kurrë.

Pse një riimportim nuk mund të arrijë pikën fundore

Një riimportim shkruan një trup të re certifikate nën një ARN ekzistuese. Ky është një operacion i ligjshëm kur një certifikatë është afër skadimit, dhe ACM do ta pranojë për sa kohë çelësi privat përputhet dhe zinxhiri vërtetohet. Ajo që nuk bën është të ekzekutojë sërish vërtetimin e momentit të krijimit të pikës fundore, kështu që asociimi dhe materiali pas tij mbeten ashtu si ishin kur u ndërtua pika fundore.

Kjo është arsyeja pse simptoma lexohet si një defekt rrjeti. Shtrëngimi i duarve TLS dështon ose rivendoset para se autorizimi të vlerësohet fare, kështu që grupet e sigurisë, rrugët dhe rregullat e autorizimit duken të gjitha të pafajshme, dhe janë.

Zinxhiri është pjesë e certifikatës së klientit

Gjysma e dytë e dështimit është në certifikatën e klientit, dhe është më e lehtë për t'u hedhur poshtë. Një certifikatë klienti duhet të importohet me zinxhirin që e lëshoi, edhe pse formulari i importimit e paraqet atë fushë si opsionale. Pa zinxhirin pika fundore nuk mund të ndërtojë një rrugë nga certifikata e klientit deri te CA-ja rrënjë e klientit me të cilën u konfigurua, dhe lidhja përfundon në një rivendosje të butë që tingëllon si një mur zjarri që hedh paketat. openssl verify -CAfile root-ca.pem client.crt i përgjigjet asaj pyetjeje lokalisht në një sekondë, dhe duhet të jetë komanda e parë që ekzekutoni.

Riimportimi me zinxhirin është një korrigjim i vërtetë për atë gjysmë, dhe megjithatë nuk mjafton vetëm. Pasi objekti në ACM ka ndryshuar, pika fundore që mban asociimin e vjetër është gjëja e gabuar kundrejt së cilës të vazhdoni testimin. Të dy hapat i përkasin të njëjtit riparim, prandaj korrigjimi dy-pjesësh nuk është kontradiktë.

Rikrijimi i një pike fundore është një migrim

Krijimi i një pike fundore zëvendësuese është një migrim, jo një provë e re, dhe trajtimi i saj si provë e re është mënyra se si ekipet përfundojnë me dy pika fundore gjysmë të konfiguruara. Pika fundore e re merr një ID të re dhe, nëse nuk e keni planifikuar, një emër DNS të re për çdo përdorues. Mbajeni profilin e klientit duke treguar nga një emër dhe jo nga një adresë, që ndërrimi të bëhet një ndryshim regjistri dhe jo një rishpërndarje.

Rendi që e mban këtë të sigurt është i shkurtër: krijoni pikën fundore të re me të njëjtën CIDR, nënrrjete dhe rregulla autorizimi, eksportoni një profil të freskët me aws ec2 export-client-vpn-client-configuration, dhe verifikoni me një përdorues. Vetëm pas kësaj pika fundore e vjetër hiqet.

Tërheqja e pikës fundore të vjetër ka rendin e vet. Revokoni certifikatat e klientëve që kishit ndër mend të tërhiqnit përpara se ta fshini, sepse një pikë fundore e re që ende i beson CA-së së vjetër vazhdon të pranojë certifikata që mendonit se kishin shkuar. Më pas fshini pikën fundore të vjetër dhe hiqni rregullat e saj të autorizimit, që një profil i vjetëruar të mos mund të rilidhet me një rrjet destinacioni që mendonit se ishte i mbyllur. Shkruani ID-në e pikës fundore të vjetër dhe identifikuesit e asociimit në regjistrin e ndryshimeve, sepse një migrim i krahasuar me memorien është mënyra se si një pikë fundore funksionale rindërtohet dy herë.

Renditni diagnozën

Ndani tre dështime përpara se të ndryshoni çfarëdo konfigurimi. Klienti nuk mund të përfundojë TLS, klienti përfundon TLS dhe nuk është i autorizuar, ose klienti lidhet dhe nuk arrin një destinacion. Asociimi i certifikatës i përket të parit, një rregull autorizimi që nuk mbulon adresën e klientit i përket të dytit, dhe një rrugë ose grup sigurie i përket të tretit, ku rikrijimi i një pike fundore është pothuajse gjithmonë lëvizja e gabuar.

Një pikë fundore që funksionoi për muaj dhe pastaj u ndal, pa ndryshim certifikate ose politike, është një rast më vete. Rindërtimi i saj me cilësime identike mund të rivendosë shërbimin, por ky është një arsye për të mbajtur konfigurimin të riprodhueshëm, jo një arsye për të rindërtuar në çdo incident.

Mbajini katër gjëra nën kontrollin e versioneve që rindërtimi i radhës të jetë një diff dhe jo një improvizim: parametrat e pikës fundore, ARN-të e certifikatës dhe zinxhirit, rregullat e autorizimit dhe CIDR-ja e klientit. Dokumentacioni i vërtetimit të Client VPN liston cila certifikatë luan çfarë roli, gjë që ia vlen të kontrollohet përpara se të supozoni se problemi është një certifikatë. Nëse një riimportim nuk ndryshon asgjë dhe pika fundore vazhdon të rivendoset, i dyshuari është asociimi dhe përgjigja është një pikë fundore e re e ndërtuar nga parametrat e regjistruar. Nëse pika fundore e merr vërtet objektin e re, asociimi ishte tashmë i saktë dhe defekti qëndron në zinxhirin e klientit ose në shtresën e autorizimit.