VPN DNS'i devraldı ve yerel adları bozdu: listeyi düzeltin

Tünel açılıyor, intranet yükleniyor ve yazıcının adı çözümlenmemeye başlıyor. Ya da tersi: yerel adlar hâlâ çalışırken kurumsal ağın içindeki her şey zaman aşımına uğruyor. İki belirti de aynı yerden geliyor, VPN istemcisinin bağlanırken yeniden yazdığı çözücü listesi.

Listeyi bilerek düzeltin, sonra push mekanizmasını ayrı ele alın. Rotalar üçüncü bir konu ve burada düzeltilen şey o değil.

Uygulamaların gerçekte hangi listeyi kullandığı

Windows, bir iletişim kutusunun gösterdiğinden değil, arayüz düzeyindeki ayarlardan çözümler, bu yüzden her arayüzün etkin listeleriyle başlayın. Takma ad, görünen addan daha önemli, çünkü aşağıdaki her komut bir arayüze hitap eder. Takma adı karıştırırsanız düzeltme yanlış bağdaştırıcıya iner. Bir sonraki yeniden bağlanmaya kadar çalışıyor gibi görünür, o zaman tünelin kendi girdisi geri döner.

Soru, hangi sunucuların öne geçtiği ve statik girdi olarak mı yoksa DHCP kiralaması olarak mı geldikleri. İki gerçek de hangi düzeltmenin elinizde olduğunu belirler.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Tünel bağdaştırıcısı ve fiziksel bağdaştırıcı için çıktıyı okuyun ve her birindeki her adresi not edin. Statik bir girdi bir ilke veya betikle kaldırılabilir; DHCP'nin sağladığı girdi kiralamaya bağlıdır ve geri gelir, bu da seçmeniz gereken düzeltmeyi değiştirir. Uzak ağdaki adları duyurulan çözücü, yerel LAN'daki adları fiziksel bağdaştırıcı çözer ve sorgu ilk bakılan listeye gider.

İtilen sunucuları kaldırın veya daha aşağıya yerleştirin

Tünelin içinde hiçbir şey onlara gereksinim duymuyorsa itilen sunucuları silin, çünkü fiziksel bağdaştırıcının kendi çözücüleri yeniden devralır. Yalnızca uzak ağın yalnızca kendi sunucularının yanıtlayabildiği bölgeleri varsa onları tutun ve bu durumda önlerine yerel bir çözücü koyun. Aşağıdaki iki komut iki seçeneği de kapsar, bu yüzden ikisini de çalıştırmak yerine duruma uygun olanı seçin.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

1 numaralı dizin ilk bakılan olduğu için itilen adresler erişilebilir kalır ama her sorgunun varsayılan yanıtı olmaktan çıkar. validate=no bayrağı, tünel henüz otururken sık sık başarısız olan bir erişilebilirlik testini atlar, bu yüzden çıkış koduna güvenmek yerine show komutuyla sonucu doğrulayın.

Buna güvenmeden önce iki sınırı bilmekte yarar var. Windows, DHCP ile netsh üzerinden gelen sunucuları silmez ve bu değerler arayüzün kayıt defteri anahtarı altında DhcpNameServer olarak kalır, bu yüzden kayıt defteri düzenlemesi sonraki kiralamadan sonra yeniden denetlenmesi gereken son çaredir. Bağdaştırıcı bağlama sırası da güvenilir bir sıralama mekanizması değildir, çünkü bir VPN istemcisi kendi girdisini listenin en üstüne ekleyebilir.

Push nerede süzülebilir

Daha iyi bir düzeltme seçeneği uygulanmadan önce ortadan kaldırır. Community OpenVPN istemcisi itilen bir direktifi ada göre süzebilir, bu da sunucunun yapılandırmasını dokunulmamış bırakır.

pull-filter ignore "dhcp-option DNS "

Sondaki boşluk eşleşmeye aittir ve süzgeç sunucu adresini değil seçeneği adlandırır. Profilde ayrıca block-outside-dns direktifi varsa, onu kaldırmak ad çözümlemesini değil sızıntı korumasını değiştirir, bu yüzden iki düzenlemeyi birleştirmek yerine bunu ayrı olarak kararlaştırın.

İnatçı tek bir ana makine adı için Windows hosts dosyasındaki bir satır, tüm makine için çözücüleri yeniden sıralamaktan daha kararlıdır. Bir sonraki kişi için görünmez de olduğundan, makinenin yapılandırmasının belgelendiği yere not edin.

Düzeltmeyi yeniden bağlanmaya dayanıklı kılın

Ad çözümlemesi iki kez sınanmalı, bir kez seçilen bir sunucuya karşı, bir kez de bir uygulamanın kullandığı biçimde. Bu çift, çözücü sırası sorununu hiç yanıt vermeyen bir sunucudan ayırır. İlk testi atlamak iki nedeni birbirine dolaşmış bırakır.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Tüneli yeniden bağlayın ve iki komutu yineleyin. Elle değiştirdikleriniz yalnızca bir sonraki bağlantıya kadar dayanır, çünkü istemci bağdaştırıcıyı kaldırırken çözücü durumunu yeniden kurar. netsh satırlarını istemcinizin desteklenen bağlantı betiğine koyun, o betiğin başarıyla bitmesine izin verin ve çalışmasından önce kısa bir bekleme ekleyin. Betikten sonra DNS uygulayan bir istemci sonucu ne olursa olsun üzerine yazar.

Düzeltmeden sonra ortak adlar çözülüyor ama iç adlar hâlâ başarısız oluyorsa, çözücü listesi artık şüpheli değildir. Sorgu büyük olasılıkla sunucuya hiç ulaşmıyor, bu başka bir DNS ayarını değil yönlendirmeyi veya bir güvenlik duvarı kuralını işaret eder. Arayüzün takma adını ve vardığınız adresleri not edin, çünkü ikisi de makineler arasında değişir ve hiçbiri tek başına yeniden kurulumu atlatamaz.