Hentikan dua perkhidmatan Linux yang bersaing untuk /etc/resolv.conf

DNS terus kembali ke keadaan asal, sambungan semula VPN membatalkan pembaikan anda, dan akhirnya seseorang dalam pasukan mencadangkan fail dikunci. Urutan itu adalah gejala, bukan penyelesaian: dua komponen kedua-duanya percaya mereka memiliki /etc/resolv.conf, dan yang menulis terakhir menang. Mengunci fail tidak menyelesaikan konflik pemilikan, ia hanya menyembunyikannya sambil merosakkan komponen yang anda benar-benar mahu. Lakukan empat pemeriksaan di bawah mengikut urutan, dan betulkan susunan pada tahap yang memilikinya, bukan pada fail.

Pemeriksaan 1: adakah ia symlink, dan ke mana

Mulakan dengan fail itu sendiri, kerana laluan yang anda edit mungkin bukan fail itu langsung. Symlink ke direktori runtime resolver berkelakuan sama sekali berbeza daripada fail biasa yang ditulis semula oleh skrip klien:

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

Pautan ke laluan stub systemd-resolved bermaksud kandungan fail dijana, dan suntingan manual akan ditimpa pada peristiwa seterusnya. Fail biasa dengan baris nameserver biasanya ditulis oleh klien atau cangkuk DHCP yang berjalan semasa menyambung. Kedua-duanya sah; yang penting ialah mengetahui yang mana anda ada sebelum mengubah apa-apa.

Pemeriksaan 2: daemon mana yang berjalan

Ketahui apa yang benar-benar aktif, bukan apa yang dipasang. Beberapa resolver boleh hadir pada pengedaran moden, dan yang memegang port 53 pada antara muka loopback ialah yang menjawab:

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

Output status menamakan pelayan DNS setiap pautan dan domain penghalaan, iaitu peta yang anda perlukan untuk split DNS. Jika nama dalaman mesti pergi ke pelayan dalaman dan semua yang lain ke pelayan awam, dasar itu hidup dalam domain setiap pautan, dan meratakannya menjadi senarai nameserver statik dalam fail secara senyap menghilangkan perbezaan itu.

Konfigurasi NetworkManager sendiri menentukan backend mana yang digunakannya. Tetapan dns=-nya dalam fail konfigurasi utama memilih antara resolver dalamannya, dnsmasq, systemd-resolved dan none, dan pengedaran mungkin telah memilih untuk anda. Baca tetapan itu sebelum memutuskan apa maksud “membaiki DNS” pada hos ini.

Pemeriksaan 3: apa yang dibenarkan ditulis oleh klien VPN

Di sinilah konflik biasanya tinggal. Klien VPN yang menulis semula fail resolver secara langsung akan bergaduh dengan mana-mana perkhidmatan yang juga menyelenggarakannya, dan yang kalah ialah yang berjalan dahulu. Keluaran OpenVPN terkini boleh menyerahkan tetapan DNS kepada systemd-resolved dan bukannya menulis semula fail, iaitu tingkah laku kerjasama yang anda mahukan; skrip lama dan cangkuk tulisan tangan sering memanggil pembantu lama atau hanya menimpa fail.

Keadaan WireGuard serupa dari segi bentuk: konfigurasi antara muka itu sendiri tidak menguruskan DNS, alat di sekelilingnya yang menguruskan, melalui pembantu resolver atau integrasi resolved. Jika dua pembantu sedemikian dipasang, kedua-duanya akan cuba menerapkan pandangan dunia masing-masing semasa menyambung.

Baca cangkuk naik dan turun klien dan bukannya meneka. Beberapa baris shell dalam /etc/openvpn/up.sh atau direktori setara menerangkan tingkah laku yang jika tidak kelihatan rawak, dan di situlah anda boleh membuat klien bekerjasama dan bukannya bersaing.

Pemeriksaan 4: betulkan pada pemiliknya, bukan pada fail

Setelah anda tahu pemiliknya, konfigurasikan DNS melalui antara muka yang disokong oleh pemilik itu. Untuk systemd-resolved ia bermaksud tetapan setiap pautan dan domain penghalaan dan bukannya fail statik; untuk NetworkManager ia bermaksud tetapan DNS profil sambungan dan backend yang dipilih; untuk pengedaran yang menggunakan integrasi resolvconf ia bermaksud menulis melalui pembantu itu.

Jangan jadikan fail itu tidak boleh ubah. Atribut tidak boleh ubah menghentikan pembaharuan DHCP yang sah dan kemas kini VPN bersama-sama dengan yang anda lawan, dan ia meninggalkan sistem dalam keadaan di mana peningkatan pakej atau sambungan semula seterusnya menghasilkan kegagalan yang tiada siapa dapat jelaskan daripada konfigurasi. Ia menyembunyikan konflik pemilikan, iaitu perkara yang anda cuba selesaikan.

Di mana dua komponen benar-benar mesti wujud bersama, berikan mereka tugas yang berbeza. Biarkan pengurus rangkaian memiliki konfigurasi peringkat antara muka, biarkan klien VPN menyumbang DNS dan domain setiap pautan melalui integrasi yang sama, dan buang skrip ketiga yang menulis fail secara langsung. Dokumentasi systemd-resolved menyenaraikan mod yang disokongnya dan apa yang didedahkan setiap satu dalam /etc/resolv.conf. Pilih mod yang sepadan dengan berapa banyak dasar yang perlu anda kekalkan. Jika split DNS penting, susunan stub dengan domain setiap pautan memeliharanya, manakala mod yang menyalin pelayan upstream ke dalam fail secara senyap meratakannya.

Sahkan selepas sambungan semula, bukan selepas suntingan

Fail yang kelihatan betul sejurus selepas perubahan anda tidak membuktikan apa-apa, kerana peristiwa seterusnya belum berlaku. Picu urutan yang dahulunya merosakkannya: turunkan dan naikkan terowong, perbaharui pajakan DHCP atau tukar antara muka, kemudian baca semula nilai yang sama.

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

Kemudian sahkan perbezaan yang penting: nama dalaman diselesaikan melalui pelayan dalaman sementara nama awam masih berfungsi. Konfigurasi yang menghantar semuanya ke pelayan dalaman kelihatan baik sehingga seseorang cuba mencapai internet melalui terowong, dan konfigurasi yang menghantar semuanya ke yang awam membocorkan nama dalaman.

Catatkan pemilik, backend dan mod symlink dalam nota penggunaan. Satu perenggan itu menjadikan peningkatan pakej masa depan daripada insiden menjadi item semakan, dan ia menghalang orang seterusnya daripada menemui semula konflik yang sama dengan arahan chattr.