Dit VPN-DNS-fallback: hvor forespørgslen reelt ender

En resolverindstilling skifter fra den private adresse til en offentlig, og konklusionen kommer straks: tunnelen lækker. Nogle gange er det rigtigt. Ofte rejste fallback-forespørgslen stadig inde i tunnelen til en resolver, administratoren havde valgt, hvilket gør det til en politisk beslutning snarere end en fejl. At skelne de tilfælde kræver tre fakta i stedet for ét, og det første er, hvem der svarede. Find ud af, hvem der modtog forespørgslen, hvilken rute der bar den, og hvilke navne der blev spurgt om.

Fallback er en politik, ikke én adfærd

Enhver klient skal beslutte, hvad den gør, når den foretrukne resolver holder op med at svare. Den kan blokere opløsning, prøve igen, bruge et konfigureret alternativ eller overlade det til styresystemet, og det er fire forskellige produkter ud fra et privatlivsperspektiv. At læse indstillingsskærmen fortæller, hvilken adfærd der er konfigureret; den fortæller ikke, hvilken der opstod. En skærm med én kontakt beskriver ikke fire muligheder.

Browsere lægger deres eget lag ovenpå. En browser med sikker DNS aktiveret kan opløse et navn gennem sin egen valgte udbyder, selv når styresystemet peger et andet sted hen, hvilket betyder, at tunnelklientens politik måske aldrig bliver spurgt for de anmodninger, du faktisk bekymrer dig om. Kontrollér det program, der lavede anmodningen, ikke kun systemindstillingen.

Identiteten af den erstattende resolver er det første faktum, der er værd at fastslå. En offentlig resolver, der tilhører en udbyder, du allerede stoler på, er en anden situation end en adresse leveret af det netværk, du tilfældigvis er på. Adressen selv fortæller sjældent, hvilken af de to du ser på.

Hvem modtager forespørgslen efter skiftet

Modtageren og ruten er uafhængige, og kun deres kombination beskriver eksponeringen. En offentlig resolver nået gennem tunnelen ser aldrig din adgangsnetværksadresse, mens den samme resolver nået direkte gør. Begge tilfælde giver et svar, og en læktest, der kun rapporterer resolveradressen, vil beskrive dem identisk. Spørg efter grænsefladen såvel som adressen, når du læser resultatet.

Interne navne gør forskellen konkret. En offentlig resolver kan normalt ikke svare på et split-horizon-navn, så forespørgslen fejler, mens navnet stadig er blevet afsløret for en part, der ikke havde noget at gøre med at se det. Tilgængelighed og privatliv følges derfor ad her i stedet for at blive byttet.

En tunnel kan også bære forespørgslen til en resolver, der ikke drives af VPN-udbyderen, fordi tunnelen videresender i stedet for at opløse. Værten, der videresender, ser forespørgslen i klartekst og åbner derefter sin egen forbindelse videre, hvilket beskytter det næste hop uden at beskytte det første.

Kontrollér ruten og modtageren sammen

Observér pakkerne i stedet for konfigurationen. Spørg systemet, hvilken resolver der ville blive brugt, og bekræft derefter, at forespørgslen faktisk forlod den forventede grænseflade til den forventede adresse.

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 optagelsen viser forespørgslen forlade den fysiske grænseflade, mens tunnelen er oppe, omgik fallbacken tunnelen, uanset hvad resolverlisten siger. Hvis den vises på tunnelgrænsefladen, bliver spørgsmålet, hvem der driver den fjerne ende, og hvad den gemmer.

Gentag kontrollen for et internt navn og et offentligt navn. Den interne forespørgsel er, hvor en fallback-konfiguration normalt afslører sig selv, fordi en resolver, der ikke kan svare, stadig modtager spørgsmålet.

Beslut, om fallback skal tillades

Hvis kravet er, at opløsningen stopper, når den foretrukne resolver er utilgængelig, skal du konfigurere en håndhævelsespolitik, der fejler lukket, og acceptere konsekvensen: navne opløses ikke under et udfald. Det er en bevidst tilgængelighedshandel snarere end en funktionsfejl, og designet bør sige det, før udfaldet sker.

Hvis kravet kun er, at forespørgsler ikke må rejse uden for tunnelen, kan en offentlig resolver nået gennem tunnelen være acceptabel, forudsat at operatøren og dens opbevaringspolitik forstås. En sådan accept er en dom om en tredjepart snarere end en erklæring om kryptografi, og den tilhører den, der ejer privatlivskravet. Hvis interne navne skal blive ved med at virke, skal fallbacken være en resolver, der har de interne zoner, hvilket normalt betyder, at fallback-målet er en anden server snarere end en anden adressefamilie.

Dokumentér resultatet som en sætning om adfærd: hvilken resolver der modtager forespørgsler i normal drift, hvilken der modtager dem efter en fejl, og om interne navne opløses i det andet tilfælde. En læktest, der til sidst indlæser en side, beviser mindre end den sætning, fordi en side kan indlæses gennem en resolver, der aldrig burde være blevet spurgt.