VPN bağlı ama adlar başarısız: DNS gerçekte nerede kırılıyor

Tünel ayakta, simge yeşil ve her tarayıcı sekmesi ad çözümleme hatası bildiriyor. Bu görüntüyü üç farklı mekanizma üretir: çözümleyiciye ulaşılamıyor olabilir, istemci beklemediğiniz bir çözümleyiciye soruyor olabilir veya yalnızca özel adlar başarısız olabilir. Tünel protokolünde herhangi bir şeyi değiştirmeden önce bunları ayırın, çünkü her biri farklı bir yerde onarılır. Aşağıdaki sıra, üçünü birbirinden ayıran gözlemlerle başlar.

Bir sorgunun gerçekte neye ihtiyacı var

Bir sorgunun üç şeye ihtiyacı vardır: çözümleyici adresi, o adrese giden rota ve soruya uyan yanıt. Her biri tek başına başarısız olabilir ve görünen belirti yüklenmeyen aynı sayfadır. Bu yüzden hata sayfası, üçünden hangisinin kırıldığını bilene kadar size neredeyse hiçbir şey söylemez.

İstemci çözümleyicisini VPN profilinden, tüneldeki DHCP'den veya kendi yapılandırmasından öğrenir ve hangi kaynağın kazanacağı platforma bağlıdır. Windows'ta ipconfig /all her bağdaştırıcı için DNS sunucularını listeler, böylece gönderilen değerin gerçekten ulaşıp ulaşmadığını görürsünüz. İşletim sistemine hiç ulaşmayan gönderilmiş bir değer sessiz ve yaygın bir hatadır. Profili değiştirmeden önce yapılandırılmış değeri okuyun.

Linux ve macOS aynı soruya farklı komutlarla yanıt verir ve yanıt da aynı okumayı hak eder: resolvectl status ve scutil --dns her ikisi de sunucuları arayüz başına listeler. Bu listeyi profilin gönderdiğini iddia ettiği adresle karşılaştırın. Buradaki uyumsuzluk aşağıdaki her şeyi açıklar, bu yüzden adları test etmeden önce bunu çözün.

Bir genel ve bir özel adı test edin

Aynı makineden sıradan bir genel ana bilgisayar adı ile belgelenmiş özel ana bilgisayar adını sorgulayın ve her birine hangi sunucunun yanıt verdiğini not edin. İkisi de başarısız olursa çözümleyici veya rotası bozulmuştur. Yalnızca özel ad başarısız olursa çözümleyici yanıtlamıştır ve soru bölge veya yönlendirmeye dönüşür. Rota değişikliğinin farkı açıklayamaması için iki sorguyu bir dakika içinde çalıştırın.

İç adları herkese açık ekran görüntülerinden ve genel çözümleyicilerden uzak tutun. Zaman aşımı ile var olmayan bir alan adı yanıtı farklı gözlemlerdir: birincisi hiçbir şeyin dönmediğini, ikincisi bir otoritenin adın olmadığını yanıtladığını söyler. İkisini tek hata olarak ele almak sizi yanlış katmana götürür ve sertifika uyarısı yine üçüncü bir şeydir, DNS hatası değildir.

nslookup sorgulanan sunucuyu ve alınan yanıtı birlikte yazdırır, tam ihtiyacınız olan çift de budur. Aynı kabukta iki kez çalıştırın ve yanıt veren adresi her yanıtın yanına yazın.

nslookup example.com
nslookup host.corp.example 10.20.30.53

İstemcinin gerçekten o sunucuya ulaşabildiğini doğrulayın

Profilin gönderdiği özel çözümleyici ancak tünel ayaktayken istemci ona ulaşabiliyorsa işe yarar. Doğru görünen bir adres rotasızsa zaman aşımı üretir ve tünelin bağlı durumu o rota hakkında hiçbir şey söylemez. Denetim, VPN uç noktasına değil çözümleyicinin kendisine yönelen rota aramasıdır.

Her platform bunu tek satırda yanıtlar ve çıktıda adlandırılan arayüz yanıtın tamamıdır. Çözümleyici tünelin arkasındayken fiziksel bağdaştırıcıyı gösteriyorsa profil onu kapsayan bir önek göndermiyordur.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Bölünmüş tünel profilinde çözümleyici gönderilen rotaların dışında kalabilir, bu sunucu değil profil sorunudur. Çözümleyici adresini gönderilen öneklerle karşılaştırın ve bunlardan birinin onu kapsadığını doğrulayın. Aynı uyumsuzluk, DNS'in bir ağda çalışıp aynı profile sahip başka bir ağda neden başarısız olduğunu açıklar.

Tarayıcıların sistem çözümleyicisini atlayabildiğini unutmayın

Güvenli DNS'i açık bir tarayıcı, sorguları HTTPS üzerinden kendi seçtiği bir sağlayıcıya gönderebilir ve işletim sisteminin çözümleyicisini tamamen yok sayabilir. O zaman sistem doğru görünürken tarayıcı başarısız olur veya tersi. Bu, tünel için değil tarayıcı için bir ilke sorunudur.

Tarayıcının güvenli DNS ayarını ve onu denetleyen yönetilen ilkeyi kontrol edin, ardından tünel değişmeden ikinci bir uygulama veya tarayıcı deneyin. Yalnızca bir uygulama başarısız olursa düzeltme o uygulamaya aittir. Gizli pencere temiz bir karşılaştırma değildir, çünkü bir tarayıcıda uzantıları varsayılan olarak devre dışı bırakabilir diğerinde bırakmaz ve yönetilen bir ilkeyi hiçbir zaman atlamaz. Bunun yerine ikinci bir tarayıcı profili veya başka bir uygulama kullanın.

Önbelleği temizleyin ve gerçek görevi yeniden test edin

Bir ayarı düzelttikten sonra yerel çözümleyici önbelleğini temizleyin ki eski yanıt düzeltmeden uzun yaşamasın. Kısa bir toparlanmanın ardından yeni bir başarısızlık, nedenin hâlâ orada olduğu anlamına gelir, temizliğin başarısız olduğu değil. Üç önbellek ayrı olduğu için kullandığınız makineye uyan satırı seçin.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Ardından sentetik bir sorgu yerine özgün görevi yineleyin, çünkü kullanıcı için önemli olan görevin kendisidir. Bir kez yeniden bağlanın, böylece yeniden test kullanıcının gerçekte olacağı durumu kapsasın. Microsoft'un nslookup başvurusu sorgu bağımsız değişkenleri için saklanmaya değer sayfadır.

Adlar yalnızca bağlantı kesildikten sonra başarısız olursa, istemci önceki yapılandırmayı geri yüklemedi, bu bildirilmesi gereken bir yaşam döngüsü hatasıdır, değiştirilmesi gereken bir DNS sunucusu değil. Çalışan bir sorgu da bir sızıntı testi değildir, çünkü çıkış ülkesi hangi çözümleyicinin yanıtladığını söylemez.