Mengapa resolv.conf menampilkan DNS VPN Anda tetapi pencarian mengabaikannya

Tidak ada yang tampak salah di log: antarmuka aktif, resolver melaporkan server DNS milik VPN, dan berkas di disk mencantumkannya. Namun nama host internal masih diselesaikan melalui router lokal. Ketiga pernyataan itu tidak saling bertentangan, karena berkas, keadaan per tautan, dan jalur pencarian adalah objek berbeda yang kebetulan berbagi nama. Berikut ini jalur yang benar-benar ditempuh sebuah kueri di host dengan systemd-resolved.

Tiga objek bernama resolv.conf

Di host dengan resolved, /etc/resolv.conf biasanya berupa tautan simbolik ke /run/systemd/resolve/stub-resolv.conf. Target itu menyimpan alamat pendengar stub lokal, 127.0.0.53, ditambah domain pencarian yang dihitung resolved. Ini adalah tampilan keadaan, bukan keadaan itu sendiri.

Keadaan hidup dalam konfigurasi resolved per tautan, dan itulah sebabnya resolvectl status bisa berbeda pendapat dengan berkas itu dan tetap benar. Setiap tautan membawa server dan domain peruteannya sendiri, dan stub memeriksa data itu saat kueri datang. Panduan systemd-resolved menjelaskan berkas yang dihasilkan dan model per tautan; pemisahan antara tampilan dan keadaan adalah bagian yang layak diingat. Mengubah target tautan simbolik mengubah apa yang dibaca klien tradisional, bukan apa yang diketahui resolver.

Objek ketiga, /run/systemd/resolve/resolv.conf, meratakan setiap tautan menjadi satu daftar server. Program yang diarahkan ke berkas itu mengirim kueri langsung ke server yang tercantum dan melewati stub, sehingga kebijakan per tautan tidak lagi berlaku untuknya. Karena itu dua program di mesin yang sama bisa menjawab nama yang sama secara berbeda, dan tidak ada yang rusak.

Lacak satu pencarian melalui NSS

glibc membaca /etc/nsswitch.conf untuk memutuskan siapa yang menjawab sebuah nama. Baris hosts yang memuat resolve mengarahkan pertanyaan ke nss-resolve, yang bertanya kepada resolved lewat D-Bus dan menerima jawaban per tautan. Baris yang hanya memuat files dns mengirim kueri ke alamat apa pun yang dipegang /etc/resolv.conf.

Baris tunggal itu menjelaskan sebagian besar perselisihan antara peramban dan dig. dig membaca resolv.conf secara langsung dan tidak pernah menyentuh NSS, jadi ia menguji stub atau server hulu alih-alih jalur yang dipakai aplikasi. getent hosts internal.example melewati NSS, dan membandingkan jawabannya dengan jawaban dig adalah pengukuran pertama yang berguna.

Aplikasi yang membawa resolver sendiri, atau berbicara DNS melalui HTTPS ke titik akhir tetap, melewati kedua jalur itu. Tidak ada apa pun di resolv.conf atau di keadaan resolved yang membatasi mereka.

Periksa siapa pemilik berkas dan ke mana ia menunjuk

Baca rantai tautan sebelum mengubah apa pun, karena kepemilikan menentukan berkas mana yang berwenang. Setiap perintah di bawah hanya membaca keadaan.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Baris pertama mencetak tautan dan targetnya bersama-sama, dan berkas biasa yang dimiliki skrip VPN berarti resolver tidak pernah memperlakukan tulisan itu sebagai masukan. Keluaran status mendaftar server per tautan plus domain perutean yang menentukan ke mana setiap kueri pergi. Baris nsswitch menyatakan apakah stub diperiksa sama sekali, sehingga alamat stub di berkas tanpa resolve di sana berarti kueri mencapai pendengar lokal sementara tidak ada yang mengelola pemisahan. Daftar terakhir itu juga penting, karena host tanpa stub-resolv.conf tidak menjalankan tataan yang dijelaskan di sini.

Jika rantai berakhir pada berkas yang dikelola paket lain, klien VPN dan paket itu adalah dua pemilik yang harus direkonsiliasi. Mengganti tautan membuang kerja satu pemilik dan membiarkan kerja pemilik lain di tempatnya.

Perbaiki di pemilik tautan

Koneksi VPN seharusnya mendaftarkan server dan domainnya pada tautannya sendiri, lalu menariknya kembali saat terputus. Integrasi resolved milik NetworkManager dan pembantu milik klien sama-sama bekerja begitu; skrip yang hanya menulis ulang resolv.conf tidak.

Pada tautan yang sudah ada, pengaturan runtime menunjukkan mekanismenya. resolvectl dns tun0 10.40.0.53 melampirkan server, dan resolvectl domain tun0 '~corp.example' melampirkan domain perutean. Tilde adalah karakter pemikul beban: ia membatasi kueri untuk sufiks itu pada tautan ini dan membiarkan sisanya, sedangkan nilai yang sama tanpa tilde menjadi domain pencarian dan pemisahannya menguap. Alamat-alamat itu contoh laboratorium, bukan konfigurasi permanen. Pastikan dengan resolvectl query host.corp.example dan baca tautan mana yang menjawab.

Server yang terdaftar tetap memerlukan rute. Ketika kueri mencapai tautan yang benar lalu kehabisan waktu, kesalahannya ada pada keterjangkauan melalui terowongan, bukan pada kepemilikan resolver.

Bagaimana keadaan yang berfungsi terlihat

Hasil yang sehat konsisten di ketiga tampilan: server per tautan cocok dengan yang diberikan VPN, domain perutean hanya mencakup sufiks internal, dan aplikasi yang penting menyelesaikan nama internal sementara nama publik tetap mengikuti jalur lokal. Satu kueri yang berhasil membuktikan lebih sedikit daripada kesepakatan itu.

Lalu putuskan koneksi dan ulangi kedua kueri. Klien yang membiarkan domainnya terdaftar setelah pembongkaran menghasilkan mesin yang gagal pada pencarian internal berjam-jam kemudian, tanpa terowongan terbuka dan tanpa sebab yang jelas.