resolv.conf dosyasını düzenlemek VPN kesildikten sonra DNS’i düzeltmez

VPN’i kesiyorsunuz, ping 1.1.1.1 hâlâ yanıtlıyor ve sayfa sonunda pes edene kadar her ad sorgusu asılı kalıyor. Sonra cat /etc/resolv.conf yalnızca tünelin içinde var olmuş bir ad sunucusunu gösteriyor, genellikle listenin başında. O satırı silmek yaklaşık on dakika düzeltmiş gibi görünüyor, ta ki bir askıya alma, bir Wi-Fi dolaşımı ya da yeniden başlatma onu geri koyana kadar. Düzenlediğiniz dosya ayar değil; başka bir bileşenin sahip olduğu bağlantı durumunun bir görüntüsü.

Tek bir eski kayıt neden her sorguya saniyeler kaybettiriyor

glibc çözümleyicisi ad sunucuları listesini sırayla dolaşır ve bir sonrakini denemeden önce zaman aşımının dolmasını bekler, ve resolv.conf(5) bu listeyi üç kayıtla sınırlar. Tünel gittikten sonra 10.8.0.1 gibi tünel tarafı bir çözümleyiciyi listenin başına koyun, her sorgu yanıt veren bir sunucuya düşmeden önce zaman aşımını öder. Belirtinin DNS hatası değil de ölü bağlantı gibi görünmesinin nedeni budur: tarayıcılar bloke olur, zaman aşımına uğrar ve bazen sonradan eskiyen önbelleğe alınmış bir adres sunar.

Bu aynı zamanda şikâyetin neden «internet bozuldu» olarak geldiğini açıklar. Bir IP adresine ping, bağlantının iyi olduğunu kanıtlar ve bu da arızayı uygulamanın sorunu gibi gösterir. Çözümleyici listesi okunacak ilk ve düzenlenecek son şeydir.

Efsane: resolv.conf bir ayar dosyasıdır

Değiştirmeden önce o yolun gerçekte ne olduğunu sorun:

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

systemd-resolved bulunan bir ana bilgisayarda bu, 127.0.0.53’ü gösteren stub dosyasına bir sembolik bağlantıdır ve gerçek sunucular resolvectl’in yazdırdığı bağlantı başına durumda yaşar. NetworkManager bulunan bir ana bilgisayarda, NetworkManager’ın etkin bağlantıdan yazdığı bir dosya olabilir. Bazı üretici istemcilerinde bağlanırken yerinde yeniden yazılan ve şansınız yoksa kesilirken hiç geri yüklenmeyen düz bir dosyadır. Bunlar üç farklı sahiptir ve ilk ikisini elle düzenlemek ya hiçbir şey yapmaz ya da bir sonraki ağ olayına kadar dayanır.

resolvectl status doğruyu söyleyen görünümdür: bağlantı başına DNS sunucuları, yönlendirme alan adları ve tünel bağlantısının hâlâ var olup olmadığı. resolvectl query example.com daha ileri gider ve hangi arayüzün yanıt verdiğini gösterir. Bir dosyaya dokunmadan önce ikisini de kullanın ve kendi güvenli DNS’ine sahip bir tarayıcının bütün bunları yok saydığını unutmayın.

Herhangi bir şeyi düzenlemeden önce sahibini bulun

Genellikle üç bileşen aynı ayar için yarışır: systemd-resolved, NetworkManager ve VPN istemcisinin kurduğu şey. Önce yaşayanı belirleyin:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

resolved etkinse ve sembolik bağlantı onun stub’ına işaret ediyorsa, genel dosya üretilmiş çıktıdır ve düzenlemeniz kozmetiktir. Bağlantıya NetworkManager sahipse, sunucular bağlantı profiline aittir, bu yüzden düzeltme dosya düzenlemesi değil nmcli özellik değişikliğidir. Bir üretici arka plan programı çalışıyorsa, bir sonraki bağlantıyı yalnızca kendi geri yükleme yolu atlatır.

İstemcinin bıraktığı bağlantı durumunu temizleyin

Öldürülen bir istemci temizleme kancasını çalıştıramaz. SIGKILL hiç yakalanamaz, SIGINT ve SIGTERM ise yakalanabilir, bu yüzden zorla öldürmeden sonra «sadece duran» bir tünel çoğu zaman hem arayüz kaydını hem de çözümleyici kaydını yerinde bırakır. Belirli PID’i bulun ve sinyali yalnızca ona gönderin:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Tam eşleşme listesini okumadan pkill -f vpn veya killall vpn’e uzanmayın. -f tüm komut satırıyla eşleşir, bu yüzden bir sarmalayıcı betiği, bir düzenleyici oturumunu ya da yolunda o dize bulunan ilgisiz bir süreci bitirebilir. Yanlış süreci işin ortasında bitirmek, bir çözümleyici sorununun kayıp dosyaya dönüşme yoludur.

resolvectl revert o bağlantının çalışma zamanı DNS yapılandırmasını sıfırlar; bu, çözümleyiciyi yeniden başlatmaktan daha dar ve genel dosyayı düzenlemekten çok daha dardır. Tünel bağlantısı tamamen kaybolduysa systemctl restart NetworkManager bağlantı durumunu yeniden kurar ve kaynak iş parçacıklarının sürekli döndüğü adım budur. Restart=always içeren bir hizmet yöneticisine dikkat edin, çünkü öldürülen bir istemciyi ve DNS ayarlarını doğrudan geri koyabilir.

Diğer yön: itilen ama hiç gelmeyen DNS

Eski kaydın ayna görüntüsü, hiçbir kullanılabilir çözümleyicisi olmayan bir tüneldir. Profildeki DNS seçeneği bir istektir; bağlantıyı yöneten bileşenin onu çözümleyiciye teslim etmesi gerekir. Günlük sunucunun alındığını ancak tünel bağlantısının hiçbir DNS ayarı taşımadığını gösteriyorsa, eksik olan tümleştirmedir, sunucu değil.

Teslimatı elle yaparak test edin; bu, «sunucu yanlış» ile «kimse uygulamadı»yı ayırır:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Her şeyi yakalayan yönlendirme alan adı her adı o bağlantıya gönderir; tam tünel istemcisinin istediği budur ve bölünmüş DNS’in kullanmaması gereken de budur. Bu ayarlar bir sonraki bağlantıda kaybolur. NetworkManager’da kalıcı kılmak için otomatik DNS’i kapatın, sunucuyu bağlantıya ayarlayın ve alan adını ekleyin:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Yalnızca iç adlara yanıt vermesi gereken bir şirket tüneli için, o bölgeleri her şeyi yakalamak yerine başında tilde ile listeleyin, böylece genel adlar yerel çözümleyiciyi kullanmaya devam etsin.

Bir sonraki kesintiye dönüşen geçici çözümler

Bağlanmadan önce resolv.conf’u kopyalayıp sonra geri yüklemek bir runbook’ta meşru bir satırdır ve bu bir geçici çözümdür, onarım değil. Tam da önemli olduğunda başarısız olur, çünkü bir çökme ya da zorunlu yeniden başlatma geri yüklemeyi atlar. Bir sonraki kişi bunun üzerine inşa etmesin diye geçici çözüm olarak yazın.

systemd-resolved’i kapatmak ve genel sunucuları sabit kodlamak diğer popüler hamledir. Bağlanmayı ve kesilmeyi öngörülebilir kılar ve diğer her ağ için bağlantı başına DNS’i kaldırır; bu, iç adlar için bölünmüş DNS’i bozar ve sorguları içinde tutmak için tasarlanmış bir tünelin amacını boşa çıkarır. resolvconf kurmak ve genel sunucuları sabitlemek ekstra bir katmanla aynı maliyettedir. İkisinden birini tanı olarak görün: gezinmeyi geri getiriyorsa, genel sunucuların doğru olduğunu değil, çözümleyici tümleştirmesinin suçlu olduğunu öğrendiniz.

Kalıcı düzeltme katman başına tek sahiptir: tünel bağlantısının DNS’ine hangi bileşenin, genel varsayılana hangisinin sahip olduğuna karar verin, bunu yazın ve diğerlerini yoldan çıkarın. Sonra kesildikten sonra yalnızca VPN’in çözdüğü bir adla doğrulayın. Özel bir ad hâlâ yanıtlıyorsa kayıt kaldırılmamıştır; hiçbir şey çözülmüyorsa dosya artık var olmayan bir sunucuyu gösteriyordur. İkisi de tarayıcıyı açmadan önce resolvectl’de görünür.