Windows VPN'de yanlış DNS sunucusu: metrik, bağlama sırası veya son ek

Bir Windows istemcisi çalışan bir tünele, kurumsal çözümleyiciye sahip olup yine de iç adları ev yönlendiricisine gönderebilir. Hangi sunucunun yanıt vereceğine üç farklı mekanizma karar verir ve bunlar farklı şekillerde başarısız olur. Üçünü birden düzeltmek zorunda değilsiniz: belirti hangisinin işin içinde olduğunu söyler. Aşağıdaki karar ağacı birkaç dakika sürer ve metrik değişikliği, kayıt defteri yeniden sıralaması ve NRPT kuralının birlikte geldiği ve kimsenin hangisinin ne yaptığını bilmediği olağan sonucu önler.

Üç mekanizma karar verir ve genellikle biri yanlıştır

Arabirim metriği, belirli bir adres ailesi için bağdaştırıcıları sıralar. Tcpip\Linkage altındaki bağlama sırası, eski kod yollarının hâlâ başvurduğu makine genelinde arabirim tanımlayıcıları listesidir. Ad Çözümleme İlkesi Tablosu (NRPT) bir ad alanını belirli sunuculara bağlar ve son ek listesi kısa bir adın genişletilip genişletilmeyeceğine karar verir. Bunlar bağımsızdır, bu yüzden VPN bağdaştırıcısındaki doğru çözümleyici başka bir yerdeki eski bir tercihe yenilir.

Bu mekanizmaların hiçbiri tünelin karşı tarafı değildir. VPN'in ittiği sunucu adı çözemiyorsa, istemci tarafındaki her ayar sadece süstür, dolayısıyla ilk karar çözümleyicinin kendisinin doğrudan sorulduğunda yanıt verip veremeyeceğidir.

Birinci karar: itilen çözümleyici hiç yanıt verebiliyor mu?

Sunucuya açıkça sorun ve sıradan bir aramayla karşılaştırın. Yanıtlar arasındaki fark, seçim sorununu erişilebilirlik sorunundan ayırır ve burada en hızlı çatal budur:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Birincisi başarılı olur ve ikincisi başarısız olursa çözümleyici erişilebilirdir ve Windows kötü seçiyordur; aşağıdaki ad alanı ve sıra kararlarına gidin. Birincisi de başarısız olursa istemcide hiçbir şey yardımcı olmaz: UDP ve TCP 53'ün tünelden sunucuya ulaştığını, sunucudaki ana makine güvenlik duvarının havuzu düşürmediğini ve sunucunun kendi ileticilerinin sağlıklı olduğunu denetleyin.

Bu çatalda durun. Erişemediğiniz bir çözümleyiciye NRPT kuralı uygulamak aynı arızayı daha fazla geri alınacak yapılandırmayla verir ve gerçek kusuru yetkili görünen bir kuralın arkasına saklar.

İkinci karar: tek ad alanı mı, her sorgu mu?

Kapsam aracı belirler. Yalnızca kurumsal adlar başarısız olduğunda makineyi yeniden sıralamak yerine ad alanını bağlayın: NRPT kuralı o son eki tünelin çözümleyicisine gönderir ve gerisini rahat bırakır. Her arama etkilendiğinde, sorun küresel bağdaştırıcı tercihidir ve metrik başlanacak yerdir çünkü hiçbir sunucu ayarını değiştirmez.

Metriği her adres ailesi için, iki arabirimde de ayarlayın ve ardından sırayı doğrulayın:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

11'i yukarıdaki satırdaki tünel bağdaştırıcısının ifIndex değeriyle değiştirin; 11 LAN bağdaştırıcısıysa aynı komut yanlış yolu düşürür. Bunun yerine LAN bağdaştırıcısını yükseltmek aynı sıraya diğer taraftan ulaşır: netsh int ip set interface interface="Ethernet" metric=15 ve ikinci aile için netsh int ipv6 set interface interface="Ethernet" metric=15, çünkü int ip yalnızca IPv4'e dokunur.

