Geografický DNS a anycast: kontrola vstupného bodu VPN, ktorý dostanete

Blízka odpoveď DNS sa zdá byť vyriešeným problémom, kým spojenie nepristane inde. Geografický DNS a anycast sa oba snažia skrátiť cestu a toto rozhodnutie robia na základe odlišných informácií. Ani jeden nezaručuje, že brána, ku ktorej sa dostanete, je dostupná, že predstavuje identitu, ktorú váš klient očakáva, alebo že vaša relácia prežije zmenu uzla. Kontroly nižšie oddeľujú tieto štyri otázky.

Skontrolujte, ktorú lokalitu resolver skutočne hlási

Autoritatívny server odpovedajúci na dotaz citlivý na topológiu zvyčajne vidí adresu rekurzívneho resolvera, ktorý sa pýtal, nie adresu osoby, ktorá zadala meno. Centralizovaný resolver môže byť ďaleko od klientov, ktorým slúži, a odpoveď odráža resolver, a nie ich. To nie je chyba; tak sa protokol správa, ak sa neposkytnú dodatočné informácie. Špecifikácia EDNS Client Subnet opisuje obmedzenie aj voliteľnú nápravu.

EDNS Client Subnet môže prenášať informácie o zdrojovej sieti, keď ho každý účastník podporuje a zapne. Je voliteľný, má dôsledky pre súkromie a cachovanie a nie je povolením predpokladať, že ktorýkoľvek verejný resolver hlási presnú polohu používateľa. Pred navrhovaním okolo neho sa spýtajte operátorov resolvera.

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

Skontrolujte, čo rozhodlo smerovanie anycast

Pri anycast viacero lokalít inzeruje dostupnosť jednej adresy služby a sieť doručí každého klienta uzlu, ktorý preferuje jeho smerovanie. Túto voľbu robí BGP a okolitá politika, nie vzdialenosť na mape. Topologická blízkosť tiež všeobecne neznamená lepší výkon tam a späť, pretože cesta, ktorá vyzerá krátko, môže byť preťažená alebo asymetrická. Adresa, ktorú ste dostali, nehovorí nič o tom, ktorý uzol odpovedal.

Potvrďte lokalitu obsluhujúcu zo strany služby alebo z odpovede, ktorá ju pomenúva, nielen z odpovede DNS. traceroute -n 198.51.100.20 zobrazuje cestu, ktorou ste išli, a stále nepomenúva hostiteľa na jej konci, preto ju čítajte ako cestu, a nie ako odpoveď.

Skontrolujte, či relácia prežije zmenu uzla

Dotaz DNS je krátky a relácia VPN dlhá a obe majú úplne odlišné požiadavky na stav. Smerovanie sa môže zmeniť uprostred relácie, a keď sa to stane, neskoršie pakety môžu prísť na uzol, ktorý nikdy nevidel váš tunel. Či je to prežiteľné, závisí od implementácie: zdieľaný stav, zámerné opätovné pripojenie alebo zdokumentovaná porucha. Samotná adresa neposkytuje nič z toho.

Sledujte zmenu namiesto toho, aby ste ju predpokladali. sudo tcpdump -ni any -c 20 esp zobrazuje vonkajšie pakety, ako sa cesta mení, a náhla zmena adresy partnera je práve prebiehajúca zmena. Explicitne definujte zamýšľané správanie pre implementáciu, ktorú prevádzkujete, a potom ho otestujte vynútením zmeny cesty. Ak návrh predpokladá replikáciu relácie, pomenujte mechanizmus a pomenujte poruchu, ktorú nepokrýva.

Skontrolujte, či identita stále sedí

Každý vstupný bod musí predložiť identitu, ktorú očakáva profil vášho klienta. Certifikát vydaný pre názov služby funguje naprieč uzlami, zatiaľ čo certifikáty pre jednotlivé uzly nútia klienta prijať niečo nové, a práve tam sa používatelia učia preklikávať varovania. Udržiavajte očakávanú identitu a profil konzistentné so vstupným modelom.

Skontrolujte to z klienta, ktorý sa dostal na nezvyčajný uzol, pretože to je prípad, keď sa certifikát pre uzol stane viditeľným. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com vypisuje reťazec a názvy, čo je presne to, čo klient porovnáva. Potom rozhodnite, či profil zúžiť alebo zmeniť model certifikátov.

Skontrolujte záznam, nielen prvú odpoveď

Vyhodnoťte tri scenáre a pre každý napíšte štyri fakty: normálny vstup, jedna nedostupná lokalita a dohodnutý prípad obnovy. Štyri fakty sú použitý resolver, vrátená adresa, lokalita, ktorá obsluhovala, a nový výsledok aplikácie. Tento záznam oddeľuje problém výberu DNS od problému brány, problému smerovania alebo problému stavu relácie. Bez neho všetky štyri vyzerajú z klienta rovnako.

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

Spúšťajte scenáre z reprezentatívnych prístupových sietí, nielen z kancelárie, pretože celá otázka je o tom, ku ktorému vstupnému bodu sa rôzni klienti skutočne dostanú. Jedna sieť je vzorka jednej.