VPN Bağlantısı, DNS'in yanlış DNS sunucusu kullanmasına neden oluyor

17

Şirket ağımızda (Active Directory'nin bir üyesi olan) bir Windows 7 bilgisayarım var. Bir müşterinin sitesine bir VPN bağlantısı açana kadar her şey yolunda gidiyor.

Bağlandığımda, klasör yeniden yönlendirme politikamız olan 'Uygulama Verileri' gibi dizinler de dahil olmak üzere ağdaki paylaşımlara ağ erişimini kaybediyorum. Tahmin edebileceğiniz gibi, PC'de çalışmayı çok zorlaştırıyor, masaüstü kısayolları çalışmayı durdurduğundan, 'Uygulama Verileri'nin altından çekilmesi nedeniyle yazılım düzgün çalışmıyor.

Ağımız 10.58.0.0/16 kapsamında mevcut olan diğer yerel alt ağlarla yönlendirilir (10.58.5.0/24). Uzak ağ 192.168.0.0/24 üzerinde.

Sorunu DNS ile ilgili olarak takip ettim. VPN tünelini açtığımda, tüm DNS trafiğim yerel ağın kaybını açıklayan uzak ağdan geçiyor, ancak sorum şu: Yerel DNS sorgularını müşterilerimiz yerine yerel DNS sunucularımıza gitmeye nasıl zorlayabilirim? ?

ipconfig /allVPN'ye bağlanmadığında çıkışı aşağıdadır:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Bu, VPN tüneli bağlıyken aynı komutun çıktısıdır:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

PPP adapter Customer Domain:

   Connection-specific DNS Suffix  . : customerdomain.com
   Description . . . . . . . . . . . : CustomerDomain
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.0.16
                                       192.168.0.17
   Primary WINS Server . . . . . . . : 192.168.0.17
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Yönlendirme tablosu

Ağ Hedef Ağ Maskesi Ağ Geçidi Arabirimi Metriği

          0.0.0.0          0.0.0.0        10.58.5.1       10.58.5.89     20
        10.58.5.0    255.255.255.0         On-link        10.58.5.89    276
       10.58.5.89  255.255.255.255         On-link        10.58.5.89    276
      10.58.5.255  255.255.255.255         On-link        10.58.5.89    276
    91.194.153.42  255.255.255.255        10.58.5.1       10.58.5.89     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0     192.168.0.95     192.168.0.85     21
     192.168.0.85  255.255.255.255         On-link      192.168.0.85    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.58.5.89    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.85    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.58.5.89    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.85    276

Arayüzler için bağlanma sırası aşağıdaki gibidir:

resim açıklamasını buraya girin

VPN tünelini uzak uçtaki varsayılan ağ geçidini kullanacak şekilde yapılandırmadım ve her iki ağdaki düğümlere ağ iletişimi iyi. (yani ağımızdaki veya uzaktaki ağımızdaki herhangi bir düğüme ping atabilirim).

Ben DNS sunucularını kullanmak için PPTP bağlantı özelliklerini modifiye ettik 10.58.3.32ardından 192.168.0.16, henüz sorgu hala 192.168.0.16 gider.

Düzenle:

Kaybolan yerel kaynaklar, ilgili olabilecek (veya olmayabilecek) etki alanı DFS köklerinde barındırılır.

Diğer Düzenlemeler:

Bu yalnızca etki alanı DFS köklerini etkiliyor gibi görünüyor. Paylaşıma sunucu adı üzerinden (yani \\server\shareyerine \\dfsroot\share) başvurursam, paylaşımlara erişebilirim.

Karşı benim yorumum gereğince bu cevap , ben kaybolan benim (DFS) ağ sürücüleri durur benim hosts dosyasına etki alanının DNS adını ekleyebilir buldum, ancak yukarıda sorumu cesur parçası (gibi hala ediyorum ) herhangi bir fikri varsa cevaplamak.

— Bryan
kaynak

Hangi güvenlik duvarını kullandığınızdan hiç bahsetmediniz mi? Bu oldukça önemli bir faktör IMO, bence bu sorunun cevabını potansiyel olarak bulacağınız yer.

— Hanny

@hanny güvenlik duvarı her iki sitedeki ADSL modemlerinde ağ adresi çevirisi ile sağlanır. Gerçekten gerekiyorsa muhtemelen model numaraları sağlayabilirim, ancak sadece bataklık standart ADSL NATing modemleri olacaklar. Entegre DNS'li AD hakkında konuştuğumuz göz önüne alındığında, sorunlar tamamen DNS olduğundan, bu cihazları alakalı bulmuyorum.

— Bryan

VPN, güvenlik duvarı tarafından ele alınmıyorsa, ancak Windows, o zaman içinde çalışmak için farklı bir parametre gönderdi, çünkü Windows VPN benim deneyimimde oldukça sınırlıdır. Örneğin bir ASA 5505 - bölünmüş tünel ile sorun gidermek gerçekten kolay bir şeydir ve özellikle DNS sorunları ve DNS atama konusunda yapılabilecek çok sayıda yapılandırma vardır. Bu yüzden sordum, açıkladığın için teşekkürler.

— Hanny

Lütfen gönderiye bir route print(vpn-bağlantısından) ekleyebilir misiniz ?

— florianb

Yönlendirme konusunda yanlış bir şey yok, çünkü IP üzerinden bağlanabiliyor, ancak DNS üzerinden bağlanamıyor

— MichelZ

12

Tamam, burada harika bir kaynak buldu: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

Mükemmel değil, ama işe yarayabilir.

Bağlayıcı sırası aşağıdaki konumda kayıt defterinde depolanır: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. Liste, ağ bağdaştırıcıları ve etkin bağlantılar için tüm aygıt GUID'lerini ciltleme önceliği sırasında içerir.

Kayıt defteri anahtarıyla çalışırken aşağıdaki gerçekler ortaya çıkar:

Kayıt defterindeki GUID'lerin sırasını değiştirmek, VPN bağlantıları da dahil olmak üzere ciltleme sırasını etkiler

Anahtarda yapılan değişiklikler hemen yürürlüğe girer

Bir VPN bağlantısı tamamlandığında, bağlantının GUID'si henüz yoksa bağlanma sırasının üstüne eklenir

Bir VPN bağlantısı kapatıldığında, bağlantının GUID girişi kaldırılır

Bağlantı için birden fazla GUID girişi varsa, bağlantı kapatıldığında yalnızca bir GUID girişi kaldırılır

Bu mekanizma aşağıdaki geçici çözüm olasılığını yaratır:

Bind kayıt defteri anahtarını inceleyin

VPN bağlantınıza bağlanın

Bağlama tuşunu tekrar kontrol edin ve listenin en üstüne eklenen GUID'i kopyalayın

GUID girişini listenin en altına 20 kez yapıştırın

Anahtarı dışa aktarın ve dışa aktarılan dosyayı yalnızca bağlama anahtarını içerecek şekilde temizleyin

Sonuç, istenen davranışı destekleyecek bir anahtardır. Her VPN bağlantısı kurulduğunda, GUID mevcut olduğundan eklenmeyecektir. GUID en altta olduğundan, DNS çözümlemesi istemciye yerel olarak yapılacaktır. Bağlantı kesildiğinde, bir GUID girişi kaldırılır. 20 VPN bağlantısından sonra, dışa aktarılan kayıt defteri dosyası anahtarı yeniden içe aktarmak için kullanılabilir.

Tabii ki, anahtarı yeniden içe aktarma sıklığınızı azaltmak için GUID'i daha fazla yapıştırabilirsiniz.

Ağ bağdaştırıcılarında herhangi bir değişiklik varsa bu yordamı yeniden yapmayı unutmayın.

— ZnArK
kaynak

İyi bulmak. Bu çok iyi çalışıyor, her önyükleme kayıt defteri anahtarının değerini sıfırlamak için bir bilgisayar başlatma komut dosyası ile birleştiğinde, ilk etapta neyin sorun olmaması gerektiğine dair büyük bir çözüm olmalıdır. Çok teşekkürler. Bunu biraz daha test edeceğim.

— Bryan

3

Zamanlanmış bir görev oluşturmanızı öneririm. VPN bağlantı kesme olayına karşılık gelen olay kimliği 20226'yı izleyin. Ardından powershell -File c:\scripts\fixdnsbind.ps1, aşağıdakileri içeren küçük bir powershell betiği ( ) kullanın

$val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind;  $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}";  Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind

