Krypterer VPN-en din DNS, eller bare neste hopp?

Å aktivere kryptert DNS på VPN-serveren blir ofte beskrevet som å tette en lekkasje, og den beskrivelsen skjuler hvilken forbindelse som ble endret. Hoppet fra klienten til resolvery og hoppet fra resolveren til oppstrøms er separate forbindelser med separate eiere. Å kryptere den ene lar den andre være nøyaktig som den var.

Skriv ned hvem som mottar spørringen på hvert trinn før du rører en konfigurasjonsfil.

To oppsett ser like ut på en innstillingsside

I det første oppsettet kjører enheten DNS over TLS selv, og tunnelen frakter bare den forbindelsen til en resolver du valgte. TLS-økten avsluttes hos resolveren, som betyr at resolveren ser spørringen, mens VPN-utgangen ser kryptert tekst den ikke kan lese. I det andre oppsettet sender enheten vanlig DNS gjennom tunnelen til en videresender på VPN-verten, og den videresenderen åpner sin egen krypterte forbindelse til en oppstrøms resolver. Begge ser ut som "kryptert DNS med VPN" i en funksjonsliste, og de plasserer den lesbare spørringen i forskjellige bygninger.

Forskjellen er målbar, ikke filosofisk. Se etter TLS-økten på klienten eller på serveren, så vet du hvilket oppsett du faktisk har.

Kartlegg resolverkjeden før du endrer den

Tell resolverne på veien og navngi rollen til hver av dem. En videresendende komponent overlater en forespørsel til en annen resolver, mens en rekursiv resolver gjør arbeidet med å finne et svar og kan snakke direkte med autoritative servere. Disse rollene er definert separat nettopp av denne grunnen, og RFC 9076-resolverdefinisjonene er verdt å lese før du antar at det finnes én enkelt oppstrøms destinasjon. En vert som kjører sin egen rekursive resolver har ingen enkelt "oppstrøms" å kryptere, og det gjør hele planen ugyldig.

Spør deretter hvilken komponent klienten er konfigurert til å bruke. En DNS-adresse som sendes ut av VPN-profilen forteller deg hvor spørringene går, ikke hvilken prosess som svarer på dem.

Legg merke til feilatferden også. Hvis oppstrøms kryptert forbindelse blir utilgjengelig, feiler videresenderen lukket, faller den tilbake til klartekst, eller faller den tilbake til en annen resolver? Den avgjørelsen hører hjemme i journalen, fordi den endrer personvernløftet i det øyeblikket tunnelen er minst sunn.

Bekreft hvilket hopp som er kryptert

Start på klienten og bekreft om den har en TLS-økt til port 853. En spørring som løses riktig via port 53 beviser ingenting om kryptering.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Flytt deg deretter til VPN-verten og se etter den utgående krypterte forbindelsen som videresenderen åpnet. Socket-tabellen forteller deg om en oppstrøms TLS-økt finnes, og hvilken prosess som eier den:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Hvis klienten viser en TLS-økt og serveren ikke viser noen, er du i det første oppsettet, og serveren kan ikke lese spørringer den videresender på IP-nivå. Hvis serveren viser TLS-økten og klienten viser vanlig port 53-trafikk inne i tunnelen, er du i det andre oppsettet: det videre hoppet er beskyttet, og videresenderen leser fortsatt hvert navn enheten spør om. Det andre resultatet er ikke en feil, men å kalle det ende-til-ende-kryptering er galt.

Før opp eieren og feilatferden

Eierskap avgjør hva du har lov til å love. Enhetseieren kontrollerer en kryptert forbindelse på klientsiden, mens VPN-administratoren kontrollerer den videre forbindelsen som videresenderen hans oppretter. Alle som ikke drifter noen av dem, kan bare beskrive veien.

Før du aktiverer noe, sjekk intern navngiving. Å sende organisasjonsnavn til en offentlig resolver er ikke en likeverdig løsning, og en split-horizon-sone som bare finnes inne i nettverket vil ikke løses oppstrøms i det hele tatt. Test ett internt og ett offentlig navn etter endringen, og oppbevar resultatet sammen med konfigurasjonsendringen. Hvis den krypterte veien bryter oppløsningen for interne verter, er rettelsen en resolverregel med begrenset omfang, ikke en bredere tunnel.

Avslutt med å skrive én setning per hopp: hvilken komponent som mottok spørringen, om hoppet var kryptert, og hvem som kan lese navnet. Når setningen om VPN-verten fortsatt sier at den kan lese spørringer, bør dokumentasjonen si det samme, fordi et diagram som påstår det motsatte vil bli trodd av noen som aldri kjørte kommandoene.