Mengapa entri /etc/hosts Anda tidak sampai ke DNS VPN

Anda menambahkan nama ke /etc/hosts, menyambung VPN, dan berharap catatan itu muncul bagi semua orang. Itu tidak terjadi, dan kejutannya biasanya datang dengan gejala kedua: nama itu terurai di mesin Anda dan gagal di mesin rekan kerja, yang terlihat seperti layanan DNS VPN yang rusak dan sebenarnya file hosts melakukan tepat apa yang dirancang untuk dilakukannya. File hosts adalah konfigurasi resolusi nama lokal, bukan pembaruan zona, dan tidak ada apa pun dalam koneksi VPN normal yang mengunggahnya.

Hosts adalah penimpaan lokal, bukan pembaruan zona

File itu adalah daftar pemetaan yang dikonsultasikan pustaka layanan nama sebelum, atau alih-alih, bertanya ke server DNS. Baris seperti 10.40.0.20 build.corp.example mengubah apa yang disimpulkan aplikasi di satu mesin itu. File itu tidak membuat catatan, tidak melintasi terowongan, dan server DNS yang dituju terowongan tidak tahu file itu ada.

Itulah sebabnya kegagalannya asimetris. Klien Anda mendapat jawaban dari file. Klien lain bertanya ke server DNS VPN, yang tidak mengembalikan apa pun, dan aplikasi melaporkan bahwa nama itu tidak ada. Kedua mesin berperilaku benar; hanya satu yang punya penimpaan yang tidak pernah dilihat yang lain.

Dua perintah, dua komponen berbeda

Cara tercepat untuk menghentikan perdebatan adalah membuat perbedaannya terlihat dalam dua perintah, keduanya dijalankan di klien yang punya entri hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Yang pertama bertanya ke jalur pencarian sistem itu sendiri, yang pada sistem glibc tipikal membaca file lokal sebelum DNS. Yang kedua mengirim kueri DNS langsung ke server di alamat itu dan sama sekali tidak mengonsultasikan file lokal. Ketika yang pertama mengembalikan entri Anda dan yang kedua mengembalikan NXDOMAIN, Anda telah membuktikan bahwa catatan itu tidak ada di DNS dan bahwa mesin Anda menjawab dari penimpaan lokal.

Urutannya dapat dikonfigurasi, dan itu layak diperiksa sebelum Anda menyimpulkan apa pun tentang distribusi tertentu. Lihat baris hosts: di /etc/nsswitch.conf; hosts: files dns mengonsultasikan file lebih dulu. Jangan menyalin contoh itu ke konfigurasi yang berfungsi hanya untuk mengubah urutan, karena sistem nyata sering mencantumkan sumber tambahan dan entri layanan bersyarat yang tidak dimuat contoh itu.

systemd-resolved mengaburkan pengujian

Pada sistem yang memakai systemd-resolved, stub lokal juga menyajikan nama dari basis data hosts. Karena itu, kueri ke 127.0.0.53 bukan pengujian independen terhadap server jarak jauh, meskipun terlihat seperti kueri DNS dan berperilaku seperti itu. Anda dapat memastikan apa yang diketahui resolver dan server mana yang akan ditanyakannya dengan:

resolvectl query build.corp.example
resolvectl status

Keluaran status menyebut server DNS per tautan, dan begitulah cara Anda mengetahui apakah tautan VPN benar-benar menerima resolver. Pertanyaan itu terpisah dari entri hosts dan itulah yang layak diajukan ketika nama privat gagal bagi setiap pengguna dan bukan bagi satu orang.

Aplikasi dapat menambahkan lapisan lain lagi. Peramban dengan pengaturan DNS-over-HTTPS sendiri, kontainer dengan konfigurasi resolver sendiri, atau runtime yang menyimpan pencarian di cache selama masa hidup proses dapat masing-masing menjawab berbeda dari sistem. Uji aplikasi yang Anda pedulikan alih-alih menganggap satu perintah menggambarkan setiap program di mesin itu.

Apa yang sebenarnya berbagi nama di seluruh VPN

Jika nama privat harus berfungsi bagi semua orang, ia memerlukan pemilik yang dapat dijangkau resolver semua orang. Jawaban bersihnya adalah menerbitkan catatan itu di zona terkelola dan membuat zona itu dapat diurai melalui jalur DNS VPN yang dimaksud. Catatan itu lalu punya satu sumber kebenaran, jejak audit, dan siklus hidup, dan tidak ada yang harus mengingat laptop mana yang membawa penimpaan lokal.

Mendistribusikan file hosts adalah alternatif yang sah, dan itu manajemen titik akhir, bukan layanan nama. Jika Anda memilihnya, file itu harus diterapkan, diberi versi, dan dihapus oleh apa pun yang mengelola armada, dan hal itu harus dijelaskan demikian dalam desain. “VPN yang mengurusnya” bukan deskripsi proses itu.

Registrasi DNS dinamis adalah mekanisme ketiga, dengan izinnya sendiri, autentikasi pembaruan, dan masa hidup catatan. Itu tidak berasal dari entri hosts, dan juga tidak berasal dari klien yang sekadar menyambung, kecuali server dan klien keduanya dikonfigurasi untuk melakukannya. Catatan yang muncul sendiri adalah tanda bahwa seseorang mengaktifkan pembaruan aman dan klien yang mendaftarkan dirinya sendiri, dan konfigurasi itu termasuk dalam catatan desain, bukan dalam utas pemecahan masalah. Jika tidak ada yang bisa menyebutkan siapa pemilik pengaturan itu, perlakukan catatan otomatis sebagai belum terverifikasi dan pertahankan zona terkelola sebagai sumber kebenaran.

Nama yang terurai bukan rute

Resolusi nama dan keterjangkauan adalah hal terpisah, dan pemetaan lokal yang basi adalah cara klasik untuk mencampuradukkannya. Entri hosts yang menunjuk ke alamat yang sudah pindah akan terus memilih host usang jauh setelah DNS dikoreksi, dan gejalanya tampak seperti kegagalan perutean pada nama yang terurai dengan baik.

Jadi ketika laporannya adalah “nama terurai tetapi layanan tidak dapat dijangkau”, bandingkan pencarian sistem dengan kueri eksplisit ke server DNS VPN, lalu periksa alamat yang Anda dapatkan terhadap alamat yang benar-benar dipakai layanan. Referensi systemd-resolved mendokumentasikan sumber lokal yang dikonsultasikannya, dan itulah peta yang Anda butuhkan untuk perbandingan itu.

Lalu perbaiki penimpaan itu melalui pemiliknya. Menghapus satu baris dari file hosts Anda sendiri tidak melakukan apa pun bagi dua belas laptop yang menerima baris yang sama dari skrip penerapan, dan itulah versi masalah ini yang sebenarnya dialami orang.