DNS VPN versus DoH di browser: apa yang tidak bisa diceritakan tes kebocoran

Halaman tes kebocoran bilang DNS Anda baik-baik saja, lencana browser bilang aman, tetapi wiki internal tetap tidak mau dimuat. Ketiganya bisa benar sekaligus, karena alamat resolver bukan hal yang sama dengan kebijakan yang memilihnya atau jalur yang ditempuh kueri. Yang disebut orang sebagai kebocoran DNS sebenarnya satu pertanyaan: resolver mana yang menerima nama itu, dan apakah pilihan itu disengaja? Untuk merapikannya perlu tiga pemeriksaan, dan hanya yang terakhir melibatkan perubahan pengaturan.

Mitos satu: lencana menyebut nama resolver Anda

Tes kebocoran me-resolve nama uji dan melaporkan alamat yang menjawab. Tes ini tidak melaporkan kebijakan yang memilih resolver tersebut, dan ketika kueri dibungkus dalam DNS lewat HTTPS, kotak perantara di jalur sama sekali tidak bisa melihat namanya. Dua mesin yang sangat berbeda menghasilkan lencana menenangkan yang sama: satu di mana VPN mendorong 10.8.0.1 dan browser memakainya, dan satu di mana browser mengabaikan daftar sistem lalu mengirim nama itu lewat terowongan ke penyedianya yang terenkripsi.

Perbedaannya penting pada saat sebuah nama privat gagal. Pada pengaturan pertama resolver VPN menjawab untuk zona korporat; pada yang kedua browser tidak pernah bertanya, sehingga nama host pendek tidak ter-resolve dan kegagalannya tampak seperti VPN rusak. Pemeriksaan ini bukan tes kebocoran lain, melainkan pencarian nama yang hanya diketahui satu resolver.

Mitos dua: browser meninggalkan terowongan

DNS memilih alamat, perutean membawa koneksi, dan keduanya lapisan terpisah. Kueri yang dikirim ke penyedia DoH publik tetap TCP port 443 ke alamat yang bisa dirutekan. Jika tabel rute Anda mengirim rute default ke terowongan, kueri itu juga lewat terowongan. Merek resolver tidak menentukan jalurnya.

Yang diubah DoH browser adalah penerima nama-nama itu. Itu keputusan privasi sungguhan dan keputusan kebijakan sungguhan, tetapi bukan jalan pintas perutean. Jika syarat Anda adalah nama tetap bersama operator VPN, kueri terenkripsi ke pihak lain gagal memenuhi syarat itu sambil tetap memakai terowongan untuk koneksi sebenarnya.

Mitos tiga: setiap VPN mengalahkan setiap browser

DNS aman di browser punya mode, bukan sakelar: mati, penyedia default dengan cadangan, templat khusus, atau kebijakan yang dipaksakan sistem operasi atau organisasi. Kasus cadangan itulah yang menghasilkan laporan sesekali. Ketika titik akhir terenkripsi tidak terjangkau, browser bisa kembali ke resolver sistem, sehingga laptop yang sama me-resolve nama privat dengan benar pada hari Senin dan tidak pada hari Selasa.

Pada saat yang sama, sebagian besar klien VPN menyetel resolver sistem saat koneksi naik dan memulihkan yang sebelumnya saat koneksi putus. Browser yang memegang resolver terenkripsi khusus sama sekali tidak mengamati pemulihan itu. Itulah sebabnya profil yang sama berperilaku berbeda di dua laptop dan itulah sebabnya resolv.conf terlihat benar sementara browser masih bertanya kepada pihak lain.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Jalankan itu saat terhubung, catat domain mana yang diklaim setiap resolver, dan bandingkan dengan apa yang dilaporkan browser tentang modenya sendiri. Dokumentasi DoH Mozilla adalah gambaran yang wajar tentang bagaimana perilaku default dan cadangan browser seharusnya bekerja.

Keputusan ini punya tiga masukan, bukan satu

Nama privat, kepercayaan pada operator, dan keterjangkauan menentukan pengaturan yang tepat. Nama yang hanya diketahui resolver VPN memaksa DNS terbelah: sufiks privat pergi ke resolver yang didorong, dan sisanya mengikuti kebijakan yang Anda pilih untuk nama publik. Kepercayaan pada operator menentukan apakah nama publik juga harus pergi ke resolver itu atau ke layanan terpisah. Keterjangkauan menentukan apakah resolver terenkripsi pilihan Anda sama sekali bisa dipakai di jaringan ini.

Tidak satu pun baris ini merupakan rekomendasi universal. Resolver yang dijalankan VPN memusatkan pengamatan pada operator itu; layanan terpisah menambah satu lagi penerima nama yang ditanyakan. Tidak satu pun pengaturan membuktikan apa pun tentang penyimpanan kecuali Anda membaca kebijakannya.

Tuliskan keputusan per profil, karena pengaturan ini bergeser. Profil yang mendorong resolver bulan lalu mungkin hari ini tidak mendorong apa pun, dan browser akan dengan senang hati mempertahankan titik akhir khusus lama yang masih menjawab. Yang perlu ada di catatan adalah alamat resolver, sufiks yang dimilikinya, dan mode browser, bukan merek layanannya.

Uji kebijakan yang Anda kira sudah Anda konfigurasikan

Uji berdasarkan nama, bukan lencana. Resolve nama publik dan nama privat lewat resolver sistem, lalu ulangi di dalam browser dengan pengaturan DNS amannya sendiri pada mode yang hendak Anda pakai. Jika nama privat hanya gagal di browser, Anda telah menemukan ketidakcocokan penerima tanpa menyentuh satu pun pengaturan VPN.

Lalu sambungkan ulang dan periksa pemulihan, karena di situlah bug serah-terima hidup: putuskan, pastikan resolver sebelumnya kembali, sambungkan lagi, pastikan resolver yang didorong kembali. Terakhir, uji browser dengan kebijakan terkelola jika ada, karena mode itu bisa menolak perubahan Anda sepenuhnya dan diam-diam mempertahankan resolver sebelumnya.

Mulailah dari pertanyaan ruang nama dan Anda akan menghindari sebagian besar hal ini. Jika mesin harus menjangkau nama internal, resolver terenkripsi browser adalah keputusan hanya tentang separuh publik, dan separuh privat tetap bersama apa pun yang didorong VPN.