. (adaptör kimliğini uyarlamayı unutmayın). VPN'ye bağlanmadan önce bu komut dosyasını da bir kez çalıştırırsınız.

— Steve B

4

Bana öyle geliyor ki, VPN tüneli, DNS trafiğini VPN DNS sunucularına yönlendiren yerel alan arabirimine bir şekilde öncelik veriyor (bu sunuculara erişiminiz varsa bu davranışı doğrulamak veya bu davranışı doğrulamak için bu sunucudaki isteği kontrol edebilirsiniz. sen).

Tamamen açıklayamıyorum, çünkü bağlayıcı düzen farklı gösteriyor. Bu yazıya göre (daha yüksek puanlama cevabına bakın) Windows bu konuda farklı bir algıya sahiptir, bağdaştırıcı bağlama sırasındaki bağlantı hızına bağlı olarak daha yüksek öncelikli bir kanal seçer. Bu nedenle, test etmek için bu otomatik davranışı değiştirmek için aşağıdakileri deneyin: 1) Ağ bağlantılarına gidin ve her biri için 2) IP v4 özellikleri yapın 3) Gelişmiş 4) "Otomatik Metrik" i devre dışı bırakın 5) Yereliniz için manuel olarak 1 metrik koyun bağlantısı ve VPN bağlantınızda (PPP) 2 metrik. Bu şekilde, uzak DNS yerine tercih edilen şekilde yerel DNS sunucularına giden yolu zorlar.

