DNS-ul endpointului AWS Client VPN: de ce fixarea IP-ului rezolvat eșuează

Săptămâna trecută dig +short v-a dat o adresă pentru numele endpointului din profilul AWS Client VPN, iar tunelul s-a conectat. Săptămâna aceasta același profil stă pe 'Connecting' pe laptopul dvs., în timp ce copia neatinsă a unui coleg încă funcționează. Nimic nu a fost blocat și certificatul nu a expirat. Cineva a înlocuit numele de gazdă al endpointului cu acea adresă rezolvată, iar serviciul nu mai răspunde acolo. Numele exportat este partea construită să supraviețuiască acelei schimbări.

Numele din profil s-ar putea să nu fie numele care este interogat

Profilurile exportate din Client VPN conțin de obicei remote-random-hostname. Cu acea opțiune activă, clientul construiește o etichetă de unică folosință, o alătură numelui endpointului cu un punct și rezolvă numele combinat. O înregistrare wildcard în zona endpointului răspunde oricărei etichete, de aceea un prefix inventat se rezolvă în continuare și de aceea trucul rămâne invizibil când încercați să reproduceți interogarea manual.

Deci, când lipiți numele endpointului într-un terminal și primiți un răspuns, ați rezolvat un alt nume decât cel pe care clientul îl folosește la conectare. Această nepotrivire nu este un defect de corectat în profil. Eticheta este regenerată intenționat: opțiunea împiedică cache-urile să păstreze un răspuns învechit și nu identifică niciodată mașina sau sesiunea dvs.

Am întâlnit cazul de compatibilitate în care un client ignoră complet opțiunea. AWS documentează soluția: păstrați numele real al endpointului și adăugați în față un șir aleatoriu plus un punct, tratându-l ca un model de denumire, nu ca o valoare de lipit. Aplicarea acestui lucru la un client vechi este rezonabilă; codificarea fixă a șirului cu prefix ca endpoint nu este.

De ce un răspuns salvat nu poate rămâne corect

Adresele endpointului Client VPN sunt gestionate de AWS și se schimbă în timp, ceea ce documentația bunelor practici spune direct. Un răspuns capturat este o instantanee a unei rezolvări. Un profil care îl codifică fix devine un profil îndreptat spre o gazdă scoasă din uz de îndată ce serviciul se mută, iar eșecul rareori arată ca DNS: primiți un timeout de conectare sau un handshake blocat, așa că oamenii urmăresc rutarea și certificatele.

Același răspuns în /etc/hosts moștenește aceeași expirare cu o problemă suplimentară. O intrare hosts supraviețuiește repornirilor, reexportărilor și reparațiilor 'reinstalează clientul', așa că eșecul revine de fiecare dată când adresa se mută. Am văzut una stând săptămâni fără să facă rău, apoi scoțând din uz fiecare mașină care o purta, în timp ce instalările noi se conectau normal. Această scindare, o grupă eșuează și alta e în regulă pe același cont, este cel mai ieftin indiciu pe care îl veți primi.

Delimitați corect domeniul randomizării. Ea are loc la fiecare încercare de conectare. Un tunel stabilit nu își rezolvă din nou endpointul, nu schimbă servere la mijlocul sesiunii, iar cererile individuale ale aplicațiilor nu aleg fiecare o gazdă VPN nouă. Doar următoarea încercare rezolvă din nou, de aceea o sesiune care funcționează toată după-amiaza nu spune nimic despre mâine dimineață.

Ce verifică serviciul când tunelul urcă

Client VPN cere ca adresa la care sunteți conectat să corespundă unei adrese rezolvate pentru numele DNS al endpointului. Această singură cerință explică mai multe eșecuri care par nelegate: o înregistrare DNS personalizată care indică altundeva, un frontend personalizat care redirecționează către adresa reală a endpointului și un profil rescris către o adresă brută. AWS documentează combinația dintre înregistrarea personalizată și redirecționare ca eșec cu clienții AWS recenți. Verificarea este îngustă; nu este o sentință că fiecare alias este interzis.