Bağlama sırası ilk adım değil son çaredir. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage aygıt tanımlayıcılarının Bind listesini tutar ve tünel tanımlayıcısını öne taşımak hangi bağdaştırıcının önce sorulacağını gerçekten değiştirir, ancak bu, ad alanı başına kapsamı olmayan makine geneli bir kayıt defteri değeridir. Düzenlemeden önce dışa aktarın ve ardından tüneli yeniden bağlayın, böylece sıra istemcinin beklediği durumda geçerli olsun.

Tek bir ad alanı için daha dar aracı tercih edin:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Üçüncü karar: düzeltme yeniden bağlanmadan sonra da kalıyor mu?

Bir sonraki çevirmeli bağlantıya kadar çalışan metrik hiçbir zaman kaydedilmemişti. L2TP/IPsec ve diğer bağlantı profilleri bağlantı başladığında yeniden oluşturulur, bu yüzden kaydedilen değer telefon defteri girdisinde IpInterfaceMetric olarak yaşar, yalnızca canlı arabirimde değil. Bazı ortamlar o alanı tam da bu nedenle betikler; diğerleri tercihi bir yönetim ilkesinden iter ve uç noktayı rahat bırakır.

Önbellek ve kayıt ayrı bir katmandır. Bunları tünel kalktıktan sonra çalıştırmak eski girdileri düzeltir ve istemciyi yeniden kaydeder, ancak hiçbiri bağdaştırıcıyı yeniden sıralamaz:

ipconfig /registerdns
ipconfig /flushdns

Aynı katmanda bir kapama anahtarı vardır. Fiziksel bağdaştırıcıda dinamik kaydı kapatmak istemcinin VPN tarafındaki adresini yanlış ad altında duyurmasını engeller ve bu yukarıdaki yenilemeden farklı bir onarımdır.

IPv6 kararda kendi satırını hak eder. Fiziksel bağdaştırıcıda küresel IPv6 adresi varken tünel yalnızca IPv4 taşıyorsa, Windows ad çözümlemesi için tünelsiz yolu tercih edebilir. Bu aileyi ayrıca denetleyin, çünkü IPv4 için ayarlanmış bir metrik onun hakkında hiçbir şey söylemez:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

LAN bağdaştırıcısında IPv6'yı kapatmak o yolu ve onunla birlikte protokolü kaldırır; IPv6 arabirimindeki metrik değişikliği veya kurumsal ad alanı için bir NRPT kuralı aileyi korur ve tercihi düzeltir. Daha dar olanı seçin, o bağlantının IPv6 olmaması gerektiğine karar vermediyseniz.

Adlandırılmış kaynakla doğrulayın ve tek bir sahip tutun

Yalnızca bir sayfanın yüklenip yüklenmediğini değil, hangi kaynağın yürürlükte olduğunu bildiren araçlarla doğrulayın:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Ardından filtrelemeyi seçimden ayırın, çünkü bir uygulamanın içinden ikisi aynı görünür. OpenVPN'in block-outside-dns seçeneği diğer bağdaştırıcılarda 53 numaralı bağlantı noktasını engeller; çözümleyici seçmez. Artık her sorgu başarısız olursa bir filtre ulaşılabilen tek sunucuyu engelliyor olabilir; yapılandırılmış çözümleyici yok sayılıyorsa sıra veya ad alanı kuralı yanlıştır. İkisini birden değiştirmek engellenen sorguyla yok sayılan sorguyu ayırt edilemez kılar.

DNS ilkesi için tek bir sahip tutun: VPN profili, bir yönetim ilkesi veya bir NRPT kuralı, bunlardan ikisi değil. Kapatmadan önce:

• İtilen çözümleyici açıkça adlandırıldığında yanıt verir ve sıradan bir arama onu kullanır.
• Değiştirdiğiniz kural veya metrik, sorguları gerçekten taşıyan adres ailesini kapsar.
• Ayar bir bağlantı kopması ve yeniden bağlanmadan sonra da kalır ya da onu kayıtlı profile taşıdınız.
• Tam olarak bir mekanizma yetkilidir ve diğerleri oldukları gibi bırakılmıştır.

Sırayı bitirilecek bir şey değil çevre durumu olarak ele alın. Yeniden bağlanmadan sonra ve ağ yığınına dokunan bir Windows güncellemesinden sonra yeniden denetleyin, çünkü ikisinden biri fiziksel bağdaştırıcıyı yine öne getirebilir.