VPN DNS mot webbläsarens DoH: vad ett läckagetest inte kan berätta

Läckagetestets sida säger att din DNS är okej, webbläsarens märke säger säkert, och den interna wikin laddas fortfarande inte. Alla tre kan vara sanna samtidigt, eftersom en resolvers adress inte är samma sak som policyn som valde den eller vägen som frågan tog. Det folk kallar en DNS-läcka är egentligen en enda fråga: vilken resolver tog emot namnet, och var det valet avsiktligt? Att reda ut det kräver tre kontroller, och bara den sista innebär att ändra en inställning.

Myt ett: märket namnger din resolver

Ett läckagetest slår upp ett testnamn och rapporterar adressen som svarade. Det rapporterar inte policyn som valde den resolvern, och när frågan är inlindad i DNS over HTTPS kan en mellanbox på vägen inte se namnet alls. Två väldigt olika maskiner ger samma lugnande märke: en där VPN:en sköt in 10.8.0.1 och webbläsaren använder den, och en där webbläsaren ignorerade systemlistan och skickade namnet till sin egen krypterade leverantör genom tunneln.

Skillnaden spelar roll i samma stund som ett privat namn misslyckas. I det första upplägget svarar VPN-resolvern för företagszonen; i det andra frågade webbläsaren aldrig den, så det korta värdnamnet slås inte upp och felet ser ut som en trasig VPN. Kontrollen är inte ännu ett läckagetest, den är en uppslagning mot ett namn som bara en resolver känner till.

Myt två: webbläsaren lämnar tunneln

DNS väljer en adress, routingen bär anslutningen, och de två är separata lager. En fråga som skickas till en offentlig DoH-leverantör är fortfarande TCP port 443 till en dirigerbar adress. Om din routingtabell skickar standardrutten in i tunneln går den frågan också genom tunneln. Resolverns varumärke avgör inte vägen.

Det webbläsarens DoH ändrar är mottagaren av namnen. Det är ett verkligt integritetsbeslut och ett verkligt policybeslut, men det är inte en routingkringgång. Om ditt krav är att namnen stannar hos VPN-operatören, bryter en krypterad fråga till någon annan mot det kravet medan den fortfarande använder tunneln för själva anslutningen.

Myt tre: varje VPN åsidosätter varje webbläsare

Säker DNS i en webbläsare har lägen, inte en strömbrytare: av, en standardleverantör med reserv, en anpassad mall, eller en policy som tvingas av operativsystemet eller organisationen. Reservfallet är det som ger sporadiska rapporter. När den krypterade slutpunkten inte går att nå kan webbläsaren falla tillbaka på systemets resolver, så samma laptop slår upp ett privat namn korrekt på måndagen och inte på tisdagen.

Samtidigt sätter de flesta VPN-klienter systemets resolver när anslutningen kommer upp och återställer den tidigare när den faller. En webbläsare som håller en anpassad krypterad resolver märker inte den återställningen alls. Det är därför samma profil beter sig olika på två laptops och varför resolv.conf ser korrekt ut medan webbläsaren ändå frågar någon annan.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Kör dem medan du är ansluten, notera vilka domäner varje resolver gör anspråk på och jämför med vad webbläsaren rapporterar om sitt eget läge. Mozillas DoH-dokumentation är en rimlig beskrivning av hur en webbläsares standard- och reservbeteende är tänkt att fungera.

Beslutet har tre ingångar, inte en

Privata namn, operatörsförtroende och nåbarhet avgör rätt upplägg. Namn som bara VPN-resolvern känner till tvingar delad DNS: det privata suffixet går till den inskjutna resolvern, allt annat följer vilken policy du än valde för offentliga namn. Operatörsförtroende avgör om offentliga namn också ska gå till den resolvern eller till en separat tjänst. Nåbarhet avgör om din valda krypterade resolver ens är användbar på det här nätet.

Ingen av dessa rader är en universell rekommendation. En resolver som drivs av VPN:en samlar observationer hos den operatören; en separat tjänst lägger till en mottagare av efterfrågade namn. Ingen av ordningarna bevisar något om lagring om du inte läser policyn.

Skriv ner beslutet per profil, för de här inställningarna driver. En profil som sköt in en resolver förra månaden kanske inte skjuter in något i dag, och webbläsaren behåller gärna en gammal anpassad slutpunkt som fortfarande svarar. Det som hör i anteckningen är resolveradressen, suffixen den äger och webbläsarläget, inte tjänstens varumärke.

Testa policyn du tror att du konfigurerade

Testa med namn, inte med märke. Slå upp ett offentligt och ett privat namn genom systemets resolver och upprepa sedan inne i webbläsaren med dess egen säkra DNS-inställning i det läge du tänker använda. Om det privata namnet misslyckas bara i webbläsaren har du hittat mottagarmissmatchen utan att röra en enda VPN-inställning.

Återanslut sedan och kontrollera återställningen, för det är där överlämningsbuggarna bor: koppla från, bekräfta att den tidigare resolvern kom tillbaka, anslut igen, bekräfta att den inskjutna kom tillbaka. Testa till sist en webbläsare med hanterad policy om du har en, eftersom det läget kan avvisa din ändring helt och tyst behålla den tidigare resolvern.

Börja med namnrymdsfrågan så undviker du det mesta av det här. Om maskinen måste nå interna namn är webbläsarens krypterade resolver ett beslut bara om den offentliga halvan, och den privata halvan stannar hos det VPN:en sköt in.