Krypterar din VPN DNS, eller bara nästa hopp?

Att slå på krypterad DNS på VPN-servern beskrivs ofta som att täppa igen ett läckage, och den beskrivningen döljer vilken anslutning som ändrades. Hoppet från klienten till resolvern och hoppet från resolvern till uppströms är separata anslutningar med separata ägare. Att kryptera den ena lämnar den andra precis som den var.

Skriv ner vem som tar emot frågan i varje steg innan du rör en konfigurationsfil.

Två uppsättningar ser likadana ut på en inställningssida

I den första uppsättningen kör enheten DNS over TLS själv, och tunneln transporterar bara den anslutningen till en resolver du valde. TLS-sessionen avslutas hos resolvern, vilket betyder att resolvern ser frågan och VPN-utgången ser krypterad text som den inte kan läsa. I den andra uppsättningen skickar enheten vanlig DNS genom tunneln till en vidarebefordrare på VPN-värden, och den vidarebefordraren öppnar sin egen krypterade anslutning till en uppströms resolver. I en funktionslista ser båda ut som "krypterad DNS med VPN", och de placerar den läsbara frågan i olika byggnader.

Skillnaden är mätbar, inte filosofisk. Leta efter TLS-sessionen på klienten eller på servern, så vet du vilken uppsättning du faktiskt har.

Kartlägg resolverkedjan innan du ändrar den

Räkna resolvrarna på vägen och namnge rollen för var och en. En vidarebefordrande komponent lämnar en begäran till en annan resolver, medan en rekursiv resolver gör arbetet med att hitta ett svar och kan prata direkt med auktoritativa servrar. Dessa roller definieras separat just av denna anledning, och resolverdefinitionerna i RFC 9076 är värda att läsa innan du antar att det bara finns en uppströms destination. En värd som kör sin egen rekursiva resolver har ingen enda "uppström" att kryptera, vilket gör hela planen ogiltig.

Fråga sedan vilken komponent klienten är konfigurerad att använda. En DNS-adress som VPN-profilen skickar ut talar om vart frågorna går, inte vilken process som svarar på dem.

Notera också beteendet vid fel. Om den krypterade uppströmsförbindelsen blir onåbar, misslyckas vidarebefordraren då stängt, faller den tillbaka till klartext eller växlar den till en annan resolver? Det beslutet hör hemma i protokollet, eftersom det ändrar integritetsgarantin i det ögonblick då tunneln är som minst frisk.

Verifiera vilket hopp som är krypterat

Börja på klienten och bekräfta om den har en TLS-session till port 853. En fråga som löses korrekt via port 53 bevisar 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

Gå sedan till VPN-värden och leta efter den utgående krypterade anslutning som vidarebefordraren öppnade. Sockettabellen talar om ifall en uppströms TLS-session finns och vilken process som äger den:

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

Om klienten visar en TLS-session och servern ingen, är du i den första uppsättningen och servern kan inte läsa frågor som den vidarebefordrar på IP-nivå. Om servern visar TLS-sessionen och klienten vanlig port 53-trafik inne i tunneln, är du i den andra uppsättningen: nästa hopp är skyddat, och vidarebefordraren läser fortfarande varje namn enheten frågar efter. Det andra resultatet är inte ett fel, men att kalla det ände-till-ände-kryptering är fel.

Anteckna ägaren och beteendet vid fel

Ägandet avgör vad du får lova. Enhetens ägare kontrollerar en krypterad anslutning på klientsidan, medan VPN-administratören kontrollerar nästa anslutning som dennes vidarebefordrare skapar. Den som inte driver någon av dem kan bara beskriva vägen.

Innan du aktiverar något, kontrollera intern namngivning. Att skicka organisationsnamn till en offentlig resolver är ingen likvärdig design, och en split-horizon-zon som bara finns inne i nätet löses inte alls uppströms. Testa ett internt och ett offentligt namn efter ändringen och spara resultatet tillsammans med konfigurationsändringen. Om den krypterade vägen bryter upplösningen för interna värdar är rättelsen en resolverregel med begränsad omfattning, inte en bredare tunnel.

Avsluta med att skriva en mening per hopp: vilken komponent som tog emot frågan, om hoppet var krypterat och vem som kan läsa namnet. När meningen om VPN-värden fortfarande säger att den kan läsa frågor, bör dokumentationen säga det, för ett diagram som påstår motsatsen kommer att litas på av någon som aldrig körde kommandona.