Nu este nici o regulă generală despre protocoalele VPN. Un remote numeric este perfect valid într-o implementare obișnuită de OpenVPN, și multe funcționează astfel. Restricția vine din aranjamentul gestionat, nu din protocolul de dedesubt.

Ceea ce face relaxarea verificării certificatului reflexul greșit. Dacă un profil eșuează după o schimbare de adresă, dezactivarea verificării serverului mută eroarea în loc să repare rezolvarea sau cerința de potrivire a adresei, și lasă un client care va avea încredere în orice. Păstrați CA-ul exportat, verificarea serverului și setările de autentificare reciprocă exact așa cum au venit.

Listele de permisiuni, ieșirea și DNS-ul privat sunt trei probleme separate

O regulă de firewall care trebuie să permită o destinație înainte ca laptopul să se conecteze privește ascultătorul exterior. Dați proprietarului rețelei numele endpointului, transportul și portul configurat, apoi întrebați dacă controlul lor poate urmări comportamentul DNS al serviciului. O regulă care ține o singură adresă capturată este o instantanee cu o expirare nescrisă. Dacă controlul acceptă doar destinații imuabile, rezolvați acel gol înainte de lansare în loc să codificați în tăcere un răspuns.

Un partener care are nevoie de o adresă sursă fixă pentru cererile făcute după ridicarea tunelului are o altă cerință: ieșirea. Ce observă un site depinde de ruta aplicației și de politica de tunel divizat, nu de adresa la care s-a conectat clientul. Traficul prin tunel divizat poate să nu atingă niciodată AWS.

DNS-ul privat din interiorul tunelului este un al treilea strat. Rezolvitorul dat clienților răspunde la nume interne după conectare; nu poate rezolva endpointul public înainte ca tunelul să existe. Eșecul de rezolvare a endpointului și eșecul de rezolvare a unei aplicații interne apar în etape diferite, iar amestecarea lor vă trimite la jurnalul greșit.

Familia de adrese aparține aceleiași liste. Un răspuns IPv4 nu spune nimic despre calea permisă a unui endpoint IPv6 sau cu stivă dublă, așa că o instantanee făcută într-o familie nu este dovadă pentru cealaltă.

Verificați o conexiune fără a fixa nimic

Începeți de la profilul așa cum a fost exportat și citiți ce cere de fapt:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Apoi comparați trei lucruri: numele endpointului pe care îl ține profilul, adresa pe care clientul o raportează pentru o încercare nouă și la ce se rezolvă numele acum. Un nume care se rezolvă dovedește doar că înregistrarea răspunde; transportul și autentificarea sunt separate, iar endpointul nu trebuie să răspundă la ping. Jurnalul clientului este singura sursă pentru elementul din mijloc, așa că capturați-l în timpul încercării, nu după.

O adresă care răspunde astăzi este dovadă despre astăzi; numele este ceea ce serviciul menține valid. Notați observația, trimiteți-o celui care deține endpointul și lăsați profilul îndreptat spre nume.

Două obiceiuri de abandonat: dezactivarea verificărilor de certificat pentru a trece de un handshake blocat și stivuirea de etichete în fața numelui endpointului în speranța că una se prinde. O etichetă se rezolvă prin înregistrarea wildcard sau problema este în altă parte. Dacă un profil configurat corect tot eșuează, trimiteți interogarea exactă și evenimentul de conectare, nu un nume de gazdă mai lung.

Înainte de a închide: profilul poartă încă numele exportat al endpointului, niciun fișier hosts nu fixează adresa, remote-ul din jurnalul clientului corespunde unei rezolvări actuale, iar regula de firewall numește endpointul, nu o adresă. Aceasta este și starea de predat următoarei persoane.