Nama dalaman gagal menerusi VPN sedangkan laman awam berjaya diselesaikan

Seorang pengguna melaporkan bahawa nama hos intranet tidak diselesaikan melalui VPN. Laporan kedua, dari komputer riba yang sama, mengatakan ujian kebocoran masih menunjukkan pertanyaan dijawab oleh penyelesai setempat. Kedua-duanya kedengaran seperti satu masalah tetapi sebenarnya dua, dengan bukti berbeza, dan pembaikan biasa untuk yang pertama menjadikan yang kedua lebih teruk. Asingkan kedua-duanya sebelum menyentuh sebarang tetapan.

Dua gejala yang bukan satu kerosakan

Gagal menyelesaikan nama dalaman bermakna pertanyaan pergi ke tempat yang tiada jawapan untuknya. Pertanyaan yang keluar dari terowong bermakna pertanyaan pergi ke tempat yang salah walaupun jawapannya tersedia. Itu kegagalan yang bertentangan: satu jawapan yang hilang, satu lagi destinasi tambahan.

Perangkapnya ialah menambah penyelesai pejabat di semua tempat membetulkan yang pertama dan menjamin yang kedua. Menambah penyelesai awam di semua tempat melakukan sebaliknya.

Catat kedua-dua pemerhatian dengan cap masa, kemudian lalui empat semakan di bawah mengikut urutan.

Penyelesai penyesuai mana yang menerima pertanyaan

Pada Windows, klien DNS memilih pelayan mengikut susunan pengikatan penyesuai, dan penyesuai terowong tidak semestinya pertama. Buka tetapan lanjutan penyesuai dan alihkan sambungan akses jauh ke atas penyesuai fizikal, kemudian sambung semula supaya perubahan terpakai pada sesi baharu.

Susunan pengikatan hanyalah separuh pertama. Klien juga perlu tahu nama mana milik penyesuai itu, dan itu soalan akhiran, bukan soalan susunan.

Letakkan ipconfig /all komputer yang berfungsi di sebelah komputer riba, kedua-duanya diambil semasa terowong aktif. Komputer yang berfungsi akan menunjukkan akhiran DNS khusus sambungan pada penyesuai pejabatnya, manakala komputer riba mungkin tidak menunjukkan apa-apa pada terowong. Perbezaan itu menjelaskan seluruh kelas laporan tentang pelayan yang ada di situ tetapi nama masih gagal, kerana tanpa akhiran nama pendek tidak pernah dilengkapkan ke zon yang dilayan oleh penyelesai pejabat.

Nama pendek memerlukan akhiran sebelum memerlukan laluan

Menulis nama hos tanpa kelayakan meminta penyelesai meneka domain. Tekaan itu datang daripada senarai akhiran yang dilampirkan pada sambungan, dan jika senarai itu kosong pertanyaan keluar sebagai satu label yang tidak akan dipadankan oleh mana-mana zon peribadi.

Salin akhiran komputer yang berfungsi ke sifat IPv4 penyesuai VPN pada tab DNS, kemudian sambung semula. Pada Linux yang setara ialah domain carian pada pautan terowong, yang didedahkan systemd-resolved setiap pautan dan bukan secara global.

Simpan kedua-dua tetapan secara berasingan dalam nota anda. Akhiran mengubah apa yang ditanya, alamat penyelesai mengubah siapa yang ditanya. Membetulkan satu sedangkan yang lain salah menghasilkan keputusan yang kelihatan rawak.

Tanya penyelesai secara terus, kemudian nama

Pertanyaan terus kepada penyelesai pejabat memisahkan masalah nama daripada masalah laluan, kerana ia memintas pemilihan penyelesai klien sepenuhnya.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Perintah pertama meminta pelayan tertentu untuk nama yang layak sepenuhnya. Jika ia menjawab, penyelesai dan laluan kepadanya baik dan kerosakan ada pada pemilihan atau akhiran. Jika ia tamat masa, alamat salah atau tidak boleh dicapai dan masalahnya ialah penghalaan, bukan DNS. Perintah kedua menunjukkan apa yang berlaku dengan nama pendek, dan yang ketiga mencetak konfigurasi penyelesai setiap pautan pada hos systemd.

Perhatikan jawapan kad bebas, yang dikembalikan oleh sesetengah rangkaian untuk nama tidak diketahui. Balasan yang kelihatan munasabah bukan bukti bahawa pelayan yang dimaksudkan menjawab, jadi bandingkan alamat yang dikembalikan dengan yang sebenarnya digunakan oleh perkhidmatan dalaman. Jika alamat itu milik halaman parkir atau proksi, penyelesai menjawab tetapi jawapannya bukan milik anda. Perbezaan itu menjimatkan sejam mengejar terowong yang sebenarnya berfungsi sepanjang masa.

Pada Linux, klien VPN yang menulis semula /etc/resolv.conf menggantikan penyelesai tempatan sepenuhnya. vpnc mendedahkan DNSUpdate no untuk menghentikannya, dan systemd-resolved boleh menghalakan hanya domain tersenarai ke pautan terowong. Kedua-dua pendekatan mengekalkan nama awam pada penyelesai tempatan sambil menghantar nama dalaman ke pejabat.

Kebocoran ialah peraturan, bukan kotak semak

Penyelesaian nama ialah pertukaran UDP ke port 53, jadi terowong yang membawa trafik web tetapi bukan UDP membiarkan pertanyaan pada laluan fizikal. Buktikan dengan menangkap pada NIC fizikal semasa nama awam diselesaikan. Pertanyaan yang kelihatan pada antara muka itu dalam bentuk boleh dibaca bermakna terowong tidak membawanya.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Jika pertanyaan muncul pada antara muka itu dalam bentuk boleh dibaca, terowong tidak membawanya. Pembaikan ialah peraturan yang membenarkan port 53 hanya kepada penyelesai yang dihantar oleh VPN dan menggugurkan destinasi lain, serta konfigurasi klien yang tidak membuang pilihan yang dihantar secara senyap.

Bahagian terakhir itu lebih penting daripada yang kelihatan. Mulakan OpenVPN dengan route-nopull dan pilihan DNS yang dihantar hilang bersama laluan, melainkan penapis tarik diperluas untuk mengekalkannya. dan klien yang mengabaikan dhcp-option DNS akan terus menggunakan apa sahaja yang ada sebelum ini. Sebarang perubahan di sebelah pelayan memerlukan sesi baharu untuk berkuat kuasa, kerana senarai penyelesai dihantar apabila terowong naik dan sesi lapuk terus menunjukkan keadaan lama.

Catat kegagalan mana yang sebenarnya anda perhatikan sebelum menutup tiket. Jawapan dalaman yang hilang dan pertanyaan yang terlepas dari terowong memerlukan pembaikan berbeza, dan perubahan akhiran yang membetulkan yang pertama boleh secara senyap memburukkan yang kedua. Sesiapa yang mengambil tiket itu seterusnya akan mempercayai label, jadi pastikan label itu tepat.