VPN-DNS-fallbacken din: hvor forespørselen faktisk går hen

En resolverinnstilling skifter fra den private adressen til en offentlig, og konklusjonen kommer med en gang: tunnelen lekker. Noen ganger stemmer det. Ofte reiste reserveforespørselen fortsatt inne i tunnelen til en resolver administratoren hadde valgt, noe som gjør det til en politisk beslutning snarere enn en feil. Å skille disse tilfellene krever tre fakta i stedet for ett, og det første er hvem som svarte. Finn ut hvem som mottok forespørselen, hvilken rute som bar den, og hvilke navn det ble spurt om.

Fallback er en policy, ikke én atferd

Hver klient må bestemme hva den gjør når den foretrukne resolveren slutter å svare. Den kan blokkere oppslag, prøve på nytt, bruke et konfigurert alternativ eller overlate det til operativsystemet, og fra et personvernperspektiv er det fire forskjellige produkter. Å lese innstillingsskjermen forteller deg hvilken atferd som er konfigurert; den forteller deg ikke hvilken som oppstod. En skjerm med én bryter beskriver ikke fire muligheter.

Nettlesere legger på sitt eget lag. En nettleser med sikker DNS aktivert kan slå opp et navn via sin egen valgte leverandør selv når operativsystemet peker et annet sted, noe som betyr at tunnelklientens policy kanskje aldri blir spurt for forespørslene du faktisk bryr deg om. Sjekk programmet som laget forespørselen, ikke bare systeminnstillingen.

Identiteten til den erstattende resolveren er det første faktumet det er verdt å fastslå. En offentlig resolver som tilhører en leverandør du allerede stoler på, er en annen situasjon enn en adresse levert av nettverket du tilfeldigvis er på. Adressen selv forteller sjelden hvilken av de to du ser på.

Hvem som mottar forespørselen etter byttet

Mottakeren og ruten er uavhengige, og bare kombinasjonen deres beskriver eksponeringen. En offentlig resolver nådd gjennom tunnelen ser aldri adressen til tilgangsnettverket ditt, mens den samme resolveren nådd direkte ser den. Begge tilfellene gir et svar, og en lekkasjetest som bare rapporterer resolveradressen, vil beskrive dem likt. Spør etter grensesnittet så vel som adressen når du leser resultatet.

Interne navn gjør forskjellen konkret. En offentlig resolver kan vanligvis ikke svare på et split-horizon-navn, så forespørselen feiler mens navnet likevel er blitt avslørt for en part som ikke hadde noe med å se det. Tilgjengelighet og personvern går derfor sammen her i stedet for å byttes mot hverandre.

En tunnel kan også bære forespørselen til en resolver som ikke drives av VPN-leverandøren, fordi tunnelen videresender i stedet for å slå opp. Verten som videresender ser forespørselen i klartekst og åpner deretter sin egen forbindelse videre, noe som beskytter neste hopp uten å beskytte det første.

Sjekk ruten og mottakeren sammen

Observer pakkene i stedet for konfigurasjonen. Spør systemet hvilken resolver som ville bli brukt, og bekreft deretter at forespørselen faktisk forlot det forventede grensesnittet til den forventede adressen.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Hvis opptaket viser forespørselen forlate det fysiske grensesnittet mens tunnelen er oppe, omgikk fallbacken tunnelen uansett hva resolverlisten sier. Hvis den vises på tunnelgrensesnittet, blir spørsmålet hvem som driver den fjerne enden og hva den beholder.

Gjenta sjekken for ett internt navn og ett offentlig navn. Den interne forespørselen er der en fallback-konfigurasjon vanligvis avslører seg, fordi en resolver som ikke kan svare fortsatt mottar spørsmålet.

Bestem om fallbacken skal tillates

Hvis kravet er at oppslag stopper når den foretrukne resolveren er utilgjengelig, konfigurer en håndhevelsespolicy som feiler lukket og godta konsekvensen: navn vil ikke bli slått opp under et avbrudd. Det er en bevisst tilgjengelighetshandel og ikke en funksjonsfeil, og designet bør si det før avbruddet skjer.

Hvis kravet bare er at forespørsler ikke skal reise utenfor tunnelen, kan en offentlig resolver nådd gjennom tunnelen være akseptabel forutsatt at operatøren og dens oppbevaringspolicy er forstått. En slik aksept er en vurdering av en tredjepart og ikke en påstand om kryptografi, og den tilhører den som eier personvernpåstanden. Hvis interne navn må fortsette å virke, må fallbacken være en resolver som holder de interne sonene, noe som vanligvis betyr at fallbackmålet er en annen server og ikke en annen adressefamilie.

Dokumenter resultatet som en setning om atferd: hvilken resolver som mottar forespørsler i normal drift, hvilken som mottar dem etter en feil, og om interne navn slås opp i det andre tilfellet. En lekkasjetest som til slutt laster en side, beviser mindre enn den setningen, fordi en side kan lastes gjennom en resolver som aldri burde vært spurt.