Linux'ta /etc/resolv.conf için yarışan iki hizmeti durdurun

DNS sürekli eski durumuna dönüyor, VPN yeniden bağlanması düzeltmenizi geri alıyor ve sonunda ekipten biri dosyayı kilitlemeyi öneriyor. Bu sıra bir belirtidir, çözüm değil: iki bileşen de /etc/resolv.conf dosyasına sahip olduğunu sanıyor ve en son yazan kazanıyor. Dosyayı kilitlemek sahiplik çakışmasını çözmez, yalnızca gizler ve bu sırada gerçekte istediğiniz bileşeni bozar. Aşağıdaki dört denetimi sırayla yapın ve düzeni dosyada değil, ona sahip olan katmanda düzeltin.

Denetim 1: sembolik bağlantı mı, ve nereye

Dosyanın kendisinden başlayın, çünkü düzenlediğiniz yol dosyanın kendisi olmayabilir. Bir çözümleyicinin çalışma dizinine giden sembolik bağlantı, istemci betiğinin yeniden yazdığı sıradan bir dosyadan tamamen farklı davranır:

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

systemd-resolved'ın stub yoluna bir bağlantı, dosyanın içeriğinin üretildiği ve elle düzenlemenin bir sonraki olayda üzerine yazılacağı anlamına gelir. nameserver satırları içeren sıradan bir dosyayı genellikle bağlantı sırasında çalışan istemci veya DHCP kancası yazar. İkisi de meşrudur; önemli olan, herhangi bir şeyi değiştirmeden önce hangisine sahip olduğunuzu bilmektir.

Denetim 2: hangi daemon çalışıyor

Ne kurulu olduğunu değil, neyin gerçekten etkin olduğunu öğrenin. Modern bir dağıtımda birkaç çözümleyici bulunabilir ve loopback arayüzünde 53 numaralı bağlantı noktasını tutan yanıt verir:

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

Durum çıktısı, bağlantı başına DNS sunucularını ve yönlendirme alan adlarını adlandırır; bölünmüş DNS için ihtiyacınız olan harita budur. İç adların iç sunucuya, geri kalan her şeyin genel bir sunucuya gitmesi gerekiyorsa bu politika bağlantı başına alan adlarında yaşar ve bunu dosyadaki statik bir nameserver listesine düzleştirmek bu ayrımı sessizce kaybeder.

NetworkManager'ın kendi yapılandırması bu arka uçlardan hangisini kullandığına karar verir. Ana yapılandırma dosyasındaki dns= ayarı, kendi iç çözümleyicisi, dnsmasq, systemd-resolved ve none arasında seçim yapar ve dağıtım sizin yerinize seçmiş olabilir. Bu ana bilgisayarda “DNS'i düzeltmenin” ne anlama geldiğine karar vermeden önce o ayarı okuyun.

Denetim 3: VPN istemcisinin neleri yazmasına izin var

Çakışma genellikle burada yaşar. Çözümleyici dosyasını doğrudan yeniden yazan bir VPN istemcisi, onu da yöneten her hizmetle kavga eder ve kaybeden ilk çalışandır. Yeni OpenVPN sürümleri dosyayı yeniden yazmak yerine DNS ayarlarını systemd-resolved'a devredebilir; bu, istediğiniz işbirlikçi davranıştır; eski betikler ve elle yazılmış kancalar genellikle eski bir yardımcı programı çağırır veya dosyanın üzerine yazar.

WireGuard'ın durumu biçim olarak benzerdir: arayüz yapılandırmasının kendisi DNS'i yönetmez, çevresindeki araçlar yönetir; bir çözümleyici yardımcısı veya resolved entegrasyonu aracılığıyla. Böyle iki yardımcı kuruluysa, ikisi de bağlantı sırasında kendi dünya görüşünü uygulamaya çalışır.

Tahmin etmek yerine istemcinin up ve down kancalarını okuyun. /etc/openvpn/up.sh veya eşdeğer bir dizindeki birkaç satır shell, aksi hâlde rastgele görünen davranışı açıklar ve istemciyi yarışmak yerine işbirliği yapmaya zorlayacağınız yer de orasıdır.

Denetim 4: sahibinde düzeltin, dosyada değil

Sahibini öğrendikten sonra DNS'i o sahibin desteklediği arayüz üzerinden yapılandırın. systemd-resolved için bu, statik dosya yerine bağlantı başına ayarlar ve yönlendirme alan adları demektir; NetworkManager için bağlantı profilinin DNS ayarları ve seçilen arka uç; resolvconf entegrasyonu kullanan bir dağıtım için o yardımcı aracılığıyla yazmak.

Dosyayı değiştirilemez yapmayın. Değiştirilemezlik özniteliği, meşru DHCP yenilemelerini ve VPN güncellemelerini, savaştıklarınızla birlikte durdurur ve sistemi, bir sonraki paket yükseltmesinin veya yeniden bağlanmanın yapılandırmadan kimsenin açıklayamayacağı bir arıza ürettiği durumda bırakır. Sahiplik çakışmasını gizler; bu da tam olarak çözmeye çalıştığınız şeydir.

İki bileşenin gerçekten bir arada bulunması gerektiğinde onlara farklı işler verin. Ağ yöneticisinin arayüz düzeyindeki yapılandırmaya sahip olmasına izin verin, VPN istemcisinin aynı entegrasyon üzerinden bağlantı başına DNS ve alan adları katkısında bulunmasına izin verin ve dosyayı doğrudan yazan üçüncü betiği kaldırın. systemd-resolved belgeleri, desteklediği kipleri ve her birinin /etc/resolv.conf içinde neyi açığa çıkardığını anlatır. Korumak zorunda olduğunuz politika miktarına uyan kipi seçin. Bölünmüş DNS önemliyse, bağlantı başına alan adlarıyla stub düzeni onu korur; üst akış sunucularını dosyaya kopyalayan kip ise onu sessizce düzleştirir.

Yeniden bağlandıktan sonra doğrulayın, düzenlemeden sonra değil

Değişikliğinizden hemen sonra doğru görünen bir dosya hiçbir şeyi kanıtlamaz, çünkü bir sonraki olay henüz gerçekleşmemiştir. Onu eskiden bozan sırayı tetikleyin: tüneli indirip kaldırın, DHCP kiralamasını yenileyin veya arayüzü değiştirin, sonra aynı değerleri yeniden okuyun.

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

Sonra önemli olan ayrımı doğrulayın: iç ad iç sunucu üzerinden çözülürken genel ad hâlâ çalışır. Her şeyi iç sunucuya gönderen yapılandırma, biri tünelden internete çıkmayı deneyene kadar iyi görünür; her şeyi genele gönderen yapılandırma ise iç adları sızdırır.

Sahibi, arka ucu ve sembolik bağlantı kipini dağıtım notlarına yazın. O tek paragraf, gelecekteki bir paket yükseltmesini olaydan inceleme maddesine dönüştürür ve bir sonraki kişinin chattr komutuyla aynı çakışmayı yeniden keşfetmesini engeller.