Cara membaca perutean DNS VPN per tautan dari resolvectl
resolvectl status menampilkan server, domain, dan rute bawaan per tautan. Baca semuanya bersama, lalu tanyakan namanya dan catat tautan mana yang menjawab.
Jalankan resolvectl status dan Anda mendapat dinding blok per tautan, masing-masing dengan servernya sendiri dan baris domainnya sendiri. Baris yang menentukan perutean adalah daftar domain, bukan alamat server nama, karena stub lokal meneruskan setiap kueri ke tautan yang mengklaim nama itu. Baca klaim itu sebelum membaca jawabannya, lalu tanyakan namanya dan periksa tautan mana yang menghasilkannya. Jawaban salah dari tautan yang benar adalah masalah berbeda dari jawaban benar dari tautan yang salah.
Apa yang diberitahukan setiap blok per tautan
Setiap blok mencantumkan server yang akan dipakai resolver untuk antarmuka itu, daftar domain, dan apakah tautan itu rute bawaan. Daftar domain adalah kumpulan klaim, dan resolver menerapkan pencocokan akhiran terpanjang: kueri untuk host.corp.example diklaim oleh tautan yang membawa corp.example sebelum tautan yang hanya membawa rute bawaan. Dua tautan yang mengklaim akhiran yang sama menyerahkan hasilnya kepada prioritas dan urutan, karena itu duplikat layak diperhatikan lebih dulu. Baris server saat ini menunjukkan server mana dari daftar itu yang dipakai pada saat tersebut.
Alamat stub seperti 127.0.0.53 di /etc/resolv.conf hanya mengatakan bahwa stub ada di depan. Alamat itu tidak menyebut sumber hulu yang menjawab, karena itu diagnosis yang hanya bersandar pada resolv.conf akan mandek.
Baca ketiga jenis entri domain dengan benar
| Entri | Apa yang diklaim | Kesalahan umum |
|---|---|---|
| corp.example | domain perutean dan akhiran pencarian: nama di bawahnya menuju tautan ini, dan string itu ditambahkan ke nama telanjang | dihapus karena perutean tampaknya tetap bekerja |
| ~corp.example | hanya rute: nama di bawahnya menuju tautan ini, tetapi akhiran tidak ditambahkan | dianggap perlu untuk perutean |
| ~. | rute bawaan: mengklaim kueri yang tidak dicakup tautan lain | dibiarkan aktif pada profil terpisah, sehingga nama publik mengikuti terowongan |
Tilde mengubah perilaku pencarian, bukan perutean. Entri tanpa tilde adalah domain perutean sekaligus domain pencarian, jadi nama di bawahnya dikirim ke tautan itu dan nama berlabel tunggal mendapat akhiran. Entri bertilde merutekan akhiran yang sama tetapi menjaganya di luar daftar pencarian. Karena itu menghapus tilde mengubah nama telanjang mana yang diresolusi, dan karena itu tilde yang hilang adalah masalah pencarian, bukan kegagalan DNS terpisah.
Entri rute bawaan mengklaim semua yang tidak dicakup tautan lain. Profil terowongan penuh biasanya menginginkannya dan profil terpisah biasanya tidak, karena nama publik lalu berjalan ke resolver privat dan bisa gagal di sana. Baca tabel itu terhadap maksud profil, bukan menyalin tanda antarprofil. Ketika dua tautan mengklaim akhiran yang sama, selesaikan soal prioritas sebelum menyunting hal lain.
Tanyakan sebuah nama dan lihat tautan mana yang menjawab
Subperintah query mencetak alamat, protokol, dan tautan atau cakupan yang menghasilkan jawaban. Uji satu nama yang seharusnya diklaim akhiran privat dan satu nama publik biasa, lalu bandingkan sumber yang dilaporkan. Jika nama privat menjawab dari tautan nirkabel, klaimnya hilang atau terowongannya mati; jika nama publik pada profil terpisah menjawab dari terowongan, rute bawaannya terlalu luas. Kedua kegagalan itu terlihat sama di peramban dan berlawanan di keluaran ini.
resolvectl status
resolvectl query host.corp.examplePerhatikan juga protokol yang dilaporkan, karena jawaban dari singgahan atau dari berkas hosts bisa datang tanpa satu pun sumber hulu ditanyai. Jawaban dari singgahan membuktikan nama itu pernah diresolusi, bukan bahwa kebijakan saat ini merutekannya dengan benar.
Pisahkan perutean nama dari perutean paket
Keputusan resolver tidak menciptakan jalur. Server yang dipilih tetap butuh rute ke alamatnya, dan alamat yang dikembalikan tetap butuh rute ke jaringan privat, jadi kebijakan DNS yang benar bisa hidup berdampingan dengan koneksi yang tidak pernah terbuka. Ketika nama teresolusi dan aplikasi gagal, periksa alamat dan rutenya daripada mengubah DNS lagi. Resolusi nama dan keterjangkauan adalah dua pertanyaan dengan dua pemilik berbeda.
Aplikasi dapat melewati resolver sistem sepenuhnya lewat setelan DNS aman miliknya sendiri atau resolver bawaan. Hasil resolvectl menjelaskan jalur sistem, dan peramban yang mengabaikannya akan berbeda pendapat dengan setiap uji yang Anda lakukan. Periksa setelan itu sebelum menyimpulkan kebijakannya rusak.
Catat alamat tempat nama itu teresolusi di samping tautannya. Nama benar yang menunjuk alamat salah adalah masalah rekaman, bukan masalah perutean.
Periksa ulang setelah tautan berubah
Menyambung ulang atau berpindah jaringan nirkabel membangun ulang keadaan tautan, dan manajer jaringan dapat memasang kembali domain serta servernya di atas apa pun yang diatur dengan tangan. Setelah itu tanyakan kedua nama yang sama dan bandingkan dengan garis dasar yang tercatat. Jika suntingan manual hilang, perbaikannya ada di profil koneksi dan bukan di perintah shell. Mencatat sebelum dan sesudah itulah yang membuatnya terlihat.
Bagikan hanya nama dan konteks server yang dibutuhkan laporan, karena akhiran internal membocorkan topologi. Dokumentasi systemd-resolved tentang perutean domain mencakup aturan pencocokan terpanjang dan perilaku tilde, dan membacanya sekali mencegah sebagian besar kesalahan tabel di atas: perutean kueri di systemd-resolved.