Benarkan DNS hanya melalui penyelesai VPN anda: panduan langkah demi langkah

Jejaki satu carian nama dari saat anda menaipnya. Pelayar bertanya kepada sistem pengendalian, sistem pengendalian bertanya kepada penyelesai yang dipilih oleh dasarnya, dan pertanyaan itu keluar dari peranti melalui antara muka tertentu dengan pengangkutan tertentu. Reka bentuk VPN anda mengatakan jawapan sepatutnya datang dari penyelesai tertentu melalui laluan tertentu. Jurang antara kedua-dua kenyataan itu ialah apa yang anda konfigurasikan dan kemudian kuatkuasakan.

Langkah 1: namakan penyelesai dan laluan

Tulis tiga perkara sebelum menyentuh tembok api: alamat penyelesai, protokol dan port yang anda jangkakan, dan antara muka tempat pertanyaan harus keluar. Tanpa senarai itu, peraturan ialah tekaan tentang trafik dan bukan pelaksanaan sesuatu keputusan. VPN boleh membawa data aplikasi sementara DNS mengikut susunan berasingan, dan itu sendiri bukan kesilapan. Itulah yang berlaku apabila tiada siapa memberitahu klien sebaliknya.

Menamakan laluan secara jelas ialah perbezaan antara reka bentuk dan kemalangan. Ia juga memberi anda sesuatu untuk diuji kemudian, kerana setiap pemerhatian boleh dibandingkan dengan jangkaan bertulis. Simpan senarai itu dalam tiket perubahan dan bukan dalam kepala seseorang.

Langkah 2: letakkan dasar di tempat ia benar-benar tinggal

Pemilihan penyelesai milik klien: konfigurasi rangkaian sistem pengendalian, tetapan klien VPN itu sendiri, atau dasar pelayar yang diuruskan. Letakkannya di sana dahulu, dengan mekanisme yang disokong platform, kerana tembok api tidak boleh memaksa klien memilih penyelesai yang tidak pernah diberitahu kepadanya. Pada klien terowong berpecah, nyatakan dengan jelas domain mana yang pergi ke penyelesai dalaman. Dalam armada terurus, dasar pelayar selalunya satu-satunya tuas untuk DoH, kerana pelayar boleh memilih penyelesai tersulitnya sendiri secara bebas daripada tetapan sistem.

Langkau ini dan terus ke tembok api, dan anda mendapat peraturan yang membenarkan penyelesai yang betul serta klien yang tidak pernah menggunakannya. Peraturan itu kelihatan betul dan log penyelesai kekal kosong, pasangan yang mengelirukan semasa menyahpepijat. Konfigurasikan pilihan dahulu, kemudian kuatkuasakannya.

Langkah 3: kuatkuasakan laluan secara sempit

Sekarang tambah kebenaran rangkaian untuk laluan yang dibenarkan: alamat penyelesai, protokol dan port, serta antara muka tempat ia harus keluar. Kekalkan peraturan terhad kepada penyelesai itu dan bukan membenarkan semua DNS keluar. Tiga laluan di bawah ialah yang boleh diambil klien moden, dan hanya yang pertama diliputi peraturan port 53.

Menyekat DoH dan DoT adalah sah; menganggap peraturan port 53 sudah menyekatnya tidak. Pelayar dengan DoH menyelesaikan nama melalui laluan yang tidak pernah dijelaskan peraturan anda, dan aplikasi yang membawa penyelesainya sendiri melakukan perkara yang sama. Tulis setiap laluan yang hendak anda benarkan dan setiap satu yang hendak anda tolak. Peraturan yang tidak menamakan laluan belum memutuskan apa-apa mengenainya.

Langkah 4: jejaki nama peribadi dan awam

DNS berpecah sengaja menghantar hanya ruang nama peribadi ke penyelesai dalaman sementara nama awam pergi ke tempat lain, jadi lebih daripada satu penyelesai dalam reka bentuk bukan kebocoran. Kebocoran ialah pertanyaan yang sepatutnya pergi ke penyelesai anda tetapi tiba di tempat lain, atau laluan yang dirancang tidak dapat dicapai sehingga klien berundur secara senyap. Dua kes itulah yang perlu dicari. Jejaki satu nama dalaman dan satu nama awam di bawah dasar yang dirancang dan catat penyelesai mana yang menjawab setiap satu.

Tapak ujian yang melaporkan penyelesai anda ialah petunjuk, bukan bukti, kerana ia hanya melihat pertanyaan yang sampai kepadanya. Tangkap pertanyaan di sisi klien apabila anda perlu tahu laluan mana yang sebenarnya diambil, kemudian bandingkan kedua-dua pemerhatian. Apabila keduanya tidak sepadan, anda telah menemui unduran yang tidak didokumenkan oleh sesiapa.

Jika alamat penyelesai betul tetapi tidak dapat dicapai, masalahnya ada pada penghalaan atau penapisan dan bukan dasar. Jejaki pertanyaan ke alamat itu dan sahkan jawapan kembali melalui antara muka yang dijangka sebelum menukar mana-mana tetapan penyelesai.

Langkah 5: tinggalkan jalan pulang

Sebelum mengetatkan akses DNS pada get laluan, sahkan kaedah pemulihan yang tidak bergantung pada penyelesaian nama. Penyelesai yang rosak menjadikan setiap alat pembaikan lebih sukar dicapai, termasuk yang akan anda gunakan untuk membatalkan perubahan. Biarkan konsol setempat atau laluan luar jalur terbuka sehingga dasar baharu terbukti. Buangkannya hanya selepas dasar itu bertahan melalui satu sambungan semula.

Selepas sambungan semula atau kemas kini dasar pelayar, periksa semula keadaan berkesan, kerana kedua-duanya boleh menukar penyelesai tanpa menukar peraturan anda. Keperluannya ialah penerima yang diketahui dan laluan terlindung untuk pertanyaan, bukan label penyelesai yang menenangkan pada satu tangkapan skrin. Spesifikasi RFC 8484 untuk DNS over HTTPS ialah rujukan bagi laluan tersulit yang tidak dilihat peraturan port anda.