DNS terpisah dan VPN: peraturan domain bukan laluan IP
DNS terpisah memilih penyelesai mengikut nama, dan jawapan masih perlukan laluan. Uji peraturan domain dan laluan secara berasingan, pada platform yang benar-benar anda jalankan.
Komputer riba anda menyelesaikan intranet.corp melalui terowong sementara gitlab.com terus pergi ke penyelesai pembekal, dan itulah susunan yang berfungsi seperti direka. Dua keputusan berasingan menghasilkannya: peraturan padanan nama memilih penyelesai, dan laluan membawa jawapan kembali. Rosakkan mana-mana satu dan pelayar menunjukkan kegagalan yang kelihatan sama dari luar. Kebanyakan laporan DNS terpisah menerangkan kegagalan kedua sambil memetik bukti tentang yang pertama.
Kedua-dua separuh tinggal di tempat berbeza dan biasanya disunting oleh orang berbeza. Satu ialah dasar DNS yang dilampirkan pada profil VPN, satu lagi ialah laluan yang dipasang atau ditahan oleh terowong. Nyahpepijat terhenti apabila tiada siapa menetapkan separuh mana yang benar-benar bergerak.
Dua keputusan tersembunyi dalam satu permintaan
Separuh nama ialah objek dasar, bukan laluan. Pada Windows ia dasar penyelesaian nama pada profil VPN; pada platform Apple satu set domain padanan pada objek tetapan DNS; pada Linux domain penghalaan, baris penyelesai terpisah atau susunan suis perkhidmatan nama. Separuh laluan ialah penghalaan biasa, dipasang oleh terowong atau dengan tangan, dan ia tidak tahu apa itu nama hos. Profil yang menerima akhiran hanya memutuskan siapa yang menjawab; ia tidak pernah menjadikan jawapan itu boleh dicapai.
Ujian simptom pantas memisahkan kedua-duanya: gantikan nama dengan alamat. Jika alamat berfungsi, laluan betul dan peraturan salah. Jika alamat juga gagal, peraturan mungkin betul dan laluan mungkin tiada.
Bagaimana setiap platform menyatakan peraturan nama yang sama
Niatnya sama dan nama medan tidak. Contoh yang disalin dari satu klien ke klien lain dihuraikan dengan bersih dan tidak pernah sepadan. Ketiga-tiga bentuk kelihatan seperti ini:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Domain padanan atau penghalaan ialah ujian akhiran, jadi intranet.corp meliputi git.intranet.corp dan tidak meliputi corp.intranet, dan menterbalikkannya ialah kesilapan paling biasa dalam seluruh persediaan. Windows membawa pemetaan itu sebagai dasar penyelesaian nama yang dilampirkan pada profil, dengan susunan keutamaannya sendiri terhadap mana-mana senarai akhiran yang sudah ada pada antara muka. Platform Apple melampirkan domain padanan pada objek tetapan DNS sambungan rangkaian, dan sistem menggunakannya bagi setiap penyelesai berskop. Tiada satu pun bentuk ini ialah laluan, dan tiada satu pun boleh menjadikan alamat tidak tercapai menjadi boleh dicapai. Rujukan dasar penyelesaian nama Windows menyenaraikan nama medan dan peraturan keutamaan untuk platform itu, dan ia bukan yang digunakan oleh dokumen Apple atau systemd.
Jawapan yang betul masih perlukan laluan
Jawapan penyelesai hanyalah alamat, dan aplikasi masih perlu mencapainya. Reka bentuk terowong terpisah sering menolak 10.20.0.0/16 dan menahan laluan lalai, jadi nama dalaman diselesaikan dan sambungan kemudian tergantung. Kes sebaliknya sama biasa: laluan wujud, penyelesai awam menjawab nama peribadi dengan NXDOMAIN, dan kegagalan direkodkan sebagai masalah penghalaan. Menguji laluan dahulu membuatkan anda memandang laluan untuk nama yang tidak akan pernah diselesaikan.
Terdapat juga pintu ketiga yang tidak diliputi oleh mana-mana separuh. ACL pada get laluan, peraturan tembok api atau dasar sebelah klien boleh menggugurkan sambungan selepas kedua-dua keputusan betul. Apabila nama diselesaikan, laluan wujud dan sambungan masih tamat masa, berhenti menguji DNS.
Menguji nama dan laluan dalam susunan tetap
Pilih satu susunan dan kekalkan, jika tidak anda akan mengejar langkah yang terakhir gagal. Selesaikan nama dalaman penuh yang didokumenkan, sahkan jawapannya alamat yang boleh dibawa jadual laluan, kemudian ulangi dengan nama awam untuk membuktikan terowong tidak menangkap semuanya. Pada hos systemd, pertanyaan dan domain penghalaan penyelesai terletak satu arahan jauhnya:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10
Klien Windows bertanya dua soalan yang sama dengan cmdlet berbeza. Yang kedua melaporkan antara muka yang sebenarnya akan digunakan oleh sistem:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10
Jika carian mengembalikan alamat dan pemeriksaan laluan menamakan antara muka fizikal, peraturan nama berfungsi dan laluan tidak. Jika nama pendek gagal sementara nama penuh diselesaikan, senarai akhiran yang salah, bukan penyelesai.
Di mana perbandingan biasanya salah
Kesilapan pertama ialah bertanya penyelesai awam tidak berkaitan tentang nama peribadi dan membaca penolakan sebagai bukti tentang VPN. Yang kedua ialah menganggap carian awam yang berfungsi membuktikan laluan penyelesai terowong. Yang ketiga ialah memperlakukan terowong terpisah dan DNS terpisah sebagai satu keputusan reka bentuk, sedangkan penggunaan boleh betul dalam satu dan rosak dalam yang lain. Setiap kesilapan menghasilkan kesimpulan yakin daripada ujian yang tidak pernah melatih bahagian yang dituduh.
Pelayar dengan DNS selamatnya sendiri juga boleh memintas peraturan sistem, sebab itulah satu pelayar gagal sementara yang lain berjaya bukan percanggahan. Bandingkan penyelesai yang menjawab, bukan pelayar yang mengadu.
Sebaik sahaja kedua-dua separuh kelihatan, soalan yang tinggal ialah soalan dasar dan bukan teknikal: ruang nama mana milik organisasi, siapa memiliki setiap jawapan, dan mana antaranya harus meninggalkan mesin sama sekali. Tuliskan itu di sebelah profil, kerana orang seterusnya yang menyentuh peraturan akan memerlukannya.