Hentikan dua layanan Linux yang berebut /etc/resolv.conf

DNS terus kembali ke keadaan semula, koneksi ulang VPN membatalkan perbaikan Anda, dan akhirnya seseorang di tim mengusulkan mengunci berkas. Urutan itu adalah gejala, bukan solusi: dua komponen sama-sama mengira memiliki /etc/resolv.conf, dan yang menulis terakhir menang. Mengunci berkas tidak menyelesaikan konflik kepemilikan, hanya menyembunyikannya sambil merusak komponen yang sebenarnya Anda inginkan. Kerjakan empat pemeriksaan di bawah ini secara berurutan, dan perbaiki susunannya pada tingkat yang memilikinya, bukan pada berkasnya.

Pemeriksaan 1: apakah itu symlink, dan ke mana

Mulailah dari berkas itu sendiri, karena jalur yang Anda sunting mungkin bukan berkasnya sama sekali. Symlink ke direktori runtime resolver berperilaku sangat berbeda dari berkas biasa yang ditulis ulang oleh skrip klien:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Tautan ke jalur stub systemd-resolved berarti isi berkas dihasilkan, dan penyuntingan manual akan ditimpa pada peristiwa berikutnya. Berkas biasa dengan baris nameserver biasanya ditulis oleh klien atau hook DHCP yang berjalan saat terhubung. Keduanya sah; yang penting adalah mengetahui mana yang Anda miliki sebelum mengubah apa pun.

Pemeriksaan 2: daemon mana yang berjalan

Cari tahu apa yang benar-benar aktif, bukan apa yang terpasang. Beberapa resolver dapat hadir pada distribusi modern, dan yang memegang port 53 pada antarmuka loopback adalah yang menjawab:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Keluaran status menyebutkan server DNS per tautan dan domain perutean, yang merupakan peta yang Anda butuhkan untuk split DNS. Jika nama internal harus pergi ke server internal dan sisanya ke server publik, kebijakan itu hidup di domain per tautan, dan meratakannya menjadi daftar nameserver statis di berkas diam-diam menghilangkan perbedaan itu.

Konfigurasi NetworkManager sendiri menentukan backend mana yang digunakannya. Pengaturan dns=-nya di berkas konfigurasi utama memilih antara resolver internalnya, dnsmasq, systemd-resolved, dan none, dan distribusi mungkin sudah memilih untuk Anda. Baca pengaturan itu sebelum memutuskan apa arti “memperbaiki DNS” pada host ini.

Pemeriksaan 3: apa yang boleh ditulis klien VPN

Di sinilah konflik biasanya tinggal. Klien VPN yang menulis ulang berkas resolver secara langsung akan bertarung dengan layanan apa pun yang juga memeliharanya, dan yang kalah adalah yang berjalan lebih dulu. Rilis OpenVPN terbaru dapat menyerahkan pengaturan DNS ke systemd-resolved alih-alih menulis ulang berkas, yang merupakan perilaku kooperatif yang Anda inginkan; skrip lama dan hook tulisan tangan sering memanggil pembantu lama atau sekadar menimpa berkas.

Situasi WireGuard serupa bentuknya: konfigurasi antarmuka itu sendiri tidak mengelola DNS, alat di sekitarnya yang melakukannya, melalui pembantu resolver atau integrasi resolved. Jika dua pembantu semacam itu terpasang, keduanya akan mencoba menerapkan pandangan dunianya saat terhubung.

Bacalah hook naik dan turun klien alih-alih menebak. Beberapa baris shell di /etc/openvpn/up.sh atau direktori setara menjelaskan perilaku yang tampaknya acak, dan di situlah Anda dapat membuat klien bekerja sama alih-alih bersaing.

Pemeriksaan 4: perbaiki pada pemiliknya, bukan pada berkas

Setelah Anda tahu pemiliknya, konfigurasikan DNS melalui antarmuka yang didukung pemilik itu. Untuk systemd-resolved itu berarti pengaturan per tautan dan domain perutean alih-alih berkas statis; untuk NetworkManager berarti pengaturan DNS profil koneksi dan backend yang dipilih; untuk distribusi yang memakai integrasi resolvconf berarti menulis melalui pembantu itu.

Jangan jadikan berkas itu immutable. Atribut immutable menghentikan pembaruan DHCP yang sah dan pembaruan VPN bersama dengan yang Anda lawan, dan meninggalkan sistem dalam keadaan di mana peningkatan paket atau koneksi ulang berikutnya menghasilkan kegagalan yang tidak dapat dijelaskan siapa pun dari konfigurasi. Itu menyembunyikan konflik kepemilikan, yang justru merupakan hal yang Anda coba selesaikan.

Ketika dua komponen benar-benar harus hidup berdampingan, beri mereka tugas yang berbeda. Biarkan pengelola jaringan memiliki konfigurasi tingkat antarmuka, biarkan klien VPN menyumbang DNS dan domain per tautan melalui integrasi yang sama, dan hapus skrip ketiga yang menulis berkas secara langsung. Dokumentasi systemd-resolved memaparkan mode yang didukungnya dan apa yang ditampilkan masing-masing di /etc/resolv.conf. Pilih mode yang sesuai dengan banyaknya kebijakan yang perlu Anda pertahankan. Jika split DNS penting, susunan stub dengan domain per tautan mempertahankannya, sedangkan mode yang menyalin server upstream ke dalam berkas diam-diam meratakannya.

Verifikasi setelah koneksi ulang, bukan setelah penyuntingan

Berkas yang tampak benar tepat setelah perubahan Anda tidak membuktikan apa pun, karena peristiwa berikutnya belum terjadi. Picu urutan yang dulu merusaknya: turunkan dan naikkan terowongan, perbarui sewa DHCP atau alihkan antarmuka, lalu baca nilai yang sama sekali lagi.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Kemudian pastikan perbedaan yang penting: nama internal diselesaikan melalui server internal sementara nama publik masih berfungsi. Konfigurasi yang mengirim semuanya ke server internal tampak baik-baik saja sampai seseorang mencoba mencapai internet melalui terowongan, dan konfigurasi yang mengirim semuanya ke server publik membocorkan nama internal.

Catat pemilik, backend, dan mode symlink di catatan penerapan. Satu paragraf itu mengubah peningkatan paket di masa depan dari insiden menjadi butir tinjauan, dan mencegah orang berikutnya menemukan kembali konflik yang sama dengan perintah chattr.