Mengapa nama hos dalaman beresolusi dalam dig tetapi gagal dalam curl pada VPN

Komputer riba anda berada pada VPN, dig service.internal.example menjawab dengan alamat 10.x, dan curl masih keluar dengan Could not resolve host. Terowong bukan masalahnya: ia membawa pertanyaan dig tanpa aduan. Yang berbeza ialah siapa yang bertanya. dig menghantar satu pertanyaan kepada satu pelayan yang anda namakan, manakala curl melalui rantaian carian sistem pengendalian, dan rantaian itu mempunyai peraturan sendiri tentang pelayan mana yang ditanya.

Dua carian untuk nama yang sama

dig ialah stub resolver tersendiri. Ia membaca /etc/resolv.conf, memilih pelayan nama, menghantar satu pertanyaan A atau AAAA dan mencetak jawapannya. Ia melangkau nsswitch sepenuhnya dan tidak tahu apa-apa tentang keadaan setiap pautan yang disimpan systemd-resolved atau NetworkManager di luar fail itu, sebab itulah jawapan dig boleh betul tetapi tetap tidak memberitahu apa yang akan dilihat aplikasi anda.

Aplikasi memanggil getaddrinfo, dan getaddrinfo menelusuri rantaian yang lebih panjang: susunan modul nsswitch, kemudian modul yang mengendalikan nama, dan akhirnya resolver yang dibina daripada konfigurasi pautan semasa. Pada mesin systemd pertanyaan pergi ke 127.0.0.53 dan systemd-resolved memilih pelayan huluan setiap pautan berdasarkan domain penghalaan yang dilekatkan pada antara muka tun.

Dua arahan memisahkan lapisan itu tanpa meneka:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent menggunakan laluan yang sama seperti curl, jadi kegagalan getent di sebelah dig yang berfungsi menyetempatkan kerosakan pada dasar carian dan bukan pada penghalaan paket. resolvectl query juga mencetak antara muka dan pelayan huluan yang memberikan jawapan, yang menunjukkan sama ada pautan terowong atau pautan fizikal memenangi keputusan itu.

Baca resolver yang benar-benar digunakan aplikasi

/etc/resolv.conf dijana pada kebanyakan desktop, dan klien VPN mempunyai tiga cara berinteraksi dengannya: menambah pelayan nama di hadapan, menimpa fail, atau menyerahkan pelayannya kepada NetworkManager dan membiarkan daemon menulis semula. Hanya corak ketiga mengekalkan DNS setiap pautan, kerana pelayan kekal terikat pada antara muka dan bukannya diratakan menjadi satu senarai global.

Pada sistem NetworkManager hasilnya bergantung pada backend dalam /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Dengan dns=default pelayan klien digabungkan ke dalam resolv.conf mengikut susunan yang menang, dan carian peribadi masih boleh dihantar ke resolver awam. Dengan backend yang memahami pautan, systemd-resolved atau dnsmasq, pelayan terowong kekal terbatas pada terowong dan hanya nama yang sepadan dengan domain penghalaannya pergi ke sana. Batasan itulah maksud split DNS dalam amalan, dan itulah bahagian yang paling kerap hilang apabila klien mendakwa menyokongnya.

Baca keadaan sebelum mengubah apa-apa:

resolvectl status
resolvectl dns tun0

Anda mahu melihat antara muka tun tersenarai dengan pelayan DNS dan domain penghalaan untuk akhiran peribadi, dipaparkan sebagai ~internal.example. Tiada pelayan pada pautan bermaksud klien tidak menghantar apa-apa. Pelayan tanpa domain bermaksud carian sama ada semuanya pergi ke sana atau tiada satu pun, bergantung pada klien, dan kedua-duanya bukan split DNS.

Tempat nsswitch menamatkan carian terlalu awal

Baris desktop biasa kelihatan seperti ini:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal mengendalikan multicast DNS dan menuntut setiap nama yang berakhir dengan .local. Perkhidmatan Kubernetes seperti api.infra.svc.cluster.local juga berakhir dengan .local. Apabila modul mDNS melaporkan NOTFOUND, tindakan [NOTFOUND=return] menamatkan seluruh carian dan bukannya meneruskan ke modul dns, jadi nama itu tidak pernah dihantar ke resolver VPN. dig melangkau fail itu sepenuhnya, dan sebab itulah kedua-dua alat tidak bersetuju.

