Hvorfor et DNS-landemærke ikke beviser en VPN-lækage

Resolveradresser, der ser udenlandske ud, dukker konstant op i DNS-testresultater, og den konklusion, folk drager, er altid den samme: forespørgslerne må være sluppet ud af tunnelen. Nogle gange gjorde de. Oftere beskriver rapporten, hvilken rekursiv tjeneste der svarede, og hvor en database mener, at adressen ligger, og det er en udtalelse om infrastruktur snarere end om dine pakker. At skille observationen fra slutningen kræver tre fakta: hvem svarede, hvordan navnet rejste, og hvilken politik du faktisk konfigurerede.

Læs, hvad testen faktisk observerede

De fleste testsider fungerer på samme måde: de beder klienten slå et unikt værtsnavn op og ser derefter efter, hvilken resolver der hentede det, eller de sender blot resolveradressen tilbage, som klienten rapporterer. Det identificerer en rekursiv tjeneste og, hvis forespørgslen bar klient-undernetinformation, en grov netværksplacering. Det beviser ikke, at forespørgslen forlod enheden uden for tunnelen, og det beviser bestemt ikke, at den samme rute blev brugt til hvert navn. En enkelt observation af et enkelt opslag generaliseres til en påstand om al trafik.

En test, der viser resolveradressen, er mere nyttig end et landemærke, fordi en adresse kan sammenlignes med den resolverliste, klienten faktisk modtog.

Anycast og videresendelse forklarer de fleste overraskelser

Store offentlige resolvere annoncerer den samme adresse fra mange steder, og netværket sender hver forespørgsel til det sted, der er nærmest i routingmæssig forstand. En geolokaliseringsdatabase knytter derefter adressen til ét sted, som kan være en virksomheds registreringsadresse på et andet kontinent eller et datacenter, som ikke er det, der svarer. RFC 4786 dækker operationel praksis for anycast-tjenester og vanskeligheden ved at knytte en sådan adresse til ét fysisk sted. Kortet er en forenkling af en routingbeslutning, og det forenkler i den retning, der giver alarmerende resultater.

Videresendelse tilføjer et andet lag. En lokal stub-resolver, en router eller en ISP-resolver kan sende forespørgsler videre til en tjeneste længere oppe, og det navn, der vises i testen, afspejler den sidste operatør i kæden snarere end den første. Klient-undernetudvidelser kan gøre et svar ovenfra skræddersyet til dit netværk, samtidig med at den rapporterede placering ser ud som et sted, du aldrig har været.

En konfigureret resolver kan derfor være korrekt og alligevel give et udenlandsk udseende resultat, og en resolver i dit eget land kan stadig være den forkerte, fordi den tilhører en part, du ikke valgte.

Hvem modtog navnet, og ad hvilken rute

To spørgsmål besvarer den praktiske del: hvilken server bruger klienten, og nås den server gennem tunnelen. Sammenlign resolverlisten med adressen i testresultatet, før du drager konklusioner om routing, og kontroller derefter, at forespørgslen til den adresse forlader tunnelinterfacet. Hvis de to adresser er forskellige, er det interessante fund, at noget har overskrevet eller omgået den tilsigtede resolver, hvilket fortjener et nærmere kig end landenavnet.

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

Den første kommando viser, hvilken server der svarede for et navn, den anden viser den konfigurerede liste og dens omfang, og den tredje rapporterer resolveradressen, som en offentlig tjeneste ser den. Når alle tre er enige, gør politikken det, den blev konfigureret til, uanset hvad landemærket siger.

Sammenlign med den politik, du valgte

En VPN, der skubber en resolver, en browser konfigureret til at bruge sin egen krypterede DNS og et styresystem, der foretrækker ét interfaces indstillinger kan hver især være korrekte, mens de tilsammen strider imod hinanden. Moderne browsere kan sende forespørgsler over en krypteret transport til en udbyder, der er valgt i browseren, hvilket bevidst omgår systemets resolverliste. Det er ikke en lækage i betydningen brudt tunnel; det er en politik valgt et andet sted, og at finde ud af, hvor den blev valgt, er den egentlige opgave.

Arbejdsenheder tilføjer domænespecifikke regler: interne navne skal gå til organisationens resolver, mens alt andet følger standarden. At erstatte den ordning, fordi en testsiden viste et uventet land, er måden, hvorpå interne navne holder op med at slå op for et helt team.

Hold testene smalle og sikre

At forespørge en offentlig testtjeneste om et internt værtsnavn afslører navnet for en part, der ikke har noget med det at gøre, og svaret fortæller dig intet, som en lokal læsning af resolverlisten ikke ville fortælle.

Brug i stedet navne, der afslører infrastruktur, registrér resolveradressen, omfanget og det anvendte interface, og sammenlign registreringen med den dokumenterede hensigt. Et kortmærke er kontekst for en samtale snarere end et bestået eller ikke bestået, og at behandle det som en dom skaber konfigurationsændringer i stedet for diagnostik.