Adakah VPN anda menyulitkan DNS, atau hanya hop seterusnya?

Mengaktifkan DNS tersulit pada pelayan VPN sering digambarkan sebagai menutup kebocoran, dan gambaran itu menyembunyikan sambungan mana yang berubah. Hop dari klien ke penyelesai dan hop dari penyelesai ke huluan ialah sambungan berasingan dengan pemilik berasingan. Menyulitkan salah satunya membiarkan yang lain tetap seperti dahulu.

Catat siapa yang menerima pertanyaan pada setiap peringkat sebelum anda menyentuh fail konfigurasi.

Dua susunan kelihatan sama pada halaman tetapan

Dalam susunan pertama peranti menjalankan DNS over TLS sendiri, dan terowong hanya membawa sambungan itu kepada penyelesai yang anda pilih. Sesi TLS tamat di penyelesai, bermakna penyelesai melihat pertanyaan itu dan laluan keluar VPN melihat teks tersulit yang tidak dapat dibacanya. Dalam susunan kedua peranti menghantar DNS biasa melalui terowong kepada penghantar di hos VPN, dan penghantar itu membuka sambungan tersulitnya sendiri kepada penyelesai huluan. Kedua-duanya kelihatan seperti "DNS tersulit dengan VPN" dalam senarai ciri, dan kedua-duanya meletakkan pertanyaan yang boleh dibaca di bangunan yang berbeza.

Perbezaannya boleh diukur, bukan falsafah. Cari sesi TLS pada klien atau pada pelayan, dan anda tahu susunan mana yang sebenarnya anda miliki.

Petakan rantai penyelesai sebelum anda mengubahnya

Kira penyelesai pada laluan dan namakan peranan setiap satu. Komponen penghantaran menyerahkan permintaan kepada penyelesai lain, manakala penyelesai rekursif melakukan kerja mencari jawapan dan boleh bercakap terus dengan pelayan berwibawa. Peranan itu ditakrifkan secara berasingan semata-mata atas sebab ini, dan takrif penyelesai RFC 9076 wajar dibaca sebelum anda menganggap hanya ada satu destinasi huluan. Hos yang menjalankan penyelesai rekursifnya sendiri tidak mempunyai satu "huluan" untuk disulitkan, yang membatalkan seluruh rancangan.

Kemudian tanya komponen mana yang klien dikonfigurasikan untuk gunakan. Alamat DNS yang ditolak oleh profil VPN memberitahu anda ke mana pertanyaan pergi, bukan proses mana yang menjawabnya.

Perhatikan juga tingkah laku kegagalan. Jika huluan tersulit menjadi tidak dapat dicapai, adakah penghantar gagal tertutup, kembali kepada teks biasa, atau beralih kepada penyelesai lain? Keputusan itu perlu ada dalam rekod, kerana ia mengubah jaminan privasi pada saat terowong paling tidak sihat.

Sahkan hop mana yang tersulit

Mulakan pada klien dan sahkan sama ada ia memegang sesi TLS ke port 853. Pertanyaan yang diselesaikan dengan betul melalui port 53 tidak membuktikan apa-apa tentang penyulitan.

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

Kemudian bergerak ke hos VPN dan cari sambungan tersulit keluar yang dibuka oleh penghantar. Jadual soket memberitahu anda sama ada sesi TLS huluan wujud, dan proses mana yang memilikinya:

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

Jika klien menunjukkan sesi TLS dan pelayan tidak menunjukkan apa-apa, anda berada dalam susunan pertama dan pelayan tidak dapat membaca pertanyaan yang dihantarnya pada lapisan IP. Jika pelayan menunjukkan sesi TLS dan klien menunjukkan trafik port 53 biasa di dalam terowong, anda berada dalam susunan kedua: hop seterusnya dilindungi, dan penghantar masih membaca setiap nama yang diminta peranti. Hasil kedua itu bukan kegagalan, tetapi menyebutnya penyulitan hujung ke hujung adalah salah.

Rekod pemilik dan tingkah laku kegagalan

Pemilikan menentukan apa yang anda dibenarkan janjikan. Pemilik peranti mengawal sambungan tersulit di sisi klien, manakala pentadbir VPN mengawal sambungan seterusnya yang dicipta oleh penghantarnya. Sesiapa yang tidak mengendalikan kedua-duanya hanya boleh menggambarkan laluan itu.

Sebelum mengaktifkan apa-apa, periksa penamaan dalaman. Menghantar nama organisasi kepada penyelesai awam bukan reka bentuk yang setara, dan zon split-horizon yang hanya wujud di dalam rangkaian tidak akan diselesaikan langsung di huluan. Uji satu nama dalaman dan satu nama awam selepas perubahan, dan simpan hasilnya bersama perubahan konfigurasi. Jika laluan tersulit memecahkan penyelesaian untuk hos dalaman, pembaikannya ialah peraturan penyelesai berskop, bukan terowong yang lebih lebar.

Akhiri dengan menulis satu ayat bagi setiap hop: komponen mana yang menerima pertanyaan, sama ada hop itu tersulit, dan siapa yang boleh membaca nama itu. Apabila ayat tentang hos VPN masih mengatakan ia boleh membaca pertanyaan, dokumentasi harus menyatakannya, kerana rajah yang mendakwa sebaliknya akan dipercayai oleh seseorang yang tidak pernah menjalankan perintah itu.