Adakah VPN Mengubah DNS Saya? Bandingkan Sebelum dan Selepas
Profil boleh memindahkan carian anda dengan sengaja. Bandingkan dasar penyelesai dan jawapan sebenar sebelum dan selepas VPN bersambung, dengan mengekalkan satu pemboleh ubah.
Anda menyambung terowong, membuka papan pemuka peribadi, dan nama itu diselesaikan kepada alamat yang tidak pernah anda lihat. Atau sebaliknya berlaku: pelayar terus berfungsi sementara alat baris arahan tiba-tiba tidak menyelesaikan apa-apa. Kedua-dua hasil datang daripada perubahan yang sama, dan orang biasanya menjelaskannya dengan satu ayat tentang VPN yang "menggunakan DNS sendiri", yang tidak cukup tepat untuk menyahpepijat atau mengesahkan. Dua soalan tersembunyi dalam ayat itu: carian mana yang sepatutnya diambil alih oleh profil ini, dan adakah mesin anda benar-benar menghantarnya kepada penyelesai yang diberikan kepadanya? Memisahkan kedua-duanya ialah keseluruhan kaedah, kerana ujian yang mencampurkannya memberi jawapan salah yang yakin dalam kedua-dua arah.
Mengapa profil menyediakan penyelesai
Di dalam terowong, nama di sebalik hujung jauh biasanya diselesaikan kepada alamat yang hanya wujud dalam rangkaian itu. Zon peribadi seperti corp.internal tidak mempunyai delegasi awam, jadi penyelesai yang menjawabnya mesti boleh dicapai dari dalam terowong. Mekanisme yang sama memenuhi tujuan kedua: apabila carian sebaliknya akan keluar melalui ISP anda, penyelesai di sisi jauh menyimpan pertanyaan di dalam laluan tersulit. Itulah sebabnya alamat pelayan DNS datang sebagai sebahagian daripada dasar sambungan dan bukan sebagai tetapan global yang anda pilih sekali untuk mesin.
Alamat itu sendiri tidak menentukan apa-apa. Penyelesai hanya boleh menjawab jika ada laluan kepadanya, dan kegagalan paling biasa ialah penyelesai yang boleh dicapai hanya semasa terowong naik. Apabila terowong jatuh dan dasar kekal, carian pergi ke alamat tanpa laluan, dan gejalanya ialah tamat masa dan bukan ralat bersih. Perbezaan itu penting apabila anda membaca hasil ujian seterusnya, kerana tamat masa menghantar orang ke tetapan pengangkutan yang tidak pernah terlibat.
Bandingkan kedua-dua reka bentuk sebelum membandingkan jawapan
Terowong penuh dan DNS berpecah menghasilkan jangkaan bertentangan, dan kedua-duanya bukan kerosakan. Di bawah terowong penuh setiap carian boleh berpindah kepada penyedia atau kepada penyelesai korporat, jadi nama awam yang menjawab berbeza selepas bersambung adalah dijangka. Di bawah DNS berpecah hanya domain yang disenaraikan pergi ke penyelesai peribadi manakala semua yang lain kekal setempat; dalam Windows senarai domain berada dalam Name Resolution Policy Table, dalam macOS dalam domain padanan tetapan DNS, dan pada hos systemd-resolved dalam domain penghalaan setiap pautan.
Itulah perbandingan yang perlu dibuat dahulu, kerana ia menentukan apa yang dikira sebagai kecacatan. Dengan DNS berpecah, nama awam yang menjawab dari penyelesai baharu ialah perkara yang wajar disiasat, manakala nama dalaman yang menjawab dengan betul ialah sistem yang menjalankan tugasnya. Dengan terowong penuh, anomali ialah nama awam yang masih menjawab dari penyelesai ISP anda. Dokumentasi Microsoft tentang penyelesaian nama VPN menerangkan susunan Windows bagi peraturan ini, termasuk bagaimana entri dasar yang sepadan dirujuk sebelum pelayan penyesuai itu sendiri.
Ada penyelesai ketiga di dalam bilik yang mudah dilupakan. DNS selamat pelayar menyelesaikan nama sendiri dan boleh terus menjawab selepas terowong mengubah dasar sistem pengendalian, jadi halaman yang dimuatkan membuktikan penyelesai pelayar berfungsi, bukan bahawa profil telah digunakan. Jika anda hanya membandingkan apa yang ditunjukkan pelayar, separuh masa anda menguji lapisan yang salah.
Rekod garis dasar dengan hanya satu pemboleh ubah
Tukar terowong. Jangan tukar nama, alat atau akhiran carian sekali gus dalam langkah yang sama. Pilih nama yang anda dibenarkan menyoal, catat aplikasi yang anda gunakan, dan tulis sama ada alamat yang kembali atau ralat yang tepat. Dalam Windows Get-DnsClientServerAddress -AddressFamily IPv4 mencetak pelayan setiap penyesuai dan Get-DnsClientNrptPolicy mencetak entri dasar; dalam Linux dengan systemd-resolved resolvectl status menunjukkan pelayan DNS dan domain penghalaan setiap pautan; dalam macOS scutil --dns mencetak susunan penyelesai yang benar-benar akan diikuti sistem.
Kemudian sambung melalui kawalan biasa klien dan ulangi arahan yang sama tepat. Simpan output pertama dan bukan ingatan tentangnya, kerana perbandingan itulah intinya dan bacaan kedua yang diambil selepas cache dikosongkan sudah menjadi ukuran lain. Jika garis dasar diambil dengan pelayar di hadapan dan larian selepas sambung berlaku dalam terminal, anda membandingkan dua penyelesai, bukan dua keadaan satu penyelesai.
Pertanyaan jelas dan carian aplikasi ialah ujian berbeza
Menyoal satu pelayan tertentu, dengan nslookup name 10.20.0.1 atau dig @10.20.0.1 name, membuktikan satu perkara: pelayan yang anda namakan menjawab apabila anda boleh mencapainya. Ia memintas logik pemilihan sepenuhnya, jadi ia tidak boleh memberitahu sama ada sistem akan memilih pelayan itu untuk nama ini. Gunakannya untuk menguji sama ada penyelesai yang diberikan boleh dicapai, dan jangan gunakannya untuk menguji dasar.
Carian melalui penyelesai setempat memang melaksanakan pemilihan. resolvectl query name menelusuri peraturan domain penghalaan yang sama dan melaporkan protokol mana yang menjawab, Resolve-DnsName dalam Windows melalui jadual dasar dan cache klien, dan scutil --dns menunjukkan susunan yang akan diikuti carian. Jalankan kedua-dua jenis dan simpan dalam lajur berasingan dalam nota anda. Pertanyaan jelas yang berjaya di sebelah carian aplikasi yang gagal ialah masalah penghalaan atau pemilihan, bukan penyelesai yang enggan berfungsi.
Cache berdiri antara anda dan jawapan. Sistem pengendalian, penyelesai stub setempat, pelayar dan cache negatif semuanya menyimpan hasil, jadi carian boleh berjaya tanpa satu paket pun meninggalkan mesin. Rekod hasil sebelum mengosongkan apa-apa: ipconfig /flushdns, resolvectl flush-caches atau sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder dalam macOS. Langkau set semula rangkaian yang luas pada peringkat ini, kerana ia memusnahkan bukti yang masih anda kumpulkan.
Apa maksud perbezaan itu
Bandingkan dua baris yang anda rekod dan kelaskan perubahan sebelum menyentuh satu tetapan pun.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Satu baris wajar diberi penekanan. Nama yang diselesaikan bukan perkhidmatan yang berfungsi, dan kejayaan DNS hanya mengatakan alamat ditemui. Ia tidak mengatakan apa-apa tentang penghantaran, peraturan tembok api atau sama ada akaun anda boleh menggunakan perkhidmatan itu, jadi akhiri dengan menguji aplikasi sebenar dan bukannya menganggap kegagalan itu pergi sendiri.
Pulihkan garis dasar dan sahkan
Putuskan sambungan melalui kawalan klien sendiri dan bukan dengan membunuh proses, kemudian baca semula tiga arahan yang sama. Pelayan setiap pautan, entri dasar dan jawapan untuk nama ujian anda sepatutnya kembali kepada garis dasar yang anda tulis lebih awal. Entri dasar yang tertinggal selepas pemutusan bersih ialah kecacatan sebenar yang wajar direkod, dan itulah sebabnya suntingan tangan pada fail penyelesai yang dijana ialah tabiat buruk: fail ditulis semula dan suntingan hilang, atau suntingan kekal dan memakukan penyelesai yang tidak lagi mempunyai laluan.
Telusuri senarai ini sekali, mengikut urutan. Tentukan reka bentuk mana yang dilaksanakan profil sebelum menilai apa-apa hasil. Kekalkan nama, alat dan akhiran sepanjang dua larian. Pisahkan pertanyaan jelas daripada carian aplikasi. Baca dasar berkesan, bukan hanya jawapan. Kosongkan cache terakhir, selepas perbandingan ditulis. Sahkan dengan aplikasi sebenar, kemudian but semula sekali dan pastikan keadaan terputus masih bersih.