Pautan mana yang menjawab: domain penghalaan untuk DNS VPN terowong berpecah

Kekalkan pelayaran biasa pada pautan tempatan sementara nama syarikat diselesaikan melalui pelayan DNS yang disediakan terowong. Mematikan laluan lalai VPN memberi anda separuh pertama dan membiarkan separuh kedua tidak dibina. Berikut ialah tetapan yang hilang, tanda baca yang mengubah maksudnya, dan satu-satunya arahan yang menunjukkan pautan mana yang benar-benar menjawab. NetworkManager dan systemd-resolved diandaikan sepanjang teks, kerana pasangan itulah tempat kekeliruan biasanya bermula.

Langkah satu: pisahkan laluan daripada penyelesai

ipv4.never-default menjawab soalan penghalaan dan menghalang NetworkManager daripada memasang sambungan ini sebagai laluan untuk semua trafik IPv4. Domain penghalaan DNS menjawab soalan lain: pelayan nama pautan mana yang menerima pertanyaan untuk akhiran yang sepadan. Kedua-duanya tidak saling membayangkan, dan profil boleh membawa salah satunya bertahun-tahun sementara yang lain tiada. Laluan sahaja bermaksud terowong membawa subnet syarikat dan penyelesainya menjawab nama syarikat, manakala semua yang lain dibiarkan.

Tetapkan sifat laluan sahaja dan nama dalaman gagal, biasanya dengan tamat masa yang kedengaran seperti terowong rosak. Tetapkan domain sahaja dan anda telah menambah akhiran carian secara senyap pada setiap nama pendek pada mesin. Kedua-dua kesilapan menghantar tiket ke pelayan VPN, yang jarang menjadi bahagian yang salah.

Langkah dua: tambah domain penghalaan sahaja pada profil

Andaikan sambungan itu bernama corp-vpn, akhiran syarikat ialah internal.example, dan penyelesai terowong sudah boleh dicapai. Baca nilai semasa dahulu, kerana arahan di bawah mengubah sifat yang mungkin sudah mengandungi entri.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Gantikan dengan nama sambungan dan akhiran anda sendiri, kerana nilai di atas hanyalah ilustrasi. Tanda tambah lebih penting daripada kelihatan: dengannya nilai ditambah pada senarai sedia ada, manakala tanpanya sifat diganti dan domain tidak berkaitan hilang daripada profil yang berfungsi semalam. Tilde mengubah tingkah laku, bukan gaya, dan perenggan di bawah menerangkan apa yang dipilihnya. Kekalkan pembacaan sebelum penulisan, supaya bentuk penggantian tidak pernah mengejutkan anda.

Tilde di hadapan menandakan domain penghalaan sahaja, jadi pertanyaan yang sepadan pergi ke pelayan pautan ini dan akhiran tidak ditambah pada nama pendek. Buang tilde dan rentetan yang sama juga menjadi akhiran carian, hasil berbeza yang jarang dimaksudkan orang. Kedua-dua tetapan di atas ialah IPv4, jadi profil tindanan berganda memerlukan ipv6.never-default dan domain penghalaan yang sama dalam ipv6.dns-search, jika tidak bahagian IPv6 terus menggunakan laluan lalai dan nama dalaman gagal di sana.

Langkah tiga: tanya resolvectl pautan mana yang menjawab

Jalankan resolvectl status dan baca pelayan DNS serta domain setiap pautan, kemudian jalankan resolvectl query host.internal.example terhadap nama dalaman sebenar yang anda dibenarkan menyoal. Arahan kedua ialah satu-satunya bukti langsung bahawa domain penghalaan menjalankan tugasnya, kerana ia menamakan pautan yang menjawab. Senarai status sahaja membuktikan konfigurasi; pertanyaan membuktikan penyelesaian.

systemd-resolved memilih domain penghalaan yang paling sepadan, jadi domain yang lebih khusus pada pautan lain masih boleh memenangi perlumbaan. Jika pertanyaan kembali dari pautan yang tidak anda jangkakan, baca senarai domain sebelum menyentuh pelayan DNS VPN. Domain akar ~. sepadan dengan segala-galanya, dan jika ia sudah ada domain khusus anda masih menang untuk namanya sendiri sementara pautan menjawab jauh lebih banyak daripada yang diminta. Padam atau sempitkan entri akar itu apabila tujuannya hanya nama syarikat.

Jika pautan VPN tidak menyenaraikan sebarang pelayan DNS, klien tidak pernah mendaftarkan satu pun. Domain penghalaan tanpa pelayan di belakangnya gagal secara berbeza daripada domain yang hilang, jadi betulkan pendaftaran dahulu.

Langkah empat: apabila nama diselesaikan tetapi perkhidmatan tidak

Jawapan yang betul hanya membuktikan penyelesaian berjaya, dan aplikasi masih memerlukan laluan ke alamat yang diterimanya. Laluan itu mesti bertahan melalui laluan lalai terpisah yang baru anda konfigurasikan, jadi periksa sebelum menyalahkan DNS lagi. Kemudian periksa kebolehcapaian pada port perkhidmatan, kerana perkongsian fail atau perkhidmatan direktori gagal pada penyelesaian, penghalaan atau pengesahan dan menghasilkan mesej yang sangat serupa dalam setiap kes. Pisahkan ketiga-tiga lapisan itu semasa melaporkan hasil, atau orang seterusnya menyemak semula DNS yang sudah betul.

Perubahan Samba yang beredar bersama soalan ini menyentuh lapisan akses, bukan pilihan DNS. Mengaplikasikannya pada kegagalan penyelesaian nama ialah cara masalah kecil mendapat masalah kedua.

Langkah lima: jangan ganti penyelesai untuk membaiki domain yang hilang

Nasihat yang menimpa fail penyelesai atau memasang pengurus penyelesai lain menyelesaikan masalah berbeza. Itu perubahan integrasi sistem dengan mod kegagalan sendiri, dan tiada satu pun menambah domain penghalaan yang tidak pernah dikonfigurasikan. Tentukan komponen mana yang memiliki penyelesaian nama pada mesin sebelum menggantinya, kerana pada desktop NetworkManager dengan systemd-resolved pemilikan itu sudah ditetapkan. Melawannya ialah cara persediaan yang berfungsi menjadi sesuatu yang tiada siapa dapat menghasilkan semula.

Urutan kerja: pastikan terowong menyediakan penyelesai, tambah domain penghalaan sahaja, sambung semula melalui kawalan profil, sahkan pautan yang menjawab, kemudian uji perkhidmatan pada portnya. Urutan itu meninggalkan hasil yang boleh anda serahkan kepada orang seterusnya tanpa temu bual kedua.