Tautan mana yang menjawab: domain perutean untuk DNS VPN terowongan terpisah

Pertahankan penjelajahan biasa di tautan lokal sementara nama perusahaan diresolusi melalui server DNS yang disediakan terowongan. Mematikan rute bawaan VPN memberi Anda separuh pertama dan membiarkan separuh kedua belum dibangun. Berikut adalah pengaturan yang hilang, tanda baca yang mengubah maknanya, dan satu perintah yang menunjukkan tautan mana yang benar-benar menjawab. NetworkManager dan systemd-resolved diasumsikan sepanjang teks, karena pasangan itulah tempat kebingungan biasanya dimulai.

Langkah satu: pisahkan rute dari resolver

ipv4.never-default menjawab pertanyaan perutean dan mencegah NetworkManager memasang koneksi ini sebagai jalur bagi semua lalu lintas IPv4. Domain perutean DNS menjawab pertanyaan lain: server nama tautan mana yang menerima kueri untuk sufiks yang cocok. Tidak satu pun menyiratkan yang lain, dan profil bisa membawa salah satunya bertahun-tahun sementara yang lain hilang. Hanya-rute berarti terowongan membawa subnet perusahaan dan resolver-nya menjawab nama perusahaan, sedangkan semua yang lain dibiarkan.

Setel hanya properti rute dan nama internal gagal, biasanya dengan batas waktu yang terdengar seperti terowongan rusak. Setel hanya domain dan Anda diam-diam menambahkan sufiks pencarian ke setiap nama pendek di mesin. Kedua kesalahan mengirim tiket ke server VPN, yang jarang menjadi bagian yang salah.

Langkah dua: tambahkan domain khusus perutean ke profil

Misalkan koneksi bernama corp-vpn, sufiks perusahaan adalah internal.example, dan resolver terowongan sudah dapat dijangkau. Baca nilai saat ini dulu, karena perintah di bawah mengubah properti yang mungkin sudah berisi 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

Ganti dengan nama koneksi dan sufiks Anda sendiri, karena nilai di atas hanya ilustrasi. Tanda plus lebih penting daripada kelihatannya: dengannya nilai ditambahkan ke daftar yang ada, sedangkan tanpanya properti diganti dan domain tak terkait hilang dari profil yang kemarin berfungsi. Tilde mengubah perilaku, bukan gaya, dan paragraf di bawah menjelaskan apa yang dipilihnya. Pertahankan pembacaan sebelum penulisan, agar bentuk penggantian tidak pernah mengejutkan Anda.

Tilde di awal menandai domain khusus perutean, jadi kueri yang cocok pergi ke server tautan ini dan sufiks tidak ditambahkan ke nama pendek. Lepas tilde dan string yang sama juga menjadi sufiks pencarian, hasil berbeda yang jarang dimaksudkan orang. Kedua pengaturan di atas adalah IPv4, jadi profil tumpukan ganda memerlukan ipv6.never-default dan domain perutean yang sama di ipv6.dns-search, atau sisi IPv6 tetap memakai rute bawaan dan nama internal gagal di sana.

Langkah tiga: tanyakan ke resolvectl tautan mana yang menjawab

Jalankan resolvectl status dan baca server DNS serta domain setiap tautan, lalu jalankan resolvectl query host.internal.example terhadap nama internal nyata yang boleh Anda kueri. Perintah kedua adalah satu-satunya bukti langsung bahwa domain perutean menjalankan tugasnya, karena perintah itu menyebut tautan yang menjawab. Daftar status saja membuktikan konfigurasi; kueri membuktikan resolusi.

systemd-resolved memilih domain perutean yang paling cocok, jadi domain yang lebih spesifik di tautan lain masih bisa memenangkan perlombaan. Jika kueri kembali dari tautan yang tidak Anda duga, baca daftar domain sebelum menyentuh server DNS VPN. Domain akar ~. cocok dengan semuanya, dan jika sudah ada, domain spesifik Anda tetap menang untuk namanya sendiri sementara tautan menjawab jauh lebih banyak daripada yang diminta. Hapus atau sempitkan entri akar itu ketika tujuannya hanya nama perusahaan.

Jika tautan VPN sama sekali tidak mencantumkan server DNS, klien tidak pernah mendaftarkan satu pun. Domain perutean tanpa server di belakangnya gagal berbeda dari domain yang hilang, jadi perbaiki pendaftaran dulu.

Langkah empat: ketika nama teresolusi tetapi layanan tidak

Jawaban yang benar hanya membuktikan resolusi berhasil, dan aplikasi masih memerlukan rute ke alamat yang diterimanya. Rute itu harus bertahan melewati rute bawaan terpisah yang baru Anda konfigurasi, jadi periksa sebelum menyalahkan DNS lagi. Lalu periksa keterjangkauan pada porta layanan, karena berbagi berkas atau layanan direktori gagal pada resolusi, perutean, atau autentikasi dan menghasilkan pesan yang sangat mirip dalam setiap kasus. Pisahkan ketiga lapisan itu saat melaporkan hasil, atau orang berikutnya memeriksa ulang DNS yang sudah benar.

Perubahan Samba yang beredar bersama pertanyaan ini menyentuh lapisan akses, bukan pilihan DNS. Menerapkannya pada kegagalan resolusi nama adalah cara masalah kecil mendapat masalah kedua.

Langkah lima: jangan mengganti resolver untuk memperbaiki domain yang hilang

Saran yang menimpa berkas resolver atau memasang manajer resolver lain memecahkan masalah berbeda. Itu perubahan integrasi sistem dengan mode kegagalan sendiri, dan tidak satu pun menambahkan domain perutean yang tidak pernah dikonfigurasi. Tetapkan komponen mana yang memiliki resolusi nama di mesin sebelum menggantinya, karena di desktop NetworkManager dengan systemd-resolved kepemilikan itu sudah ditetapkan. Melawannya adalah cara penyiapan yang berfungsi menjadi sesuatu yang tidak dapat direproduksi siapa pun.

Urutan kerja: pastikan terowongan menyediakan resolver, tambahkan domain khusus perutean, sambungkan ulang melalui kontrol profil, verifikasi tautan yang menjawab, lalu uji layanan pada portanya. Urutan itu meninggalkan hasil yang dapat Anda serahkan kepada orang berikutnya tanpa wawancara kedua.