Hvorfor en DNS-landetikett ikke beviser en VPN-lekkasje
En test knytter en adresse til et land; det sier lite om ruten. Les resolveren, videresendingskjeden og policyen før du endrer noe.
Resolveradresser som ser utenlandske ut dukker stadig opp i DNS-testresultater, og konklusjonen folk trekker er alltid den samme: spørringene må ha sluppet ut av tunnelen. Noen ganger gjorde de det. Oftere beskriver rapporten hvilken rekursiv tjeneste som svarte og hvor en database mener adressen ligger, og det er en påstand om infrastruktur, ikke om pakkene dine. Å skille observasjonen fra slutningen krever tre fakta: hvem som svarte, hvordan navnet reiste, og hvilken policy du faktisk konfigurerte.
Les hva testen faktisk observerte
De fleste testsider fungerer på samme måte: de ber klienten slå opp et unikt vertsnavn og ser deretter hvilken resolver som hentet det, eller de sender bare tilbake resolveradressen klienten rapporterer. Det identifiserer en rekursiv tjeneste og, hvis spørringen bar klient-undernettinformasjon, en grov nettverksposisjon. Det beviser ikke at spørringen forlot enheten utenfor tunnelen, og beviser absolutt ikke at samme rute ble brukt for hvert navn. Én observasjon av ett oppslag generaliseres til en påstand om all trafikk.
En test som viser resolveradressen er nyttigere enn et landmerke, fordi adressen kan sammenlignes med resolverlisten klienten faktisk mottok.
Anycast og videresending forklarer de fleste overraskelsene
Store offentlige resolvere annonserer samme adresse fra mange steder, og nettverket ruter hver spørring til stedet som er nærmest i rutemessig forstand. En geolokaliseringsdatabase knytter deretter adressen til ett sted, som kan være en bedriftsregistreringsadresse på et annet kontinent eller et datasenter som ikke er det som svarer. RFC 4786 dekker operativ praksis for anycast-tjenester og vanskeligheten med å knytte en slik adresse til ett fysisk sted. Kartet er en forenkling av en rutingsavgjørelse, og det forenkler i retningen som gir alarmerende resultater.
Videresending legger til et andre lag. En lokal stub-resolver, en ruter eller en ISP-resolver kan sende spørringer videre til en tjeneste høyere opp, og navnet som vises i testen gjenspeiler den siste operatøren i kjeden snarere enn den første. Klient-undernettutvidelser kan gjøre et svar ovenfra skreddersydd til nettverket ditt samtidig som den rapporterte posisjonen ser ut som et sted du aldri har vært.
En konfigurert resolver kan derfor være riktig og likevel gi et utenlandsk utseende resultat, og en resolver i ditt eget land kan være den gale fordi den tilhører en part du ikke valgte.
Hvem mottok navnet, og via hvilken rute
To spørsmål besvarer den praktiske delen: hvilken server klienten bruker, og om den serveren nås gjennom tunnelen. Sammenlign resolverlisten med adressen i testresultatet før du trekker konklusjoner om ruting, og kontroller deretter at spørringen til den adressen går ut gjennom tunnelgrensesnittet. Hvis de to adressene er forskjellige, er det interessante funnet at noe skrev om eller omgikk den tiltenkte resolveren, og det fortjener et nærmere blikk enn landnavnet.
resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net
Den første kommandoen viser hvilken server som svarte for et navn, den andre viser den konfigurerte listen og dens omfang, og den tredje rapporterer resolveradressen slik en offentlig tjeneste ser den. Når alle tre er enige, gjør policyen det den ble konfigurert til, uansett hva landemerket sier.
Sammenlign med policyen du valgte
En VPN som presser på en resolver, en nettleser konfigurert til å bruke sin egen krypterte DNS og et operativsystem som foretrekker innstillingene til ett grensesnitt kan hver for seg være riktige mens de samlet sett motsier hverandre. Moderne nettlesere kan sende spørringer over kryptert transport til en leverandør som er valgt i nettleseren, noe som bevisst omgår systemets resolverliste. Det er ikke en lekkasje i betydningen brutt tunnel; det er en policy valgt et annet sted, og å finne ut hvor den ble valgt er den egentlige oppgaven.
Arbeidsenheter legger til domenespesifikke regler: interne navn må gå til organisasjonens resolver, mens alt annet følger standarden. Å erstatte den ordningen fordi en testside viste et uventet land, er måten interne navn slutter å slå opp for et helt team.
Hold testene smale og trygge
Å spørre en offentlig testtjeneste om et internt vertsnavn avslører navnet for en part som ikke har noe med det å gjøre, og svaret forteller deg ingenting som en lokal lesing av resolverlisten ikke ville fortalt.
Bruk i stedet navn som avslører infrastruktur, registrer resolveradressen, omfanget og grensesnittet som ble brukt, og sammenlign den registreringen med den dokumenterte hensikten. Et kartmerke er kontekst for en samtale snarere enn et bestått eller ikke bestått, og å behandle det som en dom skaper konfigurasjonsendringer i stedet for diagnose.