Bu yardımcı olur umarım!

— ank
kaynak

İlginç, yukarıdaki yönlendirme tabloma bakıldığında, LAN arabirimindeki metrik en düşük (20), VPN bağlantısının metriği 21. Söyledikten sonra, bu sorunun biraz aralıklı ve yukarıda gösterildiği gibi yönlendirme tablosu ile , her şey şu anda doğru çalışıyor. Sorunu yeniden oluşturmaya çalışacağım ve yönlendirme tablosunu tekrar kontrol edeceğim.

— Bryan

Güncelleme, sadece tüneli yeniden açtım ve sürücülerle olan tüm bağlantılarım düştü, ancak yönlendirme tablosu yukarıdakinden farklı değil. yani LAN için Metric 20, VPN için Metric 21.

— Bryan

1

@Bryan, bu Microsoft makalesi ( support.microsoft.com/kb/299540 ), bir tür, yukarıda söylediğimi doğrular. Zamanınız olduğunda yukarıda yazdığım prosedürü uygularsanız ne olacağını görmek ilginç olurdu. Diğerleri, gördüğünüz kesin aralıklı sorunları bildirmiş ve metrikleri sıkı bir şekilde kablolayarak çözmüştür ( serverfault.com/questions/70792/… ). Ne yazık ki şu anda bazı testler yapmak için benzer bir kurulum yok.

— ank

Bu @ank için çok teşekkür ederim, kesinlikle önümüzdeki hafta ofise döndüğümde bir şans vereceğim. İlginç makale BTW. Teşekkürler.

— Bryan

1

Benim için hile yaptı! NIC için IPv4 ayarlarındaki metriğin yönlendirme tablosundaki metrikle bir ilgisi yok gibi görünüyor! ZnArK'ın yazdığı gibi HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind'deki GUID sırasını değiştirmek, NIC / DNS'in kullanıldığı hiçbir şeyi değiştirmedi. Bu, Windows 10'da test edildi

— MrCalvin

4

