VPN ana makine adları başarısız oluyor, IP adresleri çalışıyor: nereye bakmalı

Paylaşımı adresle açabiliyorsunuz ve aynı paylaşım adla başarısız oluyor; bu, tünelin paket taşıdığı ve ad katmanının taşımadığı anlamına gelir. Bu tek gözlem, güvenlik duvarı ve yol değişiklikleri üzerinden yapılacak bir dolambaçtan kurtarır. Adların bir sonek, bir çözümleyici ve sorgu için bir yola ihtiyacı vardır ve bir VPN istemcisi bunların hiçbirini kurmadan bir yol kurabilir. Aşağıdaki dört denetimi sırayla yapın ve ilk bozulanda durun.

Ad, adresin sormadığı soruyu sorar

Adres, yığının hemen kullanabileceği bir hedeftir. Kısa ad, bir sonekle genişletilmesi, bir çözümleyiciye gönderilmesi ve bölgeyi bilen bir şey tarafından yanıtlanması gereken bir sorudur. Yolları kurup çözümleyiciyi kurmayan bir tünel, ilkini çalışır, ikincisini bozuk bırakır. Bu yüzden belirti çok farklı VPN ürünlerinde bu kadar tutarlı görünür.

Adresten dışarı doğru çalışın: önce tam ad, sonra çıplak ana makine adı ve üçünden hangisinin çalıştığını not edin. Desen, tek bir yapılandırma ekranı açmadan önce hangi katmanı incelemeniz gerektiğini söyler. FQDN çözülürken yollar hakkında tahmin yürütmek boşa emektir.

Tünelin gerçekte kurduğu çözümleyiciyi okuyun

İşletim sistemine iç bölge sorgularını hangi çözümleyicinin işlediğini sorun, VPN istemcisinin arayüzünün hangisini duyurduğunu değil. İç bölge olmadan genel bir çözümleyiciyi zorla iten sunucu tam olarak bu başarısızlığı üretir ve bu, yönlendirme arızası değil yapılandırma hatasıdır.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Etki alanına katılmış bir Windows istemcisinde ad alanı yönlendirme ilkesi hangi sorguların hangi çözümleyiciye gideceğine karar verir ve VPN bağdaştırıcısının kendi DNS ayarları bağdaştırıcı ayrıntılarında görünür. Profili değil yürürlükteki ilkeyi okuyun, çünkü önbelleğe alınmış bir ilke onu kuran bağlantıdan daha uzun yaşayabilir. Çözümleyici tam ada yanıt verip kısa ada vermiyorsa, sorun çoktan sonek listesine taşınmıştır.

Get-DnsClientNrptPolicy
ipconfig /all

İç bölge doğru sunucu üzerinden çözülüyorsa durun. Çözümleyici sizin sorununuz değil.

Sonekler başarısız olan kısa adları açıklar

Tek etiketli bir ad, sorgu gönderilmeden önce bağlantının sonek listesiyle genişletilir. VPN iç soneği teslim etmezse fileserver asla fileserver.corp.example olmaz ve sorgu hiçbir genel çözümleyicinin bilmediği bir ad olarak çıkar. Soneği zorla itmek veya tam adı yazmak, sunucuda hiçbir şeyi değiştirmeden varsayımı sınar.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linux’ta çözümleyici hizmeti bir DNS sunucusunu bir bağlantıya ve bir yönlendirme etki alanları kümesine bağlar, bu yüzden tünelin bağlantısıyla ilişkilendirilmemiş zorla itilen sunucu orada yokmuş gibi davranır. Yalnızca yerel çözümleyiciyi gösterebilen stub dosyası yerine bağlantı başına durumu denetleyin. Aynı bölünme ters yönde de görünür: var olan ancak tünel arayüzüne uygulanmayan bir arama etki alanı, rastgele görünen kısa ad başarısızlıkları üretir.

Soneği eklemek bunu düzeltiyorsa, geriye kalan iş her kullanıcıdan yazmasını istemek yerine o soneği VPN profili üzerinden teslim etmektir.

NetBIOS ve WINS başka bir mekanizmadır

Eski SMB, çıplak bir adı hâlâ NetBIOS ad hizmetiyle arayabilir; bu hizmet yayın yoluyla veya bir WINS sunucusu üzerinden yanıt verir. Yayın tek bir yayın etki alanı içinde kalır ve ilk yönlendiricide durur, bu yüzden bir tüneli geçemez; WINS çalışır çünkü istemcinin kaydolacağı ve sorgulayacağı bir tek yönlü adresi vardır. Bu yüzden yalnızca IP taşıyan bir VPN, WINS yapılandırılmış ve erişilebilir olduğunda eski adları hâlâ destekleyebilir.

nbtstat -n
nbtstat -R

Modern SMB için DNS’e ve tam ada güvenin, eski yolu emekliye ayırın. Gerçekten eskise WINS sağlayın veya uygulamayı değiştirin; orta yol hiç boşalmayan bir destek kuyruğudur.

Bu yürüyüş, hangi katmanın başarısız olduğunu söyleyebildiğinizde biter: çözümleyici, sonek veya eski keşif. Yanıt veren çözümleyiciyi ve işe yarayan ad biçimini not edin, çünkü sıradaki kişi aynı belirtiyle başlayacak.