/etc/hosts girdiniz neden VPN'in DNS'ine ulaşmıyor

/etc/hosts dosyasına bir ad eklediniz, VPN'e bağlandınız ve kaydın herkese görünmesini beklediniz. Bu olmaz ve sürpriz genellikle ikinci bir belirtiyle gelir: ad sizin makinenizde çözülür, bir iş arkadaşınızınkinde çözülmez; bu bozuk bir VPN DNS hizmeti gibi görünür ve aslında hosts dosyası tam olarak tasarlandığı işi yapmaktadır. Hosts dosyası yerel ad çözümleme yapılandırmasıdır, bölge güncellemesi değildir ve normal bir VPN bağlantısında hiçbir şey onu yüklemez.

Hosts yerel bir geçersiz kılmadır, bölge güncellemesi değil

Dosya, ad hizmeti kütüphanelerinin bir DNS sunucusuna sormadan önce veya onun yerine baktığı eşlemelerin listesidir. 10.40.0.20 build.corp.example gibi bir satır, o tek makinedeki uygulamaların ne sonuca vardığını değiştirir. Bir kayıt oluşturmaz, tünelden geçmez ve tünelin işaret ettiği DNS sunucusunun varlığından haberi yoktur.

Bu yüzden hata asimetriktir. İstemciniz dosyadan bir yanıt alır. Başka bir istemci VPN'in DNS sunucusuna sorar, o hiçbir şey döndürmez ve uygulama adın var olmadığını bildirir. İki makine de doğru davranır; yalnızca biri diğerinin hiç görmediği bir geçersiz kılmaya sahiptir.

İki komut, iki farklı bileşen

Tartışmayı bitirmenin en hızlı yolu, farkı iki komutta görünür kılmaktır; ikisi de hosts girdisi olan istemcide çalıştırılır:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Birincisi sistemin kendi arama yoluna sorar; tipik bir glibc sisteminde bu, DNS'ten önce yerel dosyaları okur. İkincisi DNS sorgusunu doğrudan o adresteki sunucuya gönderir ve yerel dosyalara hiç bakmaz. Birincisi sizin girdinizi döndürüp ikincisi NXDOMAIN döndürdüğünde, kaydın DNS'te olmadığını ve makinenizin yerel bir geçersiz kılmadan yanıt verdiğini kanıtlamış olursunuz.

Sıra yapılandırılabilir ve belirli bir dağıtım hakkında herhangi bir sonuca varmadan önce kontrol etmeye değer. /etc/nsswitch.conf içindeki hosts: satırına bakın; hosts: files dns önce dosyalara bakar. Sırayı değiştirmek için o örneği çalışan bir yapılandırmanın üzerine kopyalamayın, çünkü gerçek sistemler sıklıkla örnekte bulunmayan ek kaynakları ve koşullu hizmet girdilerini listeler.

systemd-resolved testi bulanıklaştırır

systemd-resolved kullanan bir sistemde yerel stub da hosts veritabanından adlar sunar. Bu nedenle 127.0.0.53 sorgusu, DNS sorgusuna benzese ve öyle davransa da uzak sunucunun bağımsız bir testi değildir. Çözümleyicinin ne bildiğini ve hangi sunuculara soracağını şununla doğrulayabilirsiniz:

resolvectl query build.corp.example
resolvectl status

status çıktısı DNS sunucularını her bağlantı için adlandırır ve VPN bağlantısının bir çözümleyici alıp almadığını böyle öğrenirsiniz. Bu soru hosts girdisinden ayrıdır ve özel bir ad bir kişi yerine tüm kullanıcılar için başarısız olduğunda sorulmaya değer soru budur.

Uygulamalar bir katman daha ekleyebilir. Kendi DNS-over-HTTPS ayarına sahip bir tarayıcı, kendi çözümleyici yapılandırmasına sahip bir konteyner veya sürecin tüm yaşamı boyunca aramaları önbelleğe alan bir çalışma zamanı, her biri sistemden farklı yanıt verebilir. Tek bir komutun makinedeki her programı tanımladığını varsaymak yerine önemsediğiniz uygulamayı test edin.

VPN üzerinden bir adı gerçekte ne paylaşır

Özel bir ad herkes için çalışacaksa, herkesin çözümleyicisinin ulaşabileceği bir sahibe ihtiyacı vardır. Temiz yanıt, kaydı yönetilen bir bölgede yayımlamak ve o bölgeyi VPN'in amaçlanan DNS yolundan çözülebilir kılmaktır. O zaman kaydın tek bir doğruluk kaynağı, bir denetim izi ve bir yaşam döngüsü olur ve kimsenin hangi dizüstü bilgisayarda yerel bir geçersiz kılma olduğunu hatırlaması gerekmez.

Hosts dosyalarını dağıtmak meşru bir alternatiftir ve bu, ad hizmeti değil uç nokta yönetimidir. Bunu seçerseniz dosya, filoyu yöneten şey tarafından dağıtılmalı, sürümlenmeli ve kaldırılmalıdır ve tasarımda da böyle tanımlanmalıdır. “VPN bununla ilgilenir” o sürecin bir açıklaması değildir.

Dinamik DNS kaydı, kendi izinleri, güncelleme kimlik doğrulaması ve kayıt ömrüyle üçüncü bir mekanizmadır. Bir hosts girdisinden doğmaz ve bir istemcinin sadece bağlanmasından da doğmaz, sunucu ve istemci ikisi de bunun için yapılandırılmadıkça. Kendiliğinden görünen bir kayıt, birinin güvenli güncellemeleri etkinleştirdiğinin ve bir istemcinin kendini kaydettiğinin işaretidir ve bu yapılandırma sorun giderme başlığına değil tasarım kaydına aittir. Kimse o ayarın sahibini söyleyemiyorsa otomatik kaydı doğrulanmamış sayın ve yönetilen bölgeyi doğruluk kaynağı olarak tutun.

Çözülmüş bir ad bir yol değildir

Ad çözümleme ve erişilebilirlik ayrı şeylerdir ve eski yerel eşleme bunları karıştırmanın klasik yoludur. Taşınmış bir adrese işaret eden bir hosts girdisi, DNS düzeltildikten çok sonra bile eski ana bilgisayarı seçmeye devam eder ve belirti, iyi çözülen bir ad üzerinde yönlendirme hatası gibi görünür.

Bu yüzden rapor “ad çözülüyor ama hizmete ulaşılamıyor” olduğunda, sistem aramasını VPN'in DNS sunucusuna yapılan açık bir sorguyla karşılaştırın ve ardından aldığınız adresi hizmetin gerçekte kullandığı adresle kontrol edin. systemd-resolved başvurusu baktığı yerel kaynakları belgeler ve o karşılaştırma için ihtiyacınız olan harita budur.

Ardından geçersiz kılmayı sahibi aracılığıyla düzeltin. Kendi hosts dosyanızdan bir satırı silmek, aynı satırı bir dağıtım betiğinden alan on iki dizüstü bilgisayar için hiçbir şey yapmaz ve insanların gerçekte yaşadığı bu sorunun sürümü budur.