Belirtildiği gibi, bu bölünmüş bir tünel sorunudur.

Üç düzeltme, # 2'yi öneriyor çünkü VMware Workstation 8 ile iyi bir kutu kullanıyorsanız kolay ve iyi bir performansa sahip olacak

1 - Bölünmüş tünel oluşturmayı etkinleştirin - güvensizdir ve müşterinin tarafında çalışmayı gerektirebilir. Olması muhtemel değil, BT güvenlik gestapo sizi kapatacak.

2 - Sanallaştırılmış masaüstü yaklaşımı - Mevcut masaüstünüzü P2V yapın ve bir VM'ye dönüştürün. İstemciye VPN'den VM'ye kullanın. Masaüstünüzü korursunuz ve gerektiğinde masaüstüne girip çıkabilirsiniz.

3 - Sanallaştırılmış sunucu yaklaşımı - Mevcut masaüstünüzü P2V yapın ve bir VM'ye dönüştürün, ardından ESXi'nin ücretsiz bir sürümüne koyun. Masaüstünüzü korursunuz ve gerektiğinde bir konsol aracılığıyla VM'ye geçebilirsiniz. Bu yavaş olabilir ...

— Brennan
kaynak

+ 1; Görev için özel bir sanallaştırılmış sisteme sahip olma fikrini seviyorum, ancak çeşitli nedenlerle bu noktada burada iyi çalıştığını görmüyorum. Bu kesinlikle gelecekte iyi bir çözüm olacaktır. Teşekkürler.

— Bryan

3

Ne yazık ki, Windows VPN "Split-DNS" yapamaz. Ancak uzak siteye bağlandıktan sonra DNS Sunucusunu VPN bağlantısından kaldırabilirsiniz.

Bunu aşağıdakileri yaparak yapabilirsiniz:

Silme dnsservers adı ipv4 netsh interface = " VPN adı adresi" = tüm validate = hayır

VPN Ağına her bağlandığınızda bunu yapmanız gerekir.

— MichelZ
kaynak

FYI ... bu, Uzak (VPN) DNS'yi kullanmanızı engeller.

— MichelZ

Sorun şu ki, tünel yükseldiğinde, sorumu açıkladığım problemden zaten muzdaripim, bu yüzden komut çok geç olacak. Ayrıca, bunu denedikten sonra, komut aslında herhangi bir fark yaratmıyor ( nslookupyine de uzak DNS sunucusunu kullanıyor ve yine de uzak DNS sunucusunu ipconfiglisteliyor). VPN tünel bağlantısının kendi dahili DNS ayarlarımı kullanması için DNS ayarlarını da düzenledim, ancak bu yok sayıldı, tüm DNS trafiğim hala uzak DNS sunucusuna gidiyor gibi görünüyor.

— Bryan

1

Ben aynı sorunu vardı, ben denedim ve burada çalıştı. " VPN'nin adını " ayarladınız mı ? Ayrıca, çoğunlukla bu endişe eğer bir bilgisayarlarınızın dosyasında ekleyin ve hiçbir şey onu geçersiz kılmak mümkün olacak, sizin sürücüler bağlı sunucuya

— MichelZ

Teşekkürler, adı değiştirmeyi denedim ( ipconfigçıktıdan kesip yapıştırın ve yanlış yaptığımda hatayı aldım The filename, directory name, or volume label syntax is incorrect), bu yüzden komutu doğru aldığımdan eminim. Uzak PPTP sunucusunda DNS ayarını geçersiz kılmama izin vermeyen bir şey olabilir. Ben araştıracağım, ancak hosts dosya girişi fikrini seviyorum. Ben buna bir izin vereceğim. Soruya ilişkin düzenlememi de inceleyin.

— Bryan

Komutu tekrar denedim ve DNS Sunucusunu PPP bağlantısından kaldırdı. İle doğrulayabilir misiniz ipconfig /all? Ancak ana giriş sizin için bu en kolay düzeltme olmalıdır düşünüyorum.

— MichelZ

2

