Šifruje váš VPN DNS, alebo len ďalší skok?

Zapnutie šifrovaného DNS na serveri VPN sa často opisuje ako uzavretie úniku a tento opis skrýva, ktoré spojenie sa zmenilo. Skok od klienta k resolveru a skok od resolvera k nadradenej úrovni sú oddelené spojenia s oddelenými vlastníkmi. Zašifrovanie jedného necháva druhé presne také, aké bolo.

Zapíšte si, kto prijíma požiadavku v každej fáze, skôr než sa dotknete konfiguračného súboru.

Dve usporiadania vyzerajú na stránke nastavení rovnako

V prvom usporiadaní zariadenie samo spúšťa DNS over TLS a tunel iba prenáša toto spojenie k resolveru, ktorý ste si vybrali. Relácia TLS sa končí na resolveri, čo znamená, že resolver vidí požiadavku a výstup VPN vidí šifrovaný text, ktorý nedokáže prečítať. V druhom usporiadaní zariadenie posiela bežné DNS cez tunel do preposielača na hostiteľovi VPN a ten preposielač otvára vlastné šifrované spojenie s nadradeným resolverom. V zozname funkcií obe vyzerajú ako "šifrované DNS s VPN", ale čitateľnú požiadavku umiestňujú do rôznych budov.

Rozdiel je merateľný, nie filozofický. Hľadajte reláciu TLS na klientovi alebo na serveri a dozviete sa, ktoré usporiadanie skutočne máte.

Pred zmenou zmapujte reťazec resolverov

Spočítajte resolvery na ceste a pomenujte úlohu každého z nich. Preposielajúci komponent odovzdá požiadavku inému resolveru, kým rekurzívny resolver robí prácu pri hľadaní odpovede a môže priamo komunikovať s autoritatívnymi servermi. Tieto úlohy sú definované oddelene presne z tohto dôvodu a definície resolverov z RFC 9076 stojí za prečítanie, skôr než budete predpokladať, že existuje jediný nadradený cieľ. Hostiteľ, ktorý prevádzkuje vlastný rekurzívny resolver, nemá jedinú "nadradenú úroveň" na šifrovanie, čo zneplatňuje celý plán.

Potom sa opýtajte, ktorý komponent má klient nakonfigurovaný používať. Adresa DNS poskytovaná profilom VPN hovorí, kam požiadavky idú, nie ktorý proces na ne odpovedá.

Všimnite si aj správanie pri zlyhaní. Ak sa šifrovaná nadradená úroveň stane nedostupnou, zlyhá preposielač uzavretý, vráti sa k otvorenému textu alebo prepne na iný resolver? To rozhodnutie patrí do záznamu, pretože mení záruku súkromia v momente, keď je tunel najmenej zdravý.

Overte, ktorý skok je šifrovaný

Začnite na klientovi a overte, či má reláciu TLS na port 853. Požiadavka, ktorá sa správne vyrieši cez port 53, nepreukazuje o šifrovaní nič.

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

Potom prejdite na hostiteľa VPN a hľadajte odchádzajúce šifrované spojenie, ktoré otvoril preposielač. Tabuľka soketov vám povie, či existuje nadradená relácia TLS a ktorý proces ju vlastní:

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

Ak klient zobrazuje reláciu TLS a server žiadnu, ste v prvom usporiadaní a server nedokáže čítať požiadavky, ktoré preposiela na vrstve IP. Ak server zobrazuje reláciu TLS a klient bežnú prevádzku portu 53 vnútri tunela, ste v druhom usporiadaní: ďalší skok je chránený, ale preposielač stále číta každé meno, o ktoré zariadenie požiada. Druhý výsledok nie je zlyhanie, ale nazývať ho šifrovaním od konca po koniec je nesprávne.

Zaznamenajte vlastníka a správanie pri zlyhaní

Vlastníctvo rozhoduje o tom, čo smiete sľúbiť. Vlastník zariadenia ovláda šifrované spojenie na strane klienta, kým správca VPN ovláda ďalšie spojenie, ktoré vytvára jeho preposielač. Kto neprevádzkuje ani jedno z nich, môže cestu iba opísať.

Pred zapnutím čohokoľvek skontrolujte interné názvy. Posielať názvy organizácie do verejného resolvera nie je rovnocenný návrh a zóna split-horizon, ktorá existuje iba vnútri siete, sa nadradene vôbec nevyrieši. Po zmene otestujte jeden interný a jeden verejný názov a výsledok uchovajte spolu so zmenou konfigurácie. Ak šifrovaná cesta pokazí rozlišovanie názvov interných hostiteľov, opravou je pravidlo resolvera s obmedzeným rozsahom, nie širší tunel.

Na záver napíšte jednu vetu pre každý skok: ktorý komponent prijal požiadavku, či bol ten skok šifrovaný a kto môže prečítať názov. Keď veta o hostiteľovi VPN stále tvrdí, že dokáže čítať požiadavky, dokumentácia by to mala povedať, pretože diagramu, ktorý tvrdí opak, uverí niekto, kto nikdy nespustil tieto príkazy.