VPN-DNS kontra DoH i browseren: hvad en lækagetest ikke kan fortælle dig

Lækagetestsiden siger, at din DNS er fin, browserens badge siger sikker, og den interne wiki indlæses stadig ikke. Alle tre kan være sande på samme tid, fordi en resolvers adresse ikke er det samme som den politik, der valgte den, eller den vej, forespørgslen tog. Det, folk kalder en DNS-lækage, er i virkeligheden ét spørgsmål: hvilken resolver modtog navnet, og var det valg bevidst? At få styr på det kræver tre kontroller, og kun den sidste indebærer at ændre en indstilling.

Myte et: badgen navngiver din resolver

En lækagetest opløser et testnavn og rapporterer den adresse, der svarede. Den rapporterer ikke den politik, der valgte resolveren, og når forespørgslen er pakket i DNS over HTTPS, kan en mellemboks på vejen slet ikke se navnet. To meget forskellige maskiner giver den samme beroligende badge: en hvor VPN'en sendte 10.8.0.1 ind, og browseren bruger den, og en hvor browseren ignorerede systemlisten og sendte navnet gennem tunnelen til sin egen krypterede udbyder.

Forskellen betyder noget i det øjeblik, et privat navn fejler. I den første opsætning svarer VPN-resolveren for virksomhedszonen; i den anden spurgte browseren aldrig, så det korte værtsnavn opløses ikke, og fejlen ligner en ødelagt VPN. Kontrollen er ikke endnu en lækagetest, det er et opslag på et navn, som kun én resolver kender.

Myte to: browseren forlader tunnelen

DNS vælger en adresse, routing bærer forbindelsen, og de to er separate lag. En forespørgsel sendt til en offentlig DoH-udbyder er stadig TCP port 443 til en ruterbar adresse. Hvis din rutetabel sender standardruten ind i tunnelen, går den forespørgsel også gennem tunnelen. Resolverens mærke afgør ikke vejen.

Det, browser-DoH ændrer, er modtageren af navnene. Det er en rigtig privatlivsbeslutning og en rigtig politikbeslutning, men det er ikke en omgåelse af routing. Hvis dit krav er, at navne bliver hos VPN-operatøren, opfylder en krypteret forespørgsel til en anden ikke det krav, mens den stadig bruger tunnelen til den faktiske forbindelse.

Myte tre: enhver VPN tilsidesætter enhver browser

Sikker DNS i en browser har tilstande, ikke en kontakt: slukket, en standardudbyder med fallback, en brugerdefineret skabelon eller en politik, der håndhæves af styresystemet eller organisationen. Det er fallback-tilfældet, der giver de periodiske rapporter. Når det krypterede endepunkt ikke kan nås, kan browseren falde tilbage til systemets resolver, så den samme bærbare opløser et privat navn korrekt om mandagen og ikke om tirsdagen.

Samtidig sætter de fleste VPN-klienter systemets resolver, når forbindelsen kommer op, og gendanner den forrige, når den falder. En browser, der holder en brugerdefineret krypteret resolver, observerer slet ikke den gendannelse. Det er derfor den samme profil opfører sig forskelligt på to bærbare, og hvorfor resolv.conf ser korrekt ud, mens browseren stadig spørger en anden.

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, mens du er forbundet, noter hvilke domæner hver resolver gør krav på, og sammenlign med, hvad browseren rapporterer om sin egen tilstand. Mozillas DoH-dokumentation er en rimelig beskrivelse af, hvordan en browsers standard- og fallbackadfærd er tænkt at fungere.

Beslutningen har tre input, ikke ét

Private navne, operatørtillid og tilgængelighed afgør den rigtige indretning. Navne, som kun VPN-resolveren kender, tvinger opdelt DNS: det private suffiks går til den sendte resolver, alt andet følger den politik, du valgte for offentlige navne. Operatørtillid afgør, om offentlige navne også skal gå til den resolver eller til en separat tjeneste. Tilgængelighed afgør, om din valgte krypterede resolver overhovedet kan bruges på dette netværk.

Ingen af disse rækker er en universel anbefaling. En resolver, der drives af VPN'en, samler observationer hos den operatør; en separat tjeneste tilføjer en modtager mere af de forespurgte navne. Ingen af indretningerne beviser noget om opbevaring, medmindre du læser politikken.

Skriv beslutningen ned pr. profil, fordi disse indstillinger driver. En profil, der sendte en resolver sidste måned, sender måske intet i dag, og browseren beholder gerne et gammelt brugerdefineret endepunkt, der stadig svarer. Det, der hører i noten, er resolverens adresse, de suffikser den ejer, og browserens tilstand, ikke tjenestens mærke.

Test den politik, du tror, du har konfigureret

Test efter navn, ikke efter badge. Opløs et offentligt navn og et privat navn gennem systemets resolver, og gentag det derefter i browseren med dens egen sikre DNS-indstilling i den tilstand, du vil bruge. Hvis det private navn kun fejler i browseren, har du fundet modtageruoverensstemmelsen uden at røre en enkelt VPN-indstilling.

Genopret derefter forbindelsen og kontroller gendannelsen, for det er der, overleveringsfejlene bor: afbryd, bekræft at den forrige resolver kom tilbage, genopret, bekræft at den sendte kom tilbage. Test til sidst en browser med en administreret politik, hvis du har en, for den tilstand kan helt afvise din ændring og stille beholde den forrige resolver.

Begynd med navnerums-spørgsmålet, og du undgår det meste af dette. Hvis maskinen skal nå interne navne, er browserens krypterede resolver en beslutning om kun den offentlige halvdel, og den private halvdel bliver hos det, VPN'en nu har sendt.