DNS VPN berfungsi, tetapi nama .local masih gagal: siapa yang menyelesaikannya?

Dua mesin pada VPN yang sama, nama hos yang sama, dan hanya satu daripadanya menyelesaikannya: perbezaannya biasanya bukan terowong tetapi penyelesai mana yang menjawab. Pada desktop Linux nama itu boleh melalui suis perkhidmatan nama, melalui stub systemd-resolved atau melalui penyelesai yang dibawa oleh aplikasi, dan setiap satunya menggunakan peraturannya sendiri pada akhiran yang sama. Akhiran itulah tempat peraturan mencapah, kerana .local bukan label neutral. Ketahui laluan mana yang sebenarnya diambil oleh program yang gagal sebelum anda menukar susunan sesuatu dijalankan.

Dua penyelesai, dua jawapan berbeza

Carian glibc tradisional menelusuri baris hosts: dalam nsswitch.conf dan bertanya kepada setiap modul secara bergilir sehingga salah satu menjawab. Klien yang bercakap dengan systemd-resolved melalui pendengar stub pula bertanya kepada satu proses, dan proses itu menggunakan dasar setiap pautan serta kes khasnya sendiri. Aplikasi yang membawa penyelesai sendiri, atau memaut pustaka yang berbuat demikian, boleh memintas kedua-duanya. Jadi satu nama hos boleh mempunyai tiga pemilik pada satu mesin, dan hanya satu daripadanya tahu apa yang dimaksudkan oleh VPN.

Kenal pasti pemilik sebelum menukar apa-apa, kerana pembaikannya berbeza bagi setiap tiga. Pelayar dan alat baris arahan pada desktop yang sama boleh berselisih secara sah, dan perselisihan itu ialah petunjuk, bukan pepijat. Jika pelayar menyelesaikan nama itu dan alat tidak, anda sedang menyahpepijat laluan penyelesai dan bukan laluan VPN. Sahkan laluan itu secara berasingan, supaya kerosakan penghalaan tidak disalah anggap sebagai kerosakan perkhidmatan nama. Apabila kedua-duanya bersetuju, kerosakan berada di hulu hos dan konfigurasi penyelesai di sini tidak berbaloi untuk diedit lagi.

Arahan mana yang benar-benar bertanya kepada penyelesai anda

Dua arahan baca sahaja menjawab soalan berkaitan, dan membandingkannya menyetempatkan masalah lebih cepat daripada membaca konfigurasi. Gunakan nama dalaman sebenar dan pastikan output kekal peribadi, kerana rekod dalaman tetap dalaman. Jalankan kedua-duanya dalam sesi yang sama dengan tempat program yang gagal berjalan:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Yang pertama bertanya melalui modul yang dikonfigurasikan, itulah yang dialami oleh program biasa. Yang kedua bertanya terus kepada systemd-resolved dan melaporkan pautan, protokol dan pelayan yang menjawab. Bertanya kepada pelayan korporat melalui alamat hanya membuktikan bahawa pelayan itu menyimpan rekod, kerana ia tidak menyatakan sama ada aplikasi pernah bertanya. Baca pautan yang membawa VPN dan domain yang didakwanya, kemudian bandingkan senarai itu dengan akhiran dalam nama yang gagal.

Mengapa .local memintas zon unicast anda

rujukan systemd-resolved menyatakan bahawa nama berbilang label yang berakhir dengan .local biasanya pergi ke DNS multicast apabila mDNS didayakan, bukannya DNS unicast biasa. RFC 6762 mengasingkan ruang nama itu untuk multicast pautan-tempatan, jadi zon korporat boleh menyimpan rekod yang betul yang tidak pernah ditanya untuk akhiran itu. Terowong boleh menghalakan penyelesai dengan sempurna dan tetap kalah dalam perlumbaan. Ping yang berjaya dari cache tidak menyatakan apa-apa tentang carian yang baru berlaku.

Ada pengecualian yang didokumenkan, dan ia menyelesaikan kebanyakan kes ini: apabila pautan mengisytiharkan akhiran itu sebagai domain carian atau domain penghalaan, daemon menyimpannya pada laluan unicast dan melangkau kes khas multicast. Itu dasar setiap pautan dan bukan keutamaan global. Dua mesin dengan pelayan VPN yang sama boleh berkelakuan berbeza apabila satu profil rangkaian mengisytiharkan domain itu dan yang lain tidak, jadi baca profil yang aktif dan bukan yang anda ingat pernah diedit.

Pengecualian sempit mengalahkan penyusunan semula global

Untuk zon sedia ada yang tidak boleh anda namakan semula, minta pemilik penyelesai dan VPN mengisytiharkan domain itu pada sambungan yang membawanya. Entri domain penghalaan untuk satu akhiran itu serta alamat pelayan yang dimaksudkan ialah perubahan kecil dengan pemilik bernama, dan ia hidup bersama pautan dan bukan dalam fail yang diedit dengan tangan.

Ia juga bertahan selepas terputus, kerana dasar pautan digunakan semula apabila pautan kembali. Mengedit nsswitch.conf yang dikongsi ialah alternatif yang menggoda dan lebih mahal, kerana ia mengubah tingkah laku carian untuk setiap nama pada mesin itu, termasuk penemuan tempatan. Melumpuhkan daemon multicast juga tidak setara: ia membuang tingkah laku tempatan tanpa mengajar mana-mana penyelesai tentang zon korporat. Jika perkhidmatan itu baharu dan bukan warisan, letakkan di bawah subdomain yang dikawal oleh organisasi anda dan langkau persaingan sepenuhnya. Pilih pengecualian sempit apabila nama itu terpaku dalam firmware atau tercetak pada label, dan pilih subdomain baharu apabila anda masih mengawal klien.

Apa yang perlu dibuktikan selepas perubahan

Buktikan pembaikan itu dengan carian aplikasi itu sendiri dan bukan dengan alat yang anda pasang untuk menguji, dan kosongkan mana-mana cache yang boleh menjawab bagi pihaknya. Kemudian sahkan laluan penyelesai dan pautan yang menyampaikan jawapan. Akhir sekali semak bahawa penemuan tempatan masih berkelakuan seperti sebelum perubahan, kerana pencetak yang berhenti muncul ialah bahagian yang orang perhatikan paling akhir. Ketiga-tiga arahan ini menyemak nama, laluan dan identiti TLS dalam susunan itu:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Alamat yang betul dengan sijil yang salah masih menggagalkan klien yang ketat, jadi semak nama yang dijangka oleh aplikasi apabila penyelesaian berfungsi. Sahkan bahawa perkhidmatan menerima sambungan dari alamat VPN dan bukan hanya dari julat pejabat. Tulis skop domain, pelayan dan pemilik ke dalam dokumentasi sambungan. Jika tidak, orang seterusnya yang menemui kegagalan ini akan mencapai suntingan global yang sama yang baru anda elakkan.