Geografisk DNS og anycast: kontrol af den VPN-indgang, du får

Et nært DNS-svar føles som et løst problem, indtil forbindelsen lander et andet sted. Geografisk DNS og anycast forsøger begge at forkorte vejen, og de træffer den beslutning ud fra forskellige oplysninger. Ingen af dem garanterer, at den gateway, du når, er tilgængelig, at den fremviser den identitet, din klient forventer, eller at din session overlever et nodeskift. Kontrollerne nedenfor adskiller de fire spørgsmål.

Kontroller, hvis placering resolveren faktisk rapporterer

En autoritativ server, der besvarer en topologifølsom forespørgsel, ser normalt adressen på den rekursive resolver, der spurgte, ikke adressen på den person, der skrev navnet. En centraliseret resolver kan ligge langt fra de klienter, den betjener, og svaret afspejler resolveren frem for dem. Det er ikke en fejl; det er sådan protokollen opfører sig, medmindre der leveres ekstra oplysninger. Specifikationen for EDNS Client Subnet beskriver både begrænsningen og den valgfrie afhjælpning.

EDNS Client Subnet kan bære oplysninger om kildenettet, når hver deltager understøtter og aktiverer det. Det er valgfrit, det har konsekvenser for privatliv og caching, og det er ikke tilladelse til at antage, at enhver offentlig resolver rapporterer en præcis brugerplacering. Spørg resolveroperatørerne, før du designer ud fra det.

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

Kontroller, hvad anycast-routing besluttede

Med anycast annoncerer flere placeringer tilgængelighed for én serviceadresse, og netværket leverer hver klient til den node, dens routing foretrækker. Det valg træffes af BGP og den omkringliggende politik, ikke af afstand på et kort. Topologisk nærhed er heller ikke generelt ensbetydende med bedre rundturstid, fordi den vej, der ser kort ud, kan være overbelastet eller asymmetrisk. Den adresse, du fik, siger intet om, hvilken node der svarede.

Bekræft serviceplaceringen fra tjenestens side eller fra et svar, der navngiver den, i stedet for fra DNS-svaret alene. traceroute -n 198.51.100.20 viser den vej, du tog, og navngiver stadig ikke værten i dens ende, så læs den som en vej og ikke som et svar.

Kontroller, at sessionen overlever et nodeskift

En DNS-forespørgsel er kort, og en VPN-session er lang, og de to har helt forskellige krav til tilstand. Routing kan flytte sig midt i en session, og når det sker, kan senere pakker ankomme til en node, der aldrig har set din tunnel. Om det kan overleves, afhænger af implementeringen: delt tilstand, en bevidst genopkobling eller en dokumenteret fejl. Adressen alene giver ingen af dem.

Observer skiftet i stedet for at antage det. sudo tcpdump -ni any -c 20 esp viser de ydre pakker, efterhånden som vejen ændrer sig, og en pludselig ændring i peer-adressen er selve skiftet. Definer den tilsigtede adfærd eksplicit for den implementering, du kører, og test den derefter ved at fremtvinge en vejændring. Hvis designet forudsætter sessionsreplikering, navngiv mekanismen, og navngiv den fejl, den ikke dækker.

Kontroller, at identiteten stadig matcher

Hver indgang skal fremvise den identitet, din klientprofil forventer. Et certifikat udstedt til servicenavnet virker på tværs af noder, mens certifikater per node tvinger klienten til at acceptere noget nyt, og det er der, brugerne lærer at klikke gennem advarsler. Hold den forventede identitet og profilen i overensstemmelse med indgangsmodellen.

Kontroller det fra en klient, der nåede en usædvanlig node, fordi det er tilfældet, hvor et certifikat per node bliver synligt. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com udskriver kæden og navnene, hvilket er præcis det, klienten sammenligner. Beslut derefter, om profilen skal indsnævres, eller certifikatmodellen skal ændres.

Kontroller registreringen, ikke kun det første svar

Vurder tre scenarier, og skriv fire fakta for hvert: normal indgang, én placering utilgængelig og det aftalte gendannelsestilfælde. De fire fakta er den anvendte resolver, den returnerede adresse, den placering, der betjente den, og et friskt applikationsresultat. Den registrering adskiller et DNS-valgproblem fra et gatewayproblem, et routingproblem eller et sessionstilstandsproblem. Uden den ser alle fire identiske ud fra klienten.

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

Kør scenarierne fra repræsentative adgangsnetværk i stedet for kun fra kontoret, fordi hele spørgsmålet handler om, hvilken indgang forskellige klienter faktisk når. Ét netværk er en stikprøve på én.