ip netns exec ve DNS: adlar neden ad alanının içinde başarısız olur

Bir komut VPN ad alanının içinde 10.8.0.5 adresine hiçbir şikâyet olmadan ulaşır, aynı komut bir ana bilgisayar adı kullandığı anda başarısız olur. Ad alanının kendi arayüzleri, yolları ve soketleri vardır; kendi çözümleyici dosyası yoktur. Bir şey oraya bir tane koymazsa, içerideki süreç ana bilgisayarın /etc/resolv.conf dosyasını okur ve o ağ yığınından erişilemeyebilecek bir sunucuya sorar.

Bu bir yönlendirme sorunu değil dosya seçimi sorunudur ve sayısal hedefin hâlâ çalışmasının nedeni tam olarak budur.

Sürecin gerçekte aldığı çözümleyici görünümünü kontrol edin

Kullandığınız kabuğun, hata ayıkladığınız süreçle aynı olduğunu varsaymayın. Grafik bir uygulama, bir systemd birimi ve bir konteyner her biri farklı bir bağlama veya ağ bağlamına girebilir. Aramayı aynı başlatma yolu üzerinden çalıştırın ve çözümleyici dosyasını içeriden yazdırın.

ip netns add ile oluşturulmuş bir ad alanı için salt okunur kontrol kısadır:

ip netns exec vpn cat /etc/resolv.conf

Sonucun erişilebilir bir adres, bir loopback stub'ı veya farklı erişilebilirliğe sahip bir yere işaret eden bir sembolik bağlantı belirtip belirtmediğine dikkat edin.

exec yardımcısının gerçekte neyi bağladığı

ip-netns aracı, ad alanı başına yapılandırmayı /etc/netns/NAME/ altında belgeler. Bir süreç başlattığında yardımcı bir bağlama ad alanı oluşturur ve bu dosyaları olağan yollarının üzerine bağlar, böylece süreç ad alanına özgü kopyayı görür. Bu, tam olarak bu başlatıcının kolaylığıdır. Bir ağ ad alanına başka bir yoldan, örneğin unshare veya bir konteyner çalışma zamanı ile girmek bunu otomatik olarak yeniden üretmez.

Buradaki tuzak loopback çözümleyicisidir: 127.0.0.53 ad alanının kendi loopback'ini ifade eder, ana bilgisayarın stub'ını değil. Yalnızca ana bilgisayarın ad alanında dinleyen bir stub yenisinde hizmet hâline gelmez.

Ad alanının ulaşabildiği bir çözümleyici seçin

Dosya hangi sunucuyu belirtirse belirtsin, hâlâ o ad alanından bir yol gerektirir. Genel bir çözümleyici genel adları yanıtlayıp yine de iç bölge için başarısız olabilir, çünkü özel hizmete yalnızca tünel üzerinden ulaşılabilir. Yolu adresle aynı anda kontrol edin, arama zaten başarısız olduktan sonra değil.

Kendi çözümleyicisine sahip uygulamalar, örneğin DNS over HTTPS kullanan biri, dosyayı tamamen yok sayabilir. Aracın kendi DNS ayarı varsa, resolv.conf dosyasını değiştirmek onu etkilemez ve ad alanı hiçbir zaman sorun olmamıştır.

Dosyayı doğru yere yazın

Ad alanına özgü dosyayı /etc/netns/NAME/resolv.conf altında oluşturun ve başlatıcının onu sunmasına izin verin. Onu asgari tutun: bir veya iki erişilebilir sunucu ve görevin ihtiyaç duyduğu arama alan adları. Tek bir süreç grubu için düşünülmüş bir görünümü düzeltmek için ana bilgisayarın oluşturulmuş çözümleyici dosyasını düzenlemeyin, çünkü bu makinedeki her uygulamayı değiştirir. Ana bilgisayar bir çözümleyici yöneticisi kullanıyorsa, onunla savaşmak yerine ad alanı yolunu o yönetici aracılığıyla yapılandırın.

Dosya içeriğini runbook'a kaydedin. Aksi halde bir sonraki kişi ana bilgisayarın çözümleyicisini test eder, çalışan bir yanıt görür ve ad alanının iyi olduğu sonucuna varır.

Tüm yolu yeniden test edin

Ad alanının içinde sayısal bir adres, iç ad ve genel ad ile test edin. Bu sıra erişilebilirliği çözümlemeden ayırır ve iç bölgeleri genel bölgelerden ayırır. Ardından ad alanını yeniden oluşturun ve tekrarlayın, çünkü yalnızca çalışan bir örnekte var olan bir dosya onunla birlikte kaybolur.

Dosyayı kabuğun değil sürecin aldığını doğrulayın. Etkileşimli bir kabuktan çalışıp bir hizmetten başarısız olan bir arama, bağlama bağlamıyla ilgili bir bulgudur ve bir sonraki olaydan önce sıfırdan yeniden keşfetmek yerine yazıya geçirmeye değer.