Geografisk DNS og anycast: kontroller inngangsporten du får

Et DNS-svar i nærheten føles som et løst problem helt til tilkoblingen lander et annet sted. Geografisk DNS og anycast prøver begge å forkorte veien, og de tar den beslutningen ut fra ulik informasjon. Ingen av dem garanterer at inngangsporten du når er tilgjengelig, at den presenterer identiteten klienten din forventer, eller at økten din overlever et nodebytte. Kontrollene nedenfor skiller de fire spørsmålene.

Sjekk hvilken lokasjon resolveren faktisk rapporterer

En autoritativ server som svarer på en topologisensitiv forespørsel, ser normalt adressen til den rekursive resolveren som spurte, ikke adressen til personen som skrev navnet. En sentralisert resolver kan stå langt fra klientene den betjener, og svaret gjenspeiler resolveren og ikke dem. Det er ikke en feil; det er slik protokollen oppfører seg med mindre ekstra informasjon gis. Spesifikasjonen for EDNS Client Subnet beskriver både begrensningen og den valgfrie løsningen.

EDNS Client Subnet kan bære informasjon om opprinnelsesnettverket når alle involverte støtter og aktiverer det. Det er valgfritt, det har konsekvenser for personvern og hurtiglagring, og det er ikke tillatelse til å anta at en offentlig resolver rapporterer en presis brukerplassering. Spør resolveroperatørene før du designer rundt 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

Sjekk hva anycast-rutingen bestemte

Med anycast annonserer flere lokasjoner tilgjengelighet for én tjenesteadresse, og nettverket leverer hver klient til den noden rutingen foretrekker. Det valget tas av BGP og den omkringliggende policyen, ikke av avstand på et kart. Topologisk nærhet betyr heller generelt ikke bedre rundturtid, fordi veien som ser kort ut kan være overbelastet eller asymmetrisk. Adressen du fikk sier ingenting om hvilken node som svarte.

Bekreft tjenestelokasjonen fra tjenestesiden, eller fra et svar som navngir den, ikke bare fra DNS-svaret. traceroute -n 198.51.100.20 viser veien du tok og navngir fortsatt ikke verten på slutten av den, så les den som en vei og ikke som et svar.

Sjekk at økten overlever et nodebytte

En DNS-spørring er kort og en VPN-økt er lang, og de to har helt forskjellige krav til tilstand. Ruting kan endre seg midt i en økt, og når den gjør det, kan senere pakker ankomme en node som aldri har sett tunnelen din. Om det er overlevbart avhenger av implementasjonen: delt tilstand, en bevisst gjenoppkobling eller en dokumentert feil. Adressen alene gir ingen av disse.

Observer endringen i stedet for å anta den. sudo tcpdump -ni any -c 20 esp viser de ytre pakkene mens veien endres, og en plutselig endring i motpartens adresse er endringen som skjer. Definer den tiltenkte oppførselen eksplisitt for implementasjonen du kjører, og test den deretter ved å tvinge frem en veilendring. Hvis designet forutsetter øktreplikering, navngi mekanismen og navngi feilen den ikke dekker.

Sjekk at identiteten fortsatt stemmer

Hvert inngangspunkt må presentere identiteten klientprofilen din forventer. Et sertifikat utstedt for tjenestenavnet fungerer på tvers av noder, mens sertifikater per node tvinger klienten til å akseptere noe nytt, og det er der brukere lærer å klikke seg gjennom advarsler. Hold den forventede identiteten og profilen konsistent med inngangsmodellen.

Sjekk det fra en klient som nådde en uvanlig node, fordi det er tilfellet der et sertifikat per node blir synlig. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com skriver ut kjeden og navnene, som er nøyaktig det klienten sammenligner. Bestem deretter om profilen bør innsnevres eller sertifikatmodellen endres.

Sjekk posten, ikke bare det første svaret

Vurder tre scenarier og skriv fire fakta for hvert: normal inngang, én lokasjon utilgjengelig og det avtalte gjenopprettingstilfellet. De fire faktaene er resolveren som ble brukt, adressen som ble returnert, lokasjonen som betjente den og et nytt applikasjonsresultat. Den posten skiller et DNS-valgproblem fra et problem med inngangsporten, et ruteproblem eller et økttilstandsproblem. Uten den ser alle fire like ut 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

Kjør scenarioene fra representative tilgangsnettverk og ikke bare fra kontoret, fordi hele spørsmålet handler om hvilket inngangspunkt ulike klienter faktisk når. Ett nettverk er et utvalg på én.