Itulah kontras paling tajam dalam masalah ini, dan semuanya bergantung pada satu perkataan dalam fail konfigurasi yang lebih tua daripada VPN anda. Menukar tindakan kepada [NOTFOUND=continue] mengekalkan mDNS untuk pencetak dan peranti tempatan sambil membenarkan DNS melihat nama itu. Menggantikan baris dengan hosts: files dns juga berfungsi dan lebih kasar: ia menggugurkan resolusi .local untuk pencetak yang benar-benar anda gunakan.

Nama yang hidup dalam tepat satu rangkaian

Zon peribadi berwibawa di tepat satu tempat. Nama AWS seperti ip-10-0-4-31.eu-west-1.compute.internal dijawab melalui resolver VPC wilayah itu, dan hanya selagi titik akhir VPN anda berada di wilayah yang sama dengan sumber itu. Sambung ke titik akhir di Frankfurt, tanya nama compute.internal dari Ireland, dan tiada tetapan tempatan akan membantu: zon yang menyimpan rekod itu tidak dapat dicapai dari sana.

Domain carian menghasilkan imej cermin. service kosong dilengkapkan dengan akhiran yang dianggap terpakai oleh resolver, dan dengan pautan VPN domain tempatan boleh mengalahkan domain korporat. Tanya dengan titik di hujung untuk membuang tekaan, getent ahosts service.internal.example., dan jika itu berkesan sedangkan nama pendek gagal, pembetulannya ialah domain carian pada terowong, bukan alamat pelayan.

Klien terurus menambah lapisan ketiga di atas resolver sistem. Profil VPN Windows boleh membawa dasar penyelesaian nama sendiri, peraturan setiap aplikasi dan jadual NRPT yang terpakai walaupun terowong dimatikan. Aplikasi dengan cache DNS sendiri, biasa dalam runtime .NET dan Java, menyimpan kegagalan lapuk lama selepas rantaian dibetulkan. Klien Apple mengkonfigurasi split DNS melalui domain padanan dalam tetapan DNS dan bukan melalui resolv.conf, dan Chromium atau Firefox dalam mod DNS selamat boleh memintas resolver sistem untuk nama awam. Rujukan Microsoft tentang penyelesaian nama VPN menerangkan bahagian Windows bagi lapisan dasar itu.

Putuskan lapisan mana yang perlu dibetulkan

Bekerja dari gejala ke lapisan dan bukannya mencuba pembetulan mengikut urutan:

Dua baris memikul sebahagian besar beban. Tamat masa ialah masalah capaian: resolver peribadi tidak menjawab melalui terowong, jadi periksa laluan ke alamatnya dan sama ada pelayan DNS pada pautan itu yang anda sangkakan. NXDOMAIN ialah masalah kuasa: sesuatu menjawab dan ia tidak mengenal nama itu, yang menunjuk ke zon, wilayah atau resolver yang tidak sepatutnya menerima pertanyaan itu.

Baris terakhir ialah yang orang terlepas kerana kedua-dua separuh kelihatan seperti kejayaan. Nama pendek yang beresolusi berbeza daripada FQDN ialah ketidakpadanan akhiran, dan menyambung semula terowong tidak akan mengubah akhiran yang dihantar klien.

Rakam keadaan sebelum menyunting fail konfigurasi, supaya anda boleh mengatakan sama ada suntingan itu berkesan:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Jalankan pemeriksaan mengikut urutan ini dan berhenti pada kegagalan pertama. getent dan resolvectl query mesti sepadan; jika getent gagal sementara dig menjawab, kekal dalam rantaian carian dan jangan sentuh penghalaan. resolvectl status mesti menunjukkan pelayan DNS dan domain penghalaan pada antara muka tun. nsswitch tidak boleh kembali awal dengan NOTFOUND untuk akhiran yang sedang diuji. Nama mesti berwibawa dalam rangkaian tempat titik akhir anda bersambung, diuji dengan titik di hujung. Aplikasi tidak boleh menyimpan cache sendiri atau penggantian DNS selamat.

Betulkan hanya lapisan pertama yang gagal, kemudian jalankan semula arahan yang sama. Dua perubahan serentak menyebabkan anda tidak dapat mengatakan mana yang penting, dan gangguan seterusnya memulakan siasatan dari sifar.