Laptop Anda menyelesaikan intranet.corp melalui terowongan sementara gitlab.com terus menuju resolver penyedia, dan itulah susunan yang bekerja sebagaimana dirancang. Dua keputusan terpisah menghasilkannya: aturan pencocokan nama memilih resolver, dan rute membawa jawabannya kembali. Rusak salah satunya dan browser menampilkan kegagalan yang dari luar tampak sama. Sebagian besar laporan DNS terbelah menjabarkan kegagalan kedua sambil mengutip bukti tentang yang pertama.

Kedua belahan hidup di tempat berbeda dan biasanya disunting oleh orang berbeda. Satu adalah kebijakan DNS yang dilekatkan pada profil VPN, yang lain adalah rute yang dipasang atau ditahan terowongan. Penelusuran kesalahan berhenti ketika tidak ada yang menetapkan belahan mana yang sebenarnya bergerak.

Dua keputusan tersembunyi dalam satu permintaan

Belahan nama adalah objek kebijakan, bukan rute. Di Windows itu kebijakan resolusi nama pada profil VPN; di platform Apple sekumpulan domain pencocokan pada objek pengaturan DNS; di Linux domain perutean, baris resolver terbelah, atau urutan sakelar layanan nama. Belahan jalur adalah perutean biasa, dipasang oleh terowongan atau dengan tangan, dan tidak tahu apa itu nama host. Profil yang mengizinkan sufiks hanya memutuskan siapa yang menjawab; ia tidak pernah membuat jawaban itu terjangkau.

Uji gejala singkat memisahkan keduanya: ganti nama dengan alamat. Jika alamatnya bekerja, jalurnya benar dan aturannya salah. Jika alamatnya juga gagal, aturannya mungkin benar dan jalurnya hilang.

Bagaimana setiap platform mengungkapkan aturan nama yang sama

Maksudnya identik dan nama bidangnya tidak. Contoh yang disalin dari satu klien ke klien lain terurai dengan bersih dan tidak pernah cocok. Ketiga bentuknya tampak seperti ini:

PlatformWhere the rule livesWhat usually breaks
Windowsname-resolution policy on the VPN profileprecedence against the interface suffix list
Apple platformsmatch domains on the DNS settings objectdomains attached to the wrong extension
Linuxrouting domain, split resolver, nsswitch orderthe suffix written the wrong way round

Domain pencocokan atau perutean adalah uji sufiks, jadi intranet.corp mencakup git.intranet.corp dan tidak mencakup corp.intranet, dan membalikkannya adalah kesalahan paling umum dalam seluruh penyiapan. Windows membawa pemetaan sebagai kebijakan resolusi nama yang dilekatkan pada profil, dengan urutan prioritasnya sendiri terhadap daftar sufiks apa pun yang sudah dimiliki antarmuka. Platform Apple melekatkan domain pencocokan ke objek pengaturan DNS ekstensi jaringan, dan sistem menerapkannya per resolver berlingkup. Tidak ada satu pun bentuk ini yang merupakan rute, dan tidak ada yang bisa membuat alamat tak terjangkau menjadi terjangkau. Referensi kebijakan resolusi nama Windows mencantumkan nama bidang dan aturan prioritas untuk platform itu, dan itu bukan aturan yang dipakai dokumen Apple atau systemd.

Jawaban benar tetap butuh jalur

Jawaban resolver hanyalah sebuah alamat, dan aplikasi tetap harus mencapainya. Desain terowongan terbelah biasanya mendorong 10.20.0.0/16 dan menahan rute default, sehingga nama internal terselesaikan lalu koneksi menggantung. Kasus sebaliknya sama umumnya: rutenya ada, resolver publik menjawab nama privat dengan NXDOMAIN, dan kegagalannya dicatat sebagai masalah perutean. Menguji jalur lebih dulu membuat Anda menatap rute untuk nama yang tidak akan pernah terselesaikan.

Ada juga gerbang ketiga yang tidak dicakup kedua belahan. ACL di gateway, aturan firewall, atau kebijakan sisi klien dapat menjatuhkan koneksi setelah kedua keputusan benar. Ketika nama terselesaikan, rutenya ada, dan koneksi tetap habis waktu, berhentilah menguji DNS.

Menguji nama dan jalur dalam urutan tetap

Pilih satu urutan dan pegang itu, atau Anda akan mengejar langkah yang terakhir gagal. Selesaikan nama internal lengkap yang didokumentasikan, pastikan jawabannya alamat yang bisa dibawa tabel rute, lalu ulangi dengan nama publik untuk membuktikan terowongan tidak menangkap semuanya. Di host systemd kueri dan domain perutean resolver berjarak satu perintah:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Klien Windows menanyakan dua pertanyaan yang sama dengan cmdlet berbeda. Yang kedua melaporkan antarmuka yang sebenarnya akan dipakai sistem:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Jika pencarian mengembalikan alamat dan pemeriksaan jalur menyebut antarmuka fisik, aturan nama bekerja dan rutenya tidak. Jika nama pendek gagal sementara nama lengkap terselesaikan, daftar sufiksnya salah, bukan resolver.

Di mana perbandingan biasanya salah

Kesalahan pertama adalah menanyakan resolver publik tak berhubungan tentang nama privat dan membaca penolakan sebagai bukti tentang VPN. Yang kedua adalah menganggap pencarian publik yang bekerja membuktikan jalur resolver terowongan. Yang ketiga adalah memperlakukan terowongan terbelah dan DNS terbelah sebagai satu keputusan desain, padahal penerapan bisa benar di satu dan rusak di lainnya. Setiap kesalahan menghasilkan kesimpulan percaya diri dari uji yang tidak pernah melatih bagian yang disalahkan.

Browser dengan DNS amannya sendiri juga bisa melewati aturan sistem, karena itu satu browser gagal sementara yang lain berhasil bukanlah pertentangan. Bandingkan resolver yang menjawab, bukan browser yang mengeluh.

Setelah kedua belahan terlihat, pertanyaan yang tersisa adalah pertanyaan kebijakan dan bukan teknis: ruang nama mana yang milik organisasi, siapa pemilik setiap jawaban, dan mana yang seharusnya meninggalkan mesin sama sekali. Tuliskan itu di samping profil, karena orang berikutnya yang menyentuh aturan akan membutuhkannya.

Artikel terkait