Geografisk DNS og anycast: kontroller inngangsporten du får

Eit DNS-svar i nærleiken kjennest som eit løyst problem heilt til tilkoplinga landar ein annan stad. Geografisk DNS og anycast prøver begge å forkorte vegen, og dei tek den avgjerda ut frå ulik informasjon. Ingen av dei garanterer at inngangsporten du når er tilgjengeleg, at han presenterer identiteten klienten din ventar, eller at økta di overlever eit nodebyte. Kontrollane nedanfor skil dei fire spørsmåla.

Sjekk kva lokasjon resolveren faktisk rapporterer

Ein autoritativ server som svarar på ei topologisensitiv førespurnad, ser normalt adressa til den rekursive resolveren som spurde, ikkje adressa til personen som skreiv namnet. Ein sentralisert resolver kan stå langt frå klientane han tener, og svaret speglar resolveren og ikkje dei. Det er ikkje ein feil; det er slik protokollen oppfører seg med mindre ekstra informasjon vert gitt. Spesifikasjonen for EDNS Client Subnet skildrar både avgrensinga og den valfrie løysinga.

EDNS Client Subnet kan bera informasjon om opphavsnettverket når alle involverte støttar og aktiverer det. Det er valfritt, det har konsekvensar for personvern og hurtiglagring, og det er ikkje løyve til å anta at ein offentleg resolver rapporterer ein presis brukarlokasjon. Spør resolveroperatørane før du designar 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 kva anycast-rutinga bestemte

Med anycast annonserer fleire lokasjonar tilgjenge for éi tenesteadresse, og nettverket leverer kvar klient til den noden rutinga føretrekkjer. Det valet vert teke av BGP og den omkringliggjande policyen, ikkje av avstand på eit kart. Topologisk nærleik tyder heller ikkje generelt på betre rundtur-tid, fordi vegen som ser kort ut kan vera overbelasta eller asymmetrisk. Adressa du fekk seier ingenting om kva node som svara.

Stadfest tenestelokasjonen frå tenestesida, eller frå eit svar som namngir han, ikkje berre frå DNS-svaret. traceroute -n 198.51.100.20 viser vegen du tok og namngir framleis ikkje verten på slutten av han, så les han som ein veg og ikkje som eit svar.

Sjekk at økta overlever eit nodebyte

Ei DNS-spørjing er kort og ei VPN-økt er lang, og dei to har heilt ulike krav til tilstand. Ruting kan endra seg midt i ei økt, og når ho gjer det, kan seinare pakkar koma til ein node som aldri har sett tunnelen din. Om det er overlevbart avheng av implementasjonen: delt tilstand, ei medviten gjenoppkopling eller ein dokumentert feil. Adressa åleine gir ingen av desse.

Observer endringa i staden for å anta ho. sudo tcpdump -ni any -c 20 esp viser dei ytre pakkane medan vegen endrar seg, og ei brå endring i motpartadressa er endringa som skjer. Definer den tiltenkte åtferda eksplisitt for implementasjonen du køyrer, og test ho deretter ved å tvinge fram ei vegendring. Viss designet føreset øktreplikering, namnge mekanismen og namnge feilen han ikkje dekkjer.

Sjekk at identiteten framleis stemmer

Kvart inngangspunkt må presentere identiteten klientprofilen din ventar. Eit sertifikat utstedt for tenestenamnet fungerer på tvers av nodar, medan sertifikat per node tvingar klienten til å godta noko nytt, og det er der brukarar lærer å klikke seg gjennom åtvaringar. Hald den venta identiteten og profilen konsistent med inngangsmodellen.

Sjekk det frå ein klient som nådde ein uvanleg node, fordi det er tilfellet der eit sertifikat per node vert synleg. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com skriv ut kjeda og namna, som er nøyaktig det klienten samanliknar. Bestem deretter om profilen bør snevrast inn eller sertifikatmodellen endrast.

Sjekk posten, ikkje berre det første svaret

Vurder tre scenario og skriv fire fakta for kvart: normal inngang, éin lokasjon utilgjengeleg og det avtalte gjenopprettingstilfellet. Dei fire faktaa er resolveren som vart brukt, adressa som vart returnert, lokasjonen som tente han og eit nytt applikasjonsresultat. Den posten skil eit DNS-valproblem frå eit inngangsportproblem, eit ruteproblem eller eit økttilstandsproblem. Utan han ser alle fire like ut frå 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øyr scenarioa frå representative tilgangsnettverk og ikkje berre frå kontoret, fordi heile spørsmålet handlar om kva inngangspunkt ulike klientar faktisk når. Eitt nettverk er eit utval på éin.