Krypterer din VPN DNS, eller kun det næste hop?

Aktivering af krypteret DNS på VPN-serveren beskrives ofte som at lukke et læk, og den beskrivelse skjuler, hvilken forbindelse der blev ændret. Hoppet fra klient til resolver og hoppet fra resolver til upstream er separate forbindelser med separate ejere. Krypterer man den ene, forbliver den anden præcis som før.

Skriv ned, hvem der modtager forespørgslen på hvert trin, før du rører en konfigurationsfil.

To opsætninger ser ens ud på en indstillingsside

I den første opsætning kører enheden selv DNS over TLS, og tunnelen bærer blot den forbindelse til en resolver, du har valgt. TLS-sessionen afsluttes ved resolveren, hvilket betyder, at resolveren ser forespørgslen, mens VPN-udgangen ser ciphertext, den ikke kan læse. I den anden opsætning sender enheden almindelig DNS gennem tunnelen til en videresender på VPN-værten, og den videresender åbner sin egen krypterede forbindelse til en upstream-resolver. Begge ser ud som "krypteret DNS med en VPN" i en funktionsliste, og de placerer den læsbare forespørgsel i forskellige bygninger.

Forskellen er målbar snarere end filosofisk. Se efter TLS-sessionen på klienten eller på serveren, og du ved, hvilken opsætning du faktisk har.

Kortlæg resolverkæden, før du ændrer den

Tæl resolverne på vejen, og navngiv hver af dem. En videresendende komponent giver en anmodning videre til en anden resolver, mens en rekursiv resolver udfører arbejdet med at finde et svar og kan tale direkte med autoritative servere. De roller er defineret hver for sig netop af denne grund, og resolverdefinitionerne i RFC 9076 er værd at læse, før du antager, at der findes én enkelt upstream-destination. En vært, der kører sin egen rekursive resolver, har ingen enkelt "upstream" at kryptere, og det gør hele planen ugyldig.

Spørg derefter, hvilken komponent klienten er konfigureret til at bruge. En DNS-adresse, der skubbes af VPN-profilen, fortæller, hvor forespørgslerne går hen, ikke hvilken proces der besvarer dem.

Bemærk også fejladfærden. Hvis den krypterede upstream bliver utilgængelig, fejler videresenderen så lukket, falder den tilbage til klartekst, eller falder den tilbage til en anden resolver? Den beslutning hører i registret, fordi den ændrer privatlivsgarantien i det øjeblik, hvor tunnelen er mindst sund.

Bekræft, hvilket hop der er krypteret

Start på klienten, og bekræft, om den har en TLS-session til port 853. En forespørgsel, der slår korrekt op gennem port 53, beviser intet 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

Gå derefter til VPN-værten, og se efter den udgående krypterede forbindelse, som videresenderen åbnede. Sockettabellen fortæller, om der findes en upstream-TLS-session, og hvilken proces der ejer den:

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

Hvis klienten viser en TLS-session, og serveren ikke viser nogen, er du i den første opsætning, og serveren kan ikke læse forespørgsler, som den videresender på IP-niveau. Hvis serveren viser TLS-sessionen, og klienten viser almindelig trafik på port 53 inde i tunnelen, er du i den anden opsætning: det næste hop er beskyttet, og videresenderen læser stadig hvert navn, enheden spørger om. Det andet resultat er ikke en fejl, men at kalde det ende-til-ende-kryptering er forkert.

Registrér ejeren og fejladfærden

Ejerskab afgør, hvad du må love. Enhedens ejer styrer en krypteret forbindelse på klientsiden, mens VPN-administratoren styrer den videre forbindelse, som videresenderen opretter. Den, der ikke driver nogen af dem, kan kun beskrive vejen.

Kontrollér intern navngivning, før du aktiverer noget. At sende organisationsnavne til en offentlig resolver er ikke et tilsvarende design, og en split-horizon-zone, der kun findes inde i netværket, slår slet ikke op upstream. Test ét internt og ét offentligt navn efter ændringen, og gem resultatet sammen med konfigurationsændringen. Hvis den krypterede vej ødelægger opslag for interne værter, er rettelsen en resolverregel med afgrænset omfang, ikke en bredere tunnel.

Afslut med at skrive én sætning pr. hop: hvilken komponent der modtog forespørgslen, om det hop var krypteret, og hvem der kan læse navnet. Når sætningen for VPN-værten stadig siger, at den kan læse forespørgsler, bør dokumentationen sige det, for et diagram, der påstår det modsatte, vil blive troet af en, der aldrig kørte kommandoerne.