VPN içinde mDNS: .local adları neden çözümlenmiyor

Ofis yazıcınız masanızdaki her uygulamada görünüyor ve VPN'de kayboluyor, oysa sahip olduğunu bildiğiniz adrese ping atabiliyorsunuz. Tünelde hiçbir şey bozuk değil: keşif ve erişilebilirlik ayrı hizmetlerdir ve varsayılan olarak yalnızca biri yönlendirilmiş bir tüneli geçer. Aşağıdaki kontroller, siz rota eklemeye başlamadan önce ikisini ayırır. Bir rota, bağlantıyı hiç terk etmemiş bir sorguyu düzeltemez.

Bugün neyin çözümlendiğini ve neyin yalnızca çözümlenmiş göründüğünü kontrol edin

Önce iki soruyu ayırın: bir ana bilgisayar adı için unicast sorgusu bir çözümleyiciye sorar, oysa _ipp._tcp araması yerel bağlantıya sorar. Linux'ta avahi-browse -a multicast DNS'in ne görebildiğini gösterir ve resolvectl query name.local çözümleyici yığınının o adla ne yaptığını gösterir. macOS'ta dns-sd -B _ipp._tcp önce bir adres gerekmeden keşfedilen hizmetleri listeler.

Adres yanıt verip ad vermiyorsa, yönlendirme çalışıyor ve keşif çalışmıyor. .local adı, avahi-browse kurulu olmasa bile nss-mdns üzerinden ana bilgisayarın kendisinde yanıtlanabilir, bu nedenle o ada yapılan başarılı bir getent veya ping, keşfin tüneli geçtiğinin kanıtı değildir; arama sonucu ile çözümleyici sonucu farklı kanıtlardır. Uygulamalar keşfettiklerini önbelleğe alır, bu yüzden arıza genellikle bağlanma anında değil, bağlandıktan saatler sonra ortaya çıkar. Uygulamayı kapatıp yeniden açın, ardından önbellekteki girdinin ad mı yoksa adres mi içerdiğini kontrol edin, çünkü adres keşif durduktan çok sonra da çalışmaya devam eder.

Sorgu neden tüneli hiç geçmez

Multicast DNS sorguları 224.0.0.251 adresine, yerel ağ denetim bloğunun içinde, UDP 5353 bağlantı noktasına gönderir. Yönlendiriciler o bloktaki adresleri iletmez, bu yüzden sorgu gönderildiği bağlantıda kalır. Göndericiler ayrıca IP TTL'yi veya IPv6 atlama sınırını 255'e ayarlar, böylece alıcı zaten bir yönlendiriciden geçmiş paketi reddedebilir; protokol bağlantı dışı sahtekârlığı böyle algılar, yerel kalması bu şekilde değildir. Yerellik hedef adresten gelir, tek atlamalı bir TTL'den değil.

Tünel türü de önemlidir. tun tarzı bir arayüz yalnızca IP paketleri taşır, başka bir şey taşımaz, bu yüzden hiçbir multicast grubu onu geçemez. tap tarzı bir köprü yayın alanını kendisi genişletir, bu yüzden bazı eski tasarımlar yönlendirme yerine köprü kurdu ve köprünün getirdiği her sorunu devraldı.

Güvenilir LAN istisnası bunlardan hiçbirini değiştirmez, çünkü tünele multicast iletmeyi öğretmek yerine hangi trafiğin tüneli kullanabileceğine karar verir. Paketin hâlâ duyulabileceği ortak bir segmenti yoktur.

Sürdürebileceğiniz bir adlandırma tasarımı seçin

Şirket kaynakları için kalıcı yanıt, VPN'in ittiği çözümleyicinin hizmet verdiği yönlendirilmiş bir ana bilgisayar adıdır; yanında bölünmüş DNS ile iç adlar iç sunuculara gider ve diğerleri gitmez. Windows bunu ad çözümleme ilkesi tablosu olarak sunar, macOS arayüz başına kapsamlı çözümleyiciler kullanır ve çoğu istemcide eşdeğer bir itme ayarı vardır. Cihaz normal adını iç DNS'te korur ve keşif yolun parçası olmaktan çıkar.

Bir keşif vekili veya mDNS yansıtıcısı bu boşluğu köprüleyebilir ve bu, kendi ana bilgisayarı, kendi maruziyeti ve kendi istemci gereksinimleri olan gerçek bir tasarımdır. Bir rota eklediğiniz için ortaya çıkmaz. .local sorgularını asla genel bir çözümleyiciye iletmeyin: alan adı RFC 6762 tarafından yerel multicast kullanımı için ayrılmıştır ve dışarı göndermek yavaş arızalara ve gereksiz veri ifşasına yol açar.

Hizmeti doğrulayın, adı değil

Arama listesindeki bir ad, keşif adımını kanıtlar, hizmetin yanıt verdiğini değil. Yazdırma kuyruğunu veya web arayüzünü açın ve gerçek bir işlem tamamlayın, ardından yeniden bağlandıktan sonra tekrarlayın.

Keşif adları agresif biçimde önbelleğe alır, bu yüzden eski bir girdi başarı gibi görünebilir. Bir sertifika veya kimlik doğrulama istemi görünürse, bu sonraki katmandır ve ayrı bir sorundur. Hangi mekanizmayı değiştirdiğinizi, çözümleyiciyi mi keşfi mi, not edin ki bir sonraki kişi tüm soruyu yeniden açmak zorunda kalmasın.