VPN DNS çalışıyor ama .local adları hâlâ başarısız: onları kim çözüyor?

Aynı VPN üzerindeki iki makine, aynı ana bilgisayar adı ve yalnızca biri onu çözüyor: fark genellikle tünel değil, hangi çözümleyicinin yanıt verdiğidir. Bir Linux masaüstünde bu ad ad hizmeti anahtarından, systemd-resolved'ın stub'ından veya uygulamanın kendisiyle getirdiği bir çözümleyiciden geçebilir ve her biri aynı son eke kendi kuralını uygular. Kuralların ayrıldığı yer tam da son ektir, çünkü .local tarafsız bir etiket değildir. Herhangi bir şeyin hangi sırayla çalıştığını değiştirmeden önce başarısız olan programın gerçekte hangi yolu izlediğini bulun.

İki çözümleyici, iki farklı yanıt

Geleneksel bir glibc araması nsswitch.conf içindeki hosts: satırını izler ve biri yanıt verene kadar her modüle sırayla sorar. Stub dinleyicisi üzerinden systemd-resolved ile konuşan istemci bunun yerine tek bir sürece sorar ve o süreç bağlantı başına politikayı artı kendi özel durumlarını uygular. Kendi çözümleyicisini getiren ya da bunu yapan bir kütüphaneyi bağlayan uygulama ikisini de atlayabilir. Böylece tek bir ana bilgisayar adının tek bir makinede üç sahibi olabilir ve yalnızca biri VPN'in ne amaçladığını bilir.

Herhangi bir şeyi değiştirmeden önce sahibi belirleyin, çünkü düzeltme üçünün her biri için farklıdır. Aynı masaüstündeki bir tarayıcı ile komut satırı aracı meşru olarak anlaşamayabilir ve bu anlaşmazlık ipucudur, hata değil. Tarayıcı adı çözüyor da araç çözemiyorsa, bir çözümleyici yolunu ayıklıyorsunuz, VPN rotasını değil. Rotayı ayrıca doğrulayın, böylece bir yönlendirme hatası ad hizmeti hatasıyla karıştırılmasın. İkisi de aynı fikirdeyse hata ana bilgisayarın üstündedir ve buradaki çözümleyici yapılandırması başka bir düzenlemeye değmez.

Hangi komut çözümleyicinize gerçekten sordu

Salt okunur iki komut ilgili soruları yanıtlar ve bunları karşılaştırmak sorunu yapılandırmayı okumaktan daha hızlı yerelleştirir. Gerçek bir iç ad kullanın ve çıktıyı gizli tutun, çünkü iç kayıtlar iç kalır. İkisini de başarısız programın çalıştığı aynı oturumda çalıştırın:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

İlki yapılandırılmış modüller üzerinden sorar, tipik bir programın deneyimlediği budur. İkincisi doğrudan systemd-resolved'a sorar ve yanıtlayan bağlantıyı, protokolü ve sunucuyu bildirir. Sunucuya adresle soru sormak yalnızca sunucunun kaydı tuttuğunu kanıtlar, çünkü uygulamanın ona hiç sorup sormadığı hakkında hiçbir şey söylemez. VPN'i taşıyan bağlantıyı ve iddia ettiği alan adlarını okuyun, sonra bu listeyi başarısız addaki son ekle karşılaştırın.

.local neden unicast bölgenizi atlıyor

systemd-resolved başvurusu şunu belirtir: .local ile biten çok etiketli adlar mDNS etkinleştirildiğinde normal unicast DNS yerine genellikle multicast DNS'e gider. RFC 6762 bu ad alanını link-local multicast için ayırır, bu yüzden bir kurumsal bölge o son ek için hiç sorulmayan doğru bir kayda sahip olabilir. Tünel çözümleyiciyi kusursuz yönlendirebilir ve yine de yarışı kaybedebilir. Önbellekten başarılı bir ping, az önce gerçekleşen arama hakkında hiçbir şey söylemez.

Belgelenmiş bir istisna var ve bu durumların çoğunu çözer: bir bağlantı o son eki arama alanı veya yönlendirme alanı olarak bildirdiğinde, daemon onu unicast yolunda tutar ve multicast özel durumunu atlar. Bu bağlantı başına politikadır, küresel bir tercih değildir. Aynı VPN sunucusuna sahip iki makine, bir ağ profili alan adını bildirip diğeri bildirmediğinde farklı davranabilir, bu yüzden düzenlediğinizi hatırladığınız profili değil etkin profili okuyun.

Dar istisna küresel yeniden sıralamayı yener

Adını değiştiremediğiniz mevcut bir bölge için çözümleyici ve VPN sahiplerinin alan adını onu taşıyan bağlantıda bildirmesini sağlayın. O tek son ek için yönlendirme alanı girdisi artı amaçlanan sunucu adresi, adı belirtilmiş bir sahibi olan küçük bir değişikliktir ve elle düzenlenmiş bir dosyada değil bağlantıyla birlikte yaşar.

Bağlantı kesildikten sonra da hayatta kalır, çünkü bağlantı geri geldiğinde bağlantı politikası yeniden uygulanır. Paylaşılan nsswitch.conf dosyasını düzenlemek cezbedici ve daha pahalı alternatiftir, çünkü makinedeki her ad için arama davranışını, yerel keşif dahil, değiştirir. Multicast daemonunu devre dışı bırakmak da eşdeğer değildir: yerel davranışı kaldırır ama hiçbir çözümleyiciye kurumsal bölgeyi öğretmez. Hizmet yeni ve devralınmış değilse, onu kuruluşunuzun kontrol ettiği bir alt alan adının altına koyun ve rekabeti tamamen atlayın. Ad ürün yazılımında sabitlenmişse veya bir etikete basılmışsa dar istisnayı seçin, istemciyi hâlâ kontrol ediyorsanız yeni bir alt alan adı seçin.

Değişiklikten sonra ne kanıtlanmalı

Düzeltmeyi, test için kurduğunuz bir araçla değil uygulamanın kendi aramasıyla kanıtlayın ve onun yerine yanıt verebilecek her önbelleği temizleyin. Sonra çözümleyici yolunu ve yanıtı veren bağlantıyı doğrulayın. Son olarak yerel keşfin değişiklikten önceki gibi davrandığını kontrol edin, çünkü görünmeyi bırakan yazıcı insanların en son fark ettiği kısımdır. Bu üç komut adı, yolu ve TLS kimliğini bu sırayla denetler:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Yanlış sertifikayla doğru adres katı bir istemciyi yine de başarısız kılar, bu yüzden çözümleme çalıştığında uygulamanın beklediği adı kontrol edin. Hizmetin yalnızca ofis aralığından değil VPN adresinden de bağlantı kabul ettiğini doğrulayın. Alan adı kapsamını, sunucuyu ve sahibi bağlantının belgelerine yazın. Aksi halde bu hatayla karşılaşan bir sonraki kişi, az önce kaçındığınız aynı küresel düzenlemeye başvuracaktır.