VPN tüneliniz istemci ile istemci ağı arasında. Tünel açıkken kendi ağınızdaki kaynaklara erişmenizi engelleyecek bölünmüş tünel kullanmıyor gibi görünüyor.

Bu nedenle, sizin (veya müşterinizin) bölünmüş tünellemeyi etkinleştirmeniz ya da her iki ağa aynı anda erişmek için fazladan bir ağ bağlantısına ve özelleştirilmiş rota tablosuna ihtiyacınız var.

— dunxd
kaynak

Bilgi için, tünel açıkken ağ kaynaklarına erişebilirim, sadece DNS çözünürlüğü kırılıyor gibi görünüyor. split tunnellingDürüst olmak gerekirse terime aşina değildim , ancak söyleyebildiğim kadarıyla, uzak sitedeki varsayılan ağ geçidini kullanmamaya izin vermeyi içeriyor, bu da bana belirtmeme rağmen zaten yapıyorum. Yanıtınız için teşekkürler, sorumu bunu yansıtacak şekilde düzenleyeceğim.

— Bryan

1

Bu durumda, müşterinin VPN'si bölünmüş DNS için ayarlanmamış gibi görünür. Bölünmüş DNS ile VPN yoğunlaştırıcı, VPN istemcinize (şu anda olduğu gibi) bir DNS sunucuları listesi ve ayrıca bu DNS sunucularıyla kullanılması gereken tek etki alanları olan etki alanlarının bir listesini verir; diğerleri sisteminizin varsayılan DNS'sini kullanır.

— James Sneeringer

0

Bu soru çok uzun zaman önce sorulmuş olsa da, bu yanıtı başkalarına yardımcı olabilir. VPN ile aynı sorunu yaşadım, kullanıcılar uzak VPN'ye bağlandıklarında harici dns'leri durmak için kullandılar. google.comlistelenen yalnızca şirket etki alanları kullanılır split-dns.

Sorun kullanılan yerel makine yapmak dns sorgu trafiği vpn tüneline gider ve tünelde dns izin verilirse geri düşer. Geri dönüşte, önce çözünürlük olarak ipv6'yı seçmek ve daha sonra asla ipv4'e geri dönmek için kullanılır.

Sonuçları test etmek için önce yerel makinede ipv6'yı devre dışı bıraktık ve çalışmaya başladı. Etkinleştirdiğimiz tüm kullanıcılar için kalıcı olarak düzeltmek içinclient-bypass-protocol , vpn havuzlarında yapılandırılmamışsa IPv6'yı yok sayan ASA güvenlik duvarında komutu .

Bu nedenle, güvenlik duvarını kontrol edemez ve bölünmüş tünel ve bölünmüş dns'in yerinde olduğunu bilmiyorsanız, ipv6yerel makinede devre dışı bırakmayı deneyebilirsiniz ve eğer kontrol edebiliyorsanız ipv6 kullanmadığınız sürece yukarıdaki komutu etkinleştirebilirsiniz uzak ağınızda.

Bu bana yardımcı oldu, umarım bu başkalarına yardımcı olur :)

— Rsingh
kaynak

0

Yaşadığım bir şey yay!

Yerel DNS sunucusuyla VPN bağlantısını ayarlayın ve VPN etki alanı adını sorgulamak için nslookup kullanılan VPN'ye bağlanın. VPN LAN için yerel olan bir IP ile yanıt almalısınız. Bu, sorguyu çözmek için VPN DNS sunucularını kullandığınız anlamına gelir.

Şimdi LAN bağlantınızı açın ve DNS'yi yerel veya ISS DNS'nize manuel olarak ayarlayın. bir Volia !!! ok tuşunu kullanın ve nslookup sorgusunu tekrarlayın. VPN etki alanının sorgusunu çözmek için yerel / ISS DNS sunucunuzu kullandığınız anlamına gelen genel bir IP alacaksınız. Bam !!!!

— Graham.Fraser
kaynak

0

Bu seçeneği istemci VPN yapılandırmasından kaldırıyorum

