Šifruje li vaš VPN DNS ili samo sljedeći hop?
Šifrovani DNS na VPN serveru štiti drugi hop od DoT-a na strani klijenta. Pratite ko prima svaki upit prije nego što bilo što uključite.
Uključivanje šifrovanog DNS-a na VPN serveru često se opisuje kao zatvaranje curenja, a taj opis skriva koja se veza promijenila. Hop od klijenta do resolvera i hop od resolvera do uzvodnog servera dvije su odvojene veze s odvojenim vlasnicima. Šifrovanje jedne ostavlja drugu točno onakvom kakva je bila.
Zapišite ko prima upit u svakoj fazi prije nego što dirnete konfiguracijsku datoteku.
Dva rasporeda izgledaju isto na stranici s postavkama
U prvom rasporedu uređaj sam pokreće DNS over TLS, a tunel samo prenosi tu vezu do resolvera koji ste odabrali. TLS sesija završava na resolveru, što znači da resolver vidi upit, a VPN izlaz vidi šifrat koji ne može pročitati. U drugom rasporedu uređaj šalje običan DNS kroz tunel do prosljeđivača na VPN hostu, a taj prosljeđivač otvara vlastitu šifrovanu vezu prema uzvodnom resolveru. Oba u popisu značajki izgledaju kao "šifrovani DNS s VPN-om", a čitljivi upit smještaju u različite zgrade.
Razlika je mjerljiva, a ne filozofska. Potražite TLS sesiju na klijentu ili na serveru i saznat ćete koji raspored zapravo imate.
Mapirajte lanac resolvera prije nego što ga promijenite
Prebrojite resolvere na putu i imenujte ulogu svakoga. Prosljeđivačka komponenta predaje zahtjev drugom resolveru, dok rekurzivni resolver obavlja posao pronalaženja odgovora i može izravno razgovarati s autoritativnim serverima. Te su uloge upravo zato definirane odvojeno i definicije resolvera u RFC 9076 vrijedi pročitati prije nego što pretpostavite da postoji jedno uzvodno odredište. Host koji pokreće vlastiti rekurzivni resolver nema jedinstveni "uzvodni" koji bi šifrovao, što cijeli plan čini nevažećim.
Zatim pitajte koju je komponentu klijent konfiguriran koristiti. DNS adresa koju VPN profil gura govori kamo upiti idu, a ne koji proces na njih odgovara.
Zabilježite i ponašanje pri kvaru. Ako šifrovani uzvodni resolver postane nedostupan, prosljeđivač pada zatvoreno, vraća se na otvoreni tekst ili prelazi na drugi resolver? Ta odluka pripada u zapis jer mijenja jamstvo privatnosti u trenutku kada je tunel najmanje zdrav.
Provjerite koji je hop šifrovan
Počnite na klijentu i potvrdite drži li TLS sesiju prema portu 853. Upit koji se ispravno razriješi kroz port 53 ne dokazuje ništa o šifrovanju.
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
Zatim prijeđite na VPN host i potražite odlaznu šifrovanu vezu koju je prosljeđivač otvorio. Tablica socketa kaže postoji li uzvodna TLS sesija i koji je proces posjeduje:
ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short
Ako klijent pokazuje TLS sesiju, a server nikakvu, u prvom ste rasporedu i server ne može čitati upite koje prosljeđuje na IP sloju. Ako server pokazuje TLS sesiju, a klijent običan promet na portu 53 unutar tunela, u drugom ste rasporedu: sljedeći je hop zaštićen, ali prosljeđivač i dalje čita svako ime koje uređaj traži. Taj drugi rezultat nije neuspjeh, ali nazivati ga end-to-end šifrovanjem je pogrešno.
Zapišite vlasnika i ponašanje pri kvaru
Vlasništvo odlučuje što smijete obećati. Vlasnik uređaja kontrolira šifrovanu vezu na strani klijenta, dok VPN administrator kontrolira sljedeću vezu koju stvara njegov prosljeđivač. Tko ne upravlja nijednom, može samo opisati put.
Prije nego što bilo što uključite, provjerite interno imenovanje. Slanje organizacijskih imena javnom resolveru nije ekvivalentan dizajn, a split-horizon zona koja postoji samo unutar mreže neće se uzvodno razriješiti nikako. Nakon promjene isprobajte jedno interno i jedno javno ime i rezultat čuvajte uz promjenu konfiguracije. Ako šifrovani put pokvari razrješavanje internih hostova, rješenje je pravilo resolvera ograničenog opsega, a ne širi tunel.
Završite tako što ćete za svaki hop napisati jednu rečenicu: koja je komponenta primila upit, je li taj hop bio šifrovan i tko može pročitati ime. Kada rečenica za VPN host još uvijek kaže da može čitati upite, dokumentacija bi to trebala reći, jer će dijagramu koji tvrdi suprotno vjerovati neko ko nikada nije pokrenuo te naredbe.