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

Dua mesin pada VPN yang sama, nama host yang sama, dan hanya satu yang menyelesaikannya: perbedaannya biasanya bukan tunnel melainkan resolver mana yang menjawab. Di desktop Linux nama itu dapat melewati sakelar layanan nama, melalui stub systemd-resolved, atau melalui resolver yang dibawa aplikasi, dan masing-masing menerapkan aturannya sendiri pada akhiran yang sama. Akhiran itulah tempat aturan-aturan menyimpang, karena .local bukan label netral. Cari tahu jalur mana yang sebenarnya diambil program yang gagal sebelum Anda mengubah urutan apa pun dijalankan.

Dua resolver, dua jawaban berbeda

Pencarian glibc tradisional menelusuri baris hosts: di nsswitch.conf dan menanyai setiap modul bergiliran sampai salah satunya menjawab. Klien yang berbicara dengan systemd-resolved melalui pendengar stub justru menanyai satu proses, dan proses itu menerapkan kebijakan per tautan plus kasus khususnya sendiri. Aplikasi yang membawa resolver sendiri, atau menautkan pustaka yang melakukannya, dapat melewati keduanya. Jadi satu nama host dapat memiliki tiga pemilik pada satu mesin, dan hanya satu di antaranya yang tahu apa yang dimaksud VPN.

Identifikasi pemiliknya sebelum mengubah apa pun, karena perbaikannya berbeda untuk masing-masing dari ketiganya. Peramban dan alat baris perintah di desktop yang sama dapat berselisih secara sah, dan perselisihan itu adalah petunjuk, bukan bug. Jika peramban menyelesaikan nama dan alat tidak, Anda sedang men-debug jalur resolver dan bukan rute VPN. Konfirmasikan rute secara terpisah, agar kesalahan perutean tidak disalahartikan sebagai kesalahan layanan nama. Ketika keduanya sepakat, kesalahannya berada di hulu host dan konfigurasi resolver di sini tidak layak diedit lagi.

Perintah mana yang benar-benar menanyai resolver Anda

Dua perintah hanya-baca menjawab pertanyaan yang saling terkait, dan membandingkannya melokalisasi masalah lebih cepat daripada membaca konfigurasi. Gunakan nama internal sungguhan dan jaga keluaran tetap privat, karena catatan internal tetap internal. Jalankan keduanya di 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 dikonfigurasi, itulah yang dialami program biasa. Yang kedua bertanya langsung ke systemd-resolved dan melaporkan tautan, protokol, dan server yang menjawab. Menanyai server korporat berdasarkan alamat hanya membuktikan bahwa server memegang catatan itu, karena tidak mengatakan apa pun tentang apakah aplikasi pernah menanyakannya. Baca tautan yang membawa VPN dan domain yang diklaimnya, lalu bandingkan daftar itu dengan akhiran pada nama yang gagal.

Mengapa .local melewati zona unicast Anda

referensi systemd-resolved menyatakan bahwa nama berlabel banyak yang berakhiran .local biasanya menuju DNS multicast ketika mDNS diaktifkan, bukan DNS unicast biasa. RFC 6762 menyisihkan ruang nama itu untuk multicast tautan-lokal, sehingga zona korporat dapat menyimpan catatan yang benar yang tidak pernah ditanyai untuk akhiran tersebut. Tunnel dapat merutekan resolver dengan sempurna dan tetap kalah dalam perlombaan. Ping yang berhasil dari tembolok tidak mengatakan apa pun tentang pencarian yang baru saja terjadi.

Ada pengecualian yang terdokumentasi, dan itu menyelesaikan sebagian besar kasus ini: ketika sebuah tautan mendeklarasikan akhiran itu sebagai domain pencarian atau domain perutean, daemon menyimpannya di jalur unicast dan melewati kasus khusus multicast. Itu kebijakan per tautan, bukan preferensi global. Dua mesin dengan server VPN yang sama dapat berperilaku berbeda ketika satu profil jaringan mendeklarasikan domain dan yang lain tidak, jadi bacalah profil yang aktif, bukan yang Anda ingat pernah diedit.

Pengecualian sempit mengalahkan penyusunan ulang global

Untuk zona yang sudah ada dan tidak dapat Anda ganti namanya, mintalah pemilik resolver dan VPN mendeklarasikan domain pada koneksi yang membawanya. Entri domain perutean untuk satu akhiran itu plus alamat server yang dimaksud adalah perubahan kecil dengan pemilik bernama, dan ia hidup bersama tautan, bukan di berkas yang diedit tangan.

Itu juga bertahan saat terputus, karena kebijakan tautan diterapkan ulang ketika tautan kembali. Mengedit nsswitch.conf bersama adalah alternatif yang menggoda dan lebih mahal, karena mengubah perilaku pencarian untuk setiap nama di mesin, termasuk penemuan lokal. Menonaktifkan daemon multicast juga tidak setara: itu menghapus perilaku lokal tanpa mengajari resolver mana pun tentang zona korporat. Jika layanan itu baru dan bukan warisan, letakkan di bawah subdomain yang dikendalikan organisasi Anda dan lewati kompetisi sepenuhnya. Pilih pengecualian sempit ketika nama itu terkunci di firmware atau tercetak pada label, dan pilih subdomain baru ketika Anda masih mengendalikan klien.

Apa yang harus dibuktikan setelah perubahan

Buktikan perbaikannya dengan pencarian milik aplikasi itu sendiri, bukan dengan alat yang Anda pasang untuk menguji, dan bersihkan tembolok apa pun yang bisa menjawab atas namanya. Lalu konfirmasikan jalur resolver dan tautan yang menyajikan jawabannya. Terakhir periksa bahwa penemuan lokal masih berperilaku seperti sebelum perubahan, karena printer yang berhenti muncul adalah bagian yang orang sadari paling akhir. Ketiga perintah ini memeriksa nama, jalur, dan identitas TLS dalam urutan 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 benar dengan sertifikat yang salah tetap menggagalkan klien yang ketat, jadi periksa nama yang diharapkan aplikasi setelah resolusi berfungsi. Konfirmasikan bahwa layanan menerima koneksi dari alamat VPN dan bukan hanya dari rentang kantor. Tulis cakupan domain, server, dan pemiliknya ke dalam dokumentasi koneksi. Kalau tidak, orang berikutnya yang menemui kegagalan ini akan meraih pengeditan global yang sama yang baru saja Anda hindari.