DNS geografic și anycast: verificarea punctului de intrare VPN primit

Un răspuns DNS apropiat pare o problemă rezolvată până când conexiunea aterizează în altă parte. DNS-ul geografic și anycast încearcă ambele să scurteze calea și iau decizia pe baza unor informații diferite. Niciunul nu garantează că poarta de acces la care ajungi este accesibilă, că prezintă identitatea pe care o așteaptă clientul tău sau că sesiunea ta supraviețuiește unei schimbări de nod. Verificările de mai jos separă aceste patru întrebări.

Verifică a cui locație o raportează de fapt resolverul

Un server autoritar care răspunde la o interogare sensibilă la topologie vede de obicei adresa resolverului recursiv care a întrebat, nu adresa persoanei care a tastat numele. Un resolver centralizat poate sta departe de clienții pe care îi deservește, iar răspunsul reflectă resolverul și nu pe aceștia. Acesta nu este un defect; așa se comportă protocolul dacă nu sunt furnizate informații suplimentare. Specificația EDNS Client Subnet descrie atât limitarea, cât și remediul opțional.

EDNS Client Subnet poate transporta informații despre rețeaua de origine atunci când fiecare participant îl acceptă și îl activează. Este opțional, are consecințe pentru confidențialitate și cache și nu este o permisiune de a presupune că vreun resolver public raportează o locație precisă a utilizatorului. Întreabă operatorii resolverului înainte de a proiecta în jurul lui.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Verifică ce a decis rutarea anycast

Cu anycast, mai multe locații anunță accesibilitatea pentru o singură adresă de serviciu, iar rețeaua livrează fiecare client nodului pe care rutarea lui îl preferă. Această alegere este făcută de BGP și de politica din jur, nu de distanța pe hartă. Apropierea topologică, de asemenea, nu înseamnă în general performanță mai bună dus-întors, pentru că drumul care pare scurt poate fi congestionat sau asimetric. Adresa pe care ai primit-o nu spune nimic despre ce nod a răspuns.

Confirmă locația care deservește din partea serviciului sau dintr-un răspuns care o numește, nu doar din răspunsul DNS. traceroute -n 198.51.100.20 arată calea pe care ai parcurs-o și tot nu numește gazda de la capătul ei, așa că citește-o ca pe o cale, nu ca pe un răspuns.

Verifică dacă sesiunea supraviețuiește unei schimbări de nod

O interogare DNS este scurtă, iar o sesiune VPN este lungă, iar cele două au cerințe de stare complet diferite. Rutarea se poate schimba la mijlocul sesiunii, iar când se întâmplă, pachetele ulterioare pot ajunge la un nod care nu a văzut niciodată tunelul tău. Dacă acest lucru este supraviețuibil depinde de implementare: stare partajată, reconectare deliberată sau o defecțiune documentată. Doar adresa nu oferă niciuna dintre acestea.

Observă schimbarea în loc să o presupui. sudo tcpdump -ni any -c 20 esp arată pachetele exterioare pe măsură ce calea se schimbă, iar o schimbare bruscă a adresei partenerului este schimbarea care are loc. Definește explicit comportamentul dorit pentru implementarea pe care o rulezi, apoi testează-l forțând o schimbare de cale. Dacă proiectul presupune replicarea sesiunii, numește mecanismul și numește defecțiunea pe care nu o acoperă.

Verifică dacă identitatea mai corespunde

Fiecare punct de intrare trebuie să prezinte identitatea pe care o așteaptă profilul clientului tău. Un certificat emis pentru numele serviciului funcționează între noduri, în timp ce certificatele pe nod obligă clientul să accepte ceva nou, iar acolo utilizatorii învață să treacă peste avertismente. Menține identitatea așteptată și profilul consecvente cu modelul de intrare.

Verifică din partea unui client care a ajuns la un nod neobișnuit, pentru că acesta este cazul în care un certificat pe nod devine vizibil. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com afișează lanțul și numele, exact ceea ce compară clientul. Apoi decide dacă profilul trebuie restrâns sau modelul de certificate schimbat.

Verifică înregistrarea, nu doar primul răspuns

Evaluează trei scenarii și scrie patru fapte pentru fiecare: intrare normală, o locație indisponibilă și cazul de recuperare convenit. Cele patru fapte sunt resolverul folosit, adresa returnată, locația care a deservit-o și un rezultat nou al aplicației. Acea înregistrare separă o problemă de selecție DNS de o problemă a porții de acces, de rutare sau de stare a sesiunii. Fără ea, toate patru arată identic din partea clientului.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Rulează scenariile din rețele de acces reprezentative, nu doar din birou, pentru că întreaga întrebare este ce punct de intrare ating de fapt clienții diferiți. O rețea este o mostră de unu.