Mengapa resolv.conf menunjukkan DNS VPN anda tetapi carian mengabaikannya

Tiada apa dalam log kelihatan salah: antara muka aktif, penyelesai melaporkan pelayan DNS VPN, dan fail pada cakera menyenaraikannya. Namun nama hos dalaman masih diselesaikan melalui penghala tempatan. Ketiga-tiga kenyataan tidak bercanggah, kerana fail, keadaan setiap pautan dan laluan carian ialah objek berbeza yang kebetulan berkongsi nama. Berikut ialah laluan yang benar-benar dilalui oleh pertanyaan pada hos dengan systemd-resolved.

Tiga objek bernama resolv.conf

Pada hos dengan resolved, /etc/resolv.conf biasanya pautan simbolik kepada /run/systemd/resolve/stub-resolv.conf. Sasaran itu menyimpan alamat pendengar stub tempatan, 127.0.0.53, serta domain carian yang dikira resolved. Ia ialah paparan keadaan, bukan keadaan itu sendiri.

Keadaan hidup dalam konfigurasi resolved bagi setiap pautan, dan sebab itulah resolvectl status boleh bercanggah dengan fail dan masih betul. Setiap pautan membawa pelayan sendiri dan domain penghalaan sendiri, dan stub merujuk data itu apabila pertanyaan tiba. Manual systemd-resolved menerangkan fail yang dijana dan model setiap pautan; pemisahan antara paparan dan keadaan ialah bahagian yang wajar diingat. Menukar sasaran pautan simbolik mengubah apa yang dibaca klien tradisional, bukan apa yang diketahui penyelesai.

Objek ketiga, /run/systemd/resolve/resolv.conf, meratakan setiap pautan menjadi satu senarai pelayan. Program yang menunjuk ke fail itu menghantar pertanyaan terus kepada pelayan yang disenaraikan dan melangkau stub, jadi dasar setiap pautan tidak lagi terpakai kepadanya. Oleh itu dua program pada mesin yang sama boleh menjawab nama yang sama secara berbeza, dan kedua-duanya tidak rosak.

Jejaki satu carian melalui NSS

glibc membaca /etc/nsswitch.conf untuk menentukan siapa yang menjawab sesuatu nama. Baris hosts yang mengandungi resolve menghalakan soalan ke nss-resolve, yang bertanya kepada resolved melalui D-Bus dan menerima jawapan setiap pautan. Baris dengan hanya files dns menghantar pertanyaan ke alamat yang dipegang /etc/resolv.conf.

Baris tunggal itu menerangkan kebanyakan perselisihan antara pelayar dan dig. dig membaca resolv.conf secara langsung dan tidak pernah menyentuh NSS, jadi ia menguji stub atau pelayan huluan dan bukannya laluan yang digunakan aplikasi. getent hosts internal.example melalui NSS, dan membandingkan jawapannya dengan jawapan dig ialah ukuran pertama yang berguna.

Aplikasi yang membawa penyelesai sendiri, atau berbahasa DNS melalui HTTPS ke titik akhir tetap, memintas kedua-dua laluan. Tiada apa dalam resolv.conf atau dalam keadaan resolved yang mengekangnya.

Semak siapa pemilik fail dan ke mana ia menunjuk

Baca rantai pautan sebelum mengubah apa-apa, kerana pemilikan menentukan fail mana yang berwibawa. Setiap arahan 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 pautan dan sasarannya bersama-sama, dan fail biasa milik skrip VPN bermaksud penyelesai tidak pernah menganggap tulisan itu sebagai input. Output status menyenaraikan pelayan setiap pautan serta domain penghalaan yang menentukan ke mana setiap pertanyaan pergi. Baris nsswitch memberitahu sama ada stub dirujuk sama sekali, jadi alamat stub dalam fail tanpa resolve di situ bermaksud pertanyaan sampai ke pendengar tempatan sementara tiada apa mengurus pemisahan itu. Senarai terakhir itu juga penting, kerana hos tanpa stub-resolv.conf tidak menjalankan susunan yang diterangkan di sini.

Jika rantai berakhir pada fail yang diurus pakej lain, klien VPN dan pakej itu ialah dua pemilik yang perlu diselaraskan. Mengganti pautan membuang kerja satu pemilik dan membiarkan kerja pemilik lain di tempatnya.

Baiki pada pemilik pautan

Sambungan VPN sepatutnya mendaftarkan pelayan dan domainnya pada pautannya sendiri, kemudian menariknya semula apabila terputus. Integrasi resolved NetworkManager dan pembantu klien sendiri kedua-duanya berfungsi begitu; skrip yang hanya menulis semula resolv.conf tidak.

Pada pautan yang sudah wujud, tetapan masa jalan menunjukkan mekanismenya. resolvectl dns tun0 10.40.0.53 melampirkan pelayan, dan resolvectl domain tun0 '~corp.example' melampirkan domain penghalaan. Tilde ialah aksara pemikul beban: ia mengehadkan pertanyaan bagi akhiran itu kepada pautan ini dan membiarkan yang lain tenang, manakala nilai yang sama tanpanya menjadi domain carian dan pemisahan itu meruap. Alamat itu contoh makmal, bukan konfigurasi kekal. Sahkan dengan resolvectl query host.corp.example dan baca pautan mana yang menjawab.

Pelayan berdaftar masih memerlukan laluan. Apabila pertanyaan sampai ke pautan yang betul dan tamat masa, kesalahannya terletak pada kebolehcapaian melalui terowong, bukan pada pemilikan penyelesai.

Bagaimana keadaan yang berfungsi kelihatan

Hasil yang sihat adalah konsisten dalam ketiga-tiga paparan: pelayan setiap pautan sepadan dengan apa yang diberikan VPN, domain penghalaan hanya meliputi akhiran dalaman, dan aplikasi yang penting menyelesaikan nama dalaman sementara nama awam masih mengikuti laluan tempatan. Satu pertanyaan yang berjaya membuktikan kurang daripada persetujuan itu.

Kemudian putuskan sambungan dan ulangi kedua-dua pertanyaan. Klien yang membiarkan domainnya berdaftar selepas pembongkaran menghasilkan mesin yang gagal dalam carian dalaman berjam-jam kemudian, tanpa terowong terbuka dan tanpa sebab yang jelas.