Windows VPN DNS sızıntısı: metrik neden yolu yener

Bir sorgu makineden çıkıp ev yönlendiricisine ulaşırken her paket tünellenir. Doğal sonuç eksik bir yoldur ve yol genellikle iyidir. Windows, arayüz metriğine göre hangi arayüzün çözümleyicisine sorulacağını seçebilir ve tünel bağdaştırıcısı bu karşılaştırmayı kablosuza karşı sık sık kaybeder.

Bir sızıntı için iki açıklama

Yol açıklaması, trafiğin bir kısmının tünelden kaçtığını söyler, dolayısıyla varsayılan yol ya da bölünmüş tünel listesi yanlış olmalıdır. Bu açıklama tek bir komutla sınanabilir ve varsayılan yol tünelin içini gösteriyorsa iş bitmiştir. Ucuz olduğu için önce bunu denetleyin, temiz döndüğünde de bir kenara bırakın.

Sıralama açıklaması, trafiğin tamamen tünelde olduğunu ve aramanın yine de başka bir çözümleyiciye gönderildiğini söyler. Windows çözümleyici seçimini sırası olan bir arayüz özelliği olarak ele alır, bu yüzden daha iyi metriğe sahip fiziksel bir bağdaştırıcı, çözülen adrese giden paketler tünelden geçse bile bir ad için DNS sağlayabilir. İki açıklama da sızıntı testi sayfasında aynı belirtiyi üretir, bu yüzden test tanı değildir. Yalnızca biri yollar düzenlenerek onarılır.

Metrikleri ve çözümleyicileri birlikte karşılaştırın

Tünel açıkken arayüzleri, metriklerini ve yapılandırılmış sunucuları kaydedin. Bunları iki ayrı liste olarak değil, bir tablo olarak okuyun, çünkü soru hangi çözümleyicinin önce geldiğidir, hangi çözümleyicilerin var olduğu değil.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Tünel bağdaştırıcısı fiziksel bağdaştırıcıdan daha yüksek bir sayı taşıyorsa çözümleyicisi tercih edilmez ve iç ad, fiziksel tarafın sunduğu yere gider. O yönlendirici önbellekten yanıt verebilir, sorguyu iletebilir ya da reddedebilir ve bu sonuçların hiçbiri amaçladığınız tasarım değildir. Sıralama bir tercihtir, bu yüzden hata yükseltmek yerine sessizce kaybeder.

Hiç çözümleyici yapılandırılmamış bir tünel bağdaştırıcısı da aynı ölçüde yaygın bir varyanttır. İstemci arayüzü DNS itmeden kaldırır, bu yüzden sıralama sorusu hiç ortaya çıkmaz.

Tüneli yukarı taşıyıp yeniden denetleyin

Yükseltilmiş bir kabukta tünel arayüzüne en düşük metriği verin ya da fiziksel bağdaştırıcının değerini yükseltin. İkisi de arayüz başına ayardır ve ikisi de geri alınabilir; önünde oturmadığınız bir makineyi değiştirirken bu önemlidir.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Değişiklik hemen görünür, DNS istemcisi ve diğer tüketiciler zaten yaptıkları seçimi önbelleğe alır. Sorgu sonucundan bir şey okumadan önce tüneli yeniden bağlayın ya da yeniden başlatın. Çok erken çalıştırılan bir test eski davranışı yineler ve başarısız bir onarım gibi görünür.

Sonra bir iç ve bir genel ad sorun ve hangi sunucunun yanıtladığını denetleyin. Microsoft'un otomatik metrikler üzerine başvuru belgesi en düşük değerin neden tercih edildiğini ve otomatik atamanın nasıl türetildiğini açıklar.

Yeniden bağlanmaya dayanıklı hâle getirin

Her bağlantıda yeniden oluşturulan bir bağdaştırıcıdaki el ile verilmiş metrik, kaybolan bir ayardır. İstemci arayüzü yeniden kurarsa bu geçersiz kılma, bağlantı sonrası bir betik, bir ilke ya da bağlantı süresince DNS'i elinde tutan bir istemci yapılandırması gerektirir.

Fiziksel bağdaştırıcıda statik olarak yapılandırılmış sunucular aynı dayanıklılık sorununu tersine yaşar. Onlar kaldırılana kadar o arayüz için yanıt vermeye devam eder ve DHCP onları bir sonraki kiralamada yeniden doldurur, bu yüzden onları kaldırmak bir ölçümdür, tasarım değil. Dayanıklı tasarım iç ad alanı için bir ad çözümleme ilkesi ya da bağlantı süresi boyunca DNS'i devralan bir istemcidir. Her durumda, yeniden bağlanmadan önce ve sonra çözümleyici listesini kaydedin, testi bitirdiğinizde özgün metriği geri yükleyin ve önceki davranışın geri döndüğünü doğrulayın.