setenv opt block-outside-dns

Sorunu çözdü

— İsmail
kaynak

0

Birkaç yıl önce bu sorunu yaşadım ve VPN bağlantı dosyasını düzenleyerek düzeltildi, sadece bir vpn.pbk dosyası yapın (google'da bulabilirsiniz) bu dosyayı not defteri gibi metin düzenleyicisi aracılığıyla açın ve UseRasCredentials değerini sıfıra değiştirin ve sorun çözüldü. ancak tek sorun yerel alan bağlantılarınızdır DNS önceliği VPN DNS'den daha yüksek olur ve ad çözümlemesi daha fazla zaman alır (VPN internete bağlanmak için kullanılıyorsa).

— Mohsen Bigdeli
kaynak

-1

Neden DNS olduğunu düşünüyorsunuz?

VPN'ye bağlandığınızda ağ paylaşımlarınıza erişiminizi kaybederseniz, neredeyse kesinlikle makinenizin WINS / NETBIOS ile zorluk çektiği görülüyor.

Bir WINS sunucusu tanımlayın ve tekrar test edin.

— Ben Lessani - Sonassi
kaynak

Sorunlarımın nedeni bu olduğundan emin değilim, ancak bildiğim şey, AD istemcilerinin AD'yi barındırmak için kullanılan DNS sunucularını kullanması gerektiğidir ve durum böyle değildir. Sorun yalnızca bir VPN bağlantısı kurduğumda ortaya çıktığından ve DNS çözünürlüğüm aynı anda berbat olduğundan, DNS olası aday gibi görünüyor. Ne olursa olsun, VPN kullanarak başka bir ağa bağlandığımda uzak DNS sunucusunu kullanmak istemiyorum.

— Bryan

Benim önerime göre bir WINS sunucusu tanımladınız mı? Devre dışı bırakılmış olduğunu belirttiğiniz veya "Uzak ağ geçidini kullan ayarlı" olmadığı sürece DNS sunucusunu bir VPN'de kullanmak tipik bir Windows değildir. Ayrıca VPN tünelinde statik bir IP kullanıyorsunuz, neden DNS girişlerini ayarladınız? Bu DNS sunucularını (192.168.0.16-17) kaldırın veya bir WINS sunucusu ayarlayın.

— Ben Lessani - Sonassi

Hayır, istemcileri işaret edecek bir WINS sunucumuz olmadığından bunu denemedim. WINS'in dürüst olmaya yardımcı olacağına ikna olmadım, bu yüzden ağımıza bir WINS sunucusu yüklemeye hevesli değilim çünkü yardımcı olabilir . Fikri kesinlikle aklımda tutacağım, bu yüzden teşekkürler. IP, VPN sunucusu tarafından atanır ve dinamiktir. VPN bağlantısı için bir DNS sunucusu atamazsam, sunucu tarafından dinamik olarak atanır. VPN bağlantı özelliklerinde kendi DNS sunucularımı bile kodladım, ancak yine de uzak sitedeki DNS sunucularını kullanıyor.

— Bryan

Ben gereğini yok ne de şimdiye kadar, hep DNS çözümlemesi yerel sunucuda yapılmasını istiyoruz, uzaktan DNS sunucusunu kullanmak istiyorum, bu olacak dolayısıyla benim sorum DNS odaklanarak, benim sorunu çözmek. Muhtemelen uzak DNS sunucusuna erişimi engellemek için bir güvenlik duvarı kuralı kullanabilirim, ancak bu temel yanlış yapılandırma sorununu çözmez.

— Bryan

1

bunu yorumlamanız yanlış. IP adresi, gerçekte DHCP kullanmayan PPTP sunucusu tarafından atanır. PPTP sunucusunun ayırabileceği bir havuzu var, ancak bu DHCP değil . Ancak her bağlandığımda farklı bir IP alıyorum. Ayrıca, yönlendirme tablosundan açıkça görebileceğiniz gibi, uzak ağ geçidini kullanmak için kutuyu işaretlemedim.

— Bryan