resolv.conf VPN DNS'inizi gösterirken aramalar neden onu yok sayar

Günlüklerde yanlış görünen bir şey yok: arayüz açık, çözümleyici VPN'in DNS sunucusunu bildiriyor ve diskteki dosya onu listeliyor. Yine de dahili bir ana bilgisayar adı yerel yönlendirici üzerinden çözümleniyor. Bu üç ifade birbiriyle çelişmiyor, çünkü dosya, her bağlantının durumu ve arama yolu aynı adı tesadüfen paylaşan farklı nesneler. Aşağıda systemd-resolved çalışan bir ana bilgisayarda bir sorgunun gerçekte izlediği yol anlatılıyor.

resolv.conf adlı üç nesne

resolved çalışan bir ana bilgisayarda /etc/resolv.conf genellikle /run/systemd/resolve/stub-resolv.conf dosyasına bir sembolik bağlantıdır. O hedef, yerel stub dinleyicisinin adresini, 127.0.0.53, ve resolved'ın hesapladığı arama alan adlarını tutar. Bu durumun bir görünümüdür, durumun kendisi değil.

Durum resolved'ın her bağlantı için yapılandırmasında yaşar, bu yüzden resolvectl status dosyayla çelişip yine de haklı olabilir. Her bağlantı kendi sunucularını ve kendi yönlendirme alan adlarını taşır ve stub bir sorgu geldiğinde bu verilere başvurur. systemd-resolved kılavuzu üretilen dosyaları ve bağlantı başına modeli açıklar; görünüm ile durum ayrımı akılda tutulmaya değer kısımdır. Sembolik bağlantının hedefini değiştirmek geleneksel istemcilerin okuduğunu değiştirir, çözümleyicinin bildiğini değil.

Üçüncü nesne, /run/systemd/resolve/resolv.conf, her bağlantıyı tek bir sunucu listesine düzleştirir. O dosyaya yönelen bir program sorguları doğrudan listelenen sunuculara gönderir ve stub'ı atlar, bu yüzden bağlantı başına ilke artık onun için geçerli değildir. Bu nedenle aynı makinedeki iki program aynı ada farklı yanıt verebilir ve hiçbiri bozuk değildir.

NSS üzerinden tek bir aramayı izleyin

glibc bir ada kimin yanıt vereceğine karar vermek için /etc/nsswitch.conf dosyasını okur. resolve içeren hosts satırı soruyu nss-resolve adresine yönlendirir; o da D-Bus üzerinden resolved'a sorar ve bağlantı başına yanıtı alır. Yalnızca files dns içeren satır sorguyu /etc/resolv.conf adresinin tuttuğu yere gönderir.

Bu tek satır tarayıcı ile dig arasındaki anlaşmazlıkların çoğunu açıklar. dig resolv.conf dosyasını doğrudan okur ve NSS'e hiç dokunmaz, bu yüzden uygulamanın kullandığı yol yerine stub'ı ya da üst akıştaki sunucuyu sınar. getent hosts internal.example NSS üzerinden geçer ve yanıtını dig yanıtıyla karşılaştırmak ilk yararlı ölçümdür.

Kendi çözümleyicisini getiren ya da sabit bir uç noktaya HTTPS üzerinden DNS konuşan uygulamalar iki yolu da atlar. resolv.conf içinde ya da resolved durumunda hiçbir şey onları kısıtlamaz.

Dosyanın kime ait olduğunu ve nereye işaret ettiğini denetleyin

Herhangi bir şeyi değiştirmeden önce bağlantı zincirini okuyun, çünkü hangi dosyanın yetkili olduğuna sahiplik karar verir. Aşağıdaki her komut yalnızca durumu okur.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

İlk satır bağlantıyı ve hedefini birlikte yazdırır; bir VPN betiğine ait sıradan bir dosya ise çözümleyicinin o yazımı hiçbir zaman girdi saymadığı anlamına gelir. Durum çıktısı bağlantı başına sunucuları ve her sorgunun nereye gittiğini belirleyen yönlendirme alan adlarını listeler. nsswitch satırı stub'a hiç başvurulup başvurulmadığını söyler; dolayısıyla dosyada stub adresi olup orada resolve yoksa sorgular yerel dinleyiciye ulaşır ama ayrımı hiçbir şey yönetmez. O son liste de önemlidir, çünkü stub-resolv.conf olmayan bir ana bilgisayar burada anlatılan düzeni çalıştırmaz.

Zincir başka bir paketin yönettiği bir dosyada bitiyorsa, VPN istemcisi ve o paket uzlaştırılması gereken iki sahiptir. Bağlantıyı değiştirmek bir sahibin işini çöpe atar ve diğerinin işini yerinde bırakır.

Bağlantının sahibinde onarın

Bir VPN bağlantısı sunucularını ve alan adlarını kendi bağlantısında kaydetmeli, sonra bağlantı kesildiğinde bunları geri çekmelidir. NetworkManager'ın resolved entegrasyonu ve istemcinin kendi yardımcısı ikisi de böyle çalışır; yalnızca resolv.conf dosyasını yeniden yazan bir betik çalışmaz.

Zaten var olan bir bağlantıda mekanizmayı çalışma zamanı ayarları gösterir. resolvectl dns tun0 10.40.0.53 bir sunucu bağlar, resolvectl domain tun0 '~corp.example' bir yönlendirme alan adı bağlar. Tilda yükü taşıyan karakterdir: o sonek için sorguları bu bağlantıyla sınırlar ve geri kalan her şeyi rahat bırakır; tilde olmadan aynı değer bir arama alan adı olur ve ayrım buharlaşır. O adresler laboratuvar örnekleridir, kalıcı bir yapılandırma değildir. resolvectl query host.corp.example ile doğrulayın ve hangi bağlantının yanıt verdiğini okuyun.

Kayıtlı bir sunucunun yine de bir rotaya ihtiyacı vardır. Sorgu doğru bağlantıya ulaşıp zaman aşımına uğrarsa, kusur çözümleyicinin sahipliğinde değil, tünel üzerinden erişilebilirliktedir.

Çalışan bir durum nasıl görünür

Sağlıklı bir sonuç üç görünümde de tutarlıdır: bağlantı başına sunucular VPN'in dağıttığıyla eşleşir, yönlendirme alan adları yalnızca dahili son ekleri kapsar ve önemli uygulama dahili bir adı çözerken genel ad hâlâ yerel yolu izler. Tek bir başarılı sorgu bu uyumdan daha azını kanıtlar.

Sonra bağlantıyı kesin ve iki sorguyu yineleyin. Sökümden sonra alan adlarını kayıtlı bırakan bir istemci saatler sonra dahili aramalarda başarısız olan bir makine üretir; açık tünel ve belirgin bir neden yoktur.