การเชื่อมต่อ VPN ทำให้ DNS ใช้เซิร์ฟเวอร์ DNS ไม่ถูกต้อง

17

ฉันมีพีซีที่ใช้ Windows 7 ในเครือข่าย บริษัท ของเรา (ซึ่งเป็นสมาชิกของ Active Directory ของเรา) ทุกอย่างทำงานได้ดีจนกระทั่งฉันเปิดการเชื่อมต่อ VPN ไปยังเว็บไซต์ของลูกค้า

เมื่อฉันเชื่อมต่อฉันจะสูญเสียการเข้าถึงเครือข่ายเพื่อแบ่งปันในเครือข่ายรวมถึงไดเรกทอรีเช่น 'ข้อมูลแอปพลิเคชัน' ที่เรามีนโยบายการเปลี่ยนเส้นทางโฟลเดอร์ อย่างที่คุณสามารถจินตนาการได้สิ่งนี้ทำให้การทำงานบนพีซีนั้นยากมากเนื่องจากทางลัดบนเดสก์ท็อปหยุดทำงานซอฟต์แวร์หยุดทำงานอย่างถูกต้องเนื่องจากดึง 'Application Data' ออกจากใต้

เครือข่ายของเราถูกกำหนดเส้นทาง (10.58.5.0/24) พร้อมเครือข่ายย่อยท้องถิ่นอื่น ๆ ที่มีอยู่ภายในขอบเขต 10.58.0.0/16 เครือข่ายระยะไกลอยู่ใน 192.168.0.0/24

ฉันติดตามปัญหาที่เกี่ยวข้องกับ DNS แล้ว ทันทีที่ฉันเปิดอุโมงค์ VPN การรับส่งข้อมูล DNS ของฉันทั้งหมดจะผ่านเครือข่ายระยะไกลซึ่งอธิบายถึงการสูญเสียทรัพยากรในท้องถิ่น แต่คำถามของฉันคือฉันจะบังคับให้แบบสอบถาม DNS ในเครื่องไปยังเซิร์ฟเวอร์ DNS ในพื้นที่ของเราได้อย่างไร ?

ผลลัพธ์ของipconfig /allเมื่อไม่ได้เชื่อมต่อกับ VPN อยู่ด้านล่าง:

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

นี่เป็นเอาต์พุตของคำสั่งเดียวกันที่เชื่อมต่อกับอุโมงค์ VPN:

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

ตารางเส้นทาง

เครือข่ายปลายทาง Netmask Gateway Interface Interface

          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

ลำดับการโยงสำหรับอินเตอร์เฟสมีดังต่อไปนี้:

ป้อนคำอธิบายรูปภาพที่นี่

ฉันไม่ได้กำหนดค่าอุโมงค์ VPN ให้ใช้เกตเวย์เริ่มต้นที่ปลายทางระยะไกลและเครือข่าย comms ไปยังโหนดในเครือข่ายทั้งสองก็ใช้ได้ (เช่นฉันสามารถ ping โหนดใดก็ได้ในเครือข่ายของเราหรือเครือข่ายระยะไกล)

ฉันได้แก้ไขคุณสมบัติการเชื่อมต่อ PPTP เพื่อใช้เซิร์ฟเวอร์ DNS ที่10.58.3.32ตามมา192.168.0.16แต่แบบสอบถามยังคงไปที่ 192.168.0.16

แก้ไข:

ทรัพยากรในท้องถิ่นที่หายไปถูกโฮสต์บนรูท DFS ของโดเมนซึ่งอาจ (หรืออาจจะไม่) มีความเกี่ยวข้อง

แก้ไขเพิ่มเติม:

ดูเหมือนว่าจะส่งผลกระทบต่อรากของ DFS ของโดเมนเท่านั้น หากฉันอ้างอิงการแชร์ผ่านชื่อเซิร์ฟเวอร์ (เช่น\\server\shareแทน\\dfsroot\share) ฉันสามารถเข้าถึงการแชร์ได้

จากความคิดเห็นของฉันที่มีต่อคำตอบนี้ฉันพบว่าฉันสามารถเพิ่มชื่อ DNS ของโดเมนลงในไฟล์โฮสต์ของฉันซึ่งหยุดไม่ให้ไดรฟ์เครือข่าย (DFS) ของฉันหายไป แต่ฉันก็ยังชอบส่วนที่เป็นตัวหนาของคำถามของฉัน (ด้านบน ) ตอบถ้าใครมีความคิดใด ๆ

— ไบรอัน
แหล่งที่มา

คุณไม่เคยพูดถึงไฟร์วอลล์ที่คุณใช้อยู่? นั่นเป็นปัจจัยสำคัญ IMO เพราะฉันคิดว่านั่นเป็นสิ่งที่คุณจะได้พบกับคำตอบของคำถามนี้

— Hanny

@hanny ไฟร์วอลล์ให้บริการโดยการแปลที่อยู่เครือข่ายในโมเด็ม ADSL ที่ทั้งสองเว็บไซต์ ฉันอาจจัดหาหมายเลขรุ่นได้ถ้าจำเป็นจริงๆ แต่พวกเขาจะเป็นโมเด็ม ADSL NATing มาตรฐาน เนื่องจากเรากำลังพูดถึงโฆษณาด้วย DNS รวมฉันไม่คิดว่าอุปกรณ์เหล่านี้มีความเกี่ยวข้องเนื่องจากปัญหาล้วนเป็น DNS

— ไบรอัน

หาก VPN ไม่ได้รับการจัดการโดยไฟร์วอลล์ แต่ Windows แสดงว่ามีการส่งพารามิเตอร์ต่าง ๆ เพื่อใช้งานภายในเนื่องจาก Windows VPN นั้นค่อนข้าง จำกัด ในประสบการณ์ของฉัน ตัวอย่างเช่นกับ ASA 5505 - การแยกช่องสัญญาณเป็นสิ่งที่ง่ายต่อการแก้ไขปัญหาและมีการกำหนดค่าที่สามารถทำได้โดยเฉพาะอย่างยิ่งเกี่ยวกับปัญหา DNS และการกำหนด DNS นั่นคือเหตุผลที่ฉันถามขอขอบคุณสำหรับการชี้แจง

— Hanny

คุณช่วยเพิ่ม a route print(จากการเชื่อมต่อ vpn) ลงในโพสต์ได้ไหม?

— florianb

ไม่มีอะไรผิดปกติกับการกำหนดเส้นทางในขณะที่เขาสามารถเชื่อมต่อกับรางน้ำ IP แต่ไม่ผ่านราง DNS

— MichelZ

12

ตกลงพบแหล่งข้อมูลที่ดีที่นี่: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

มันไม่สมบูรณ์แบบ แต่อาจใช้ได้

HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bindคำสั่งมีผลผูกพันจะถูกเก็บไว้ในรีจิสทรีในสถานที่ดังต่อไปนี้: รายการประกอบด้วย GUID ของอุปกรณ์ทั้งหมดสำหรับอะแดปเตอร์เครือข่ายและการเชื่อมต่อที่ใช้งานอยู่ในลำดับความสำคัญการรวม

เมื่อทำงานกับคีย์รีจิสตรีข้อมูลต่อไปนี้จะปรากฏ:

การเปลี่ยนลำดับของ GUID ในรีจิสทรีจะส่งผลต่อลำดับการเชื่อมรวมถึงการเชื่อมต่อ VPN

การเปลี่ยนแปลงคีย์จะมีผลทันที

เมื่อการเชื่อมต่อ VPN เสร็จสมบูรณ์ GUID สำหรับการเชื่อมต่อจะถูกเพิ่มไปด้านบนของลำดับการผูกหากยังไม่มี

เมื่อปิดการเชื่อมต่อ VPN รายการ GUID สำหรับการเชื่อมต่อจะถูกลบออก

หากมีรายการ GUID หลายรายการสำหรับการเชื่อมต่อจะมีเพียงรายการเดียวที่ถูกลบเมื่อการเชื่อมต่อถูกปิด

กลไกนี้สร้างความเป็นไปได้ของวิธีแก้ไขปัญหาต่อไปนี้:

ตรวจสอบการผูกรีจิสทรีคีย์

เชื่อมต่อกับการเชื่อมต่อ VPN ของคุณ

ตรวจสอบคีย์ Bind อีกครั้งและคัดลอก GUID ที่เพิ่มไว้ด้านบนของรายการ

วางรายการ GUID ที่ด้านล่างของรายการ 20 ครั้ง

ส่งออกคีย์และล้างไฟล์ที่ส่งออกเพื่อรวมคีย์ผูกเท่านั้น

ผลที่ได้คือกุญแจที่จะรองรับพฤติกรรมที่ต้องการ ทุกครั้งที่มีการสร้างการเชื่อมต่อ VPN เนื่องจากมี GUID อยู่จะไม่ถูกเพิ่ม เนื่องจาก GUID อยู่ด้านล่างการแก้ปัญหา DNS จะทำภายในเครื่องกับลูกค้า เมื่อการเชื่อมต่อถูกตัดการเชื่อมต่อรายการ GUID หนึ่งรายการจะถูกลบออก หลังจากการเชื่อมต่อ VPN 20 ครั้งไฟล์รีจิสตรีที่ส่งออกสามารถใช้เพื่อนำเข้าคีย์ได้อีกครั้ง

แน่นอนคุณสามารถวาง GUID ได้มากขึ้นเพื่อลดความถี่ที่คุณต้องนำเข้ากุญแจอีกครั้ง

สิ่งสำคัญที่ต้องจำไว้ว่าให้ทำซ้ำขั้นตอนนี้หากมีการเปลี่ยนแปลงใด ๆ กับอะแดปเตอร์เครือข่าย

— ZnArK
แหล่งที่มา

หาดี มันใช้งานได้ดีมากบวกกับคอมพิวเตอร์ที่เริ่มต้นสคริปต์เพื่อรีเซ็ตค่าของรีจิสตรีคีย์ในแต่ละการบู๊ต ขอบคุณมาก. ฉันจะให้การทดสอบเพิ่มเติมต่อไป

— ไบรอัน

3

ฉันขอแนะนำให้สร้างงานที่กำหนดเวลาไว้ ตรวจสอบเหตุการณ์ ID 20226 ซึ่งสอดคล้องกับเหตุการณ์ตัดการเชื่อมต่อ VPN แล้วไฟสคริปต์ PowerShell ขนาดเล็ก ( powershell -File c:\scripts\fixdnsbind.ps1)

$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

ที่มี: (อย่าลืมที่จะปรับ ID อะแดปเตอร์) คุณเรียกใช้สคริปต์นี้หนึ่งครั้งก่อนเชื่อมต่อกับ VPN

— Steve B

4

สำหรับฉันแล้วดูเหมือนว่าอุโมงค์ VPN จะมีความสำคัญเหนือกว่าอินเทอร์เฟซในพื้นที่ที่นำทราฟฟิก DNS ไปยังเซิร์ฟเวอร์ VPN DNS (คุณสามารถตรวจสอบคำขอบนเซิร์ฟเวอร์เหล่านี้เพื่อตรวจสอบพฤติกรรมนี้หากคุณมีสิทธิ์เข้าถึง คุณ).

ฉันไม่สามารถอธิบายได้ทั้งหมดเนื่องจากลำดับการเชื่อมโยงบ่งบอกถึงความแตกต่าง ตามโพสต์นี้ที่นี่ (ดูคำตอบให้คะแนนที่สูงขึ้น) Windows มีการรับรู้ที่แตกต่างกันเมื่อมันมาถึงการเลือกช่องทางลำดับความสำคัญที่สูงขึ้นขึ้นอยู่กับความเร็วของการเชื่อมต่อที่ไม่ได้ ดังนั้นเพื่อการทดสอบลองทำสิ่งต่อไปนี้เพื่อเปลี่ยนพฤติกรรมอัตโนมัตินี้: 1) ไปที่การเชื่อมต่อเครือข่ายและสำหรับแต่ละคนทำ 2) คุณสมบัติ IP v4 3) ขั้นสูง 4) ปิดการใช้งาน "เมตริกอัตโนมัติ" 5) ใส่เมตริก 1 สำหรับท้องถิ่นของคุณ การเชื่อมต่อและเมตริก 2 บนการเชื่อมต่อ VPN ของคุณ (PPP) ด้วยวิธีนี้จะเป็นการจัดเรียงฮาร์ดคอร์พา ธ ไปยังเซิร์ฟเวอร์ DNS โลคัลตามต้องการผ่านรีโมต DNS

หวังว่านี่จะช่วยได้!

— ank
แหล่งที่มา

น่าสนใจเมื่อดูตารางเส้นทางของฉันด้านบนตัวชี้วัดบนอินเทอร์เฟซ LAN ต่ำที่สุด (20) การเชื่อมต่อ VPN มีตัวชี้วัดที่ 21 กล่าวว่าปัญหานี้อาจไม่ต่อเนื่องบ้างและตารางเส้นทางดังที่แสดงด้านบน ทุกอย่างทำงานอย่างถูกต้อง ฉันจะลองสร้างปัญหาขึ้นมาใหม่และตรวจสอบตารางเส้นทาง

— ไบรอัน

อัปเดตเพิ่งเปิดอุโมงค์อีกครั้งและการเชื่อมต่อกับไดรฟ์ทั้งหมดของฉันลดลง แต่ตารางเส้นทางไม่ได้แตกต่างจากข้างบน เช่น Metric 20 สำหรับ LAN, Metric 21 สำหรับ VPN

— ไบรอัน

1

@Bryan บทความ Microsoft นี้ ( support.microsoft.com/kb/299540 ) เรียงลำดับตรวจสอบสิ่งที่ฉันพูดไว้ข้างต้น มันจะน่าสนใจที่จะเห็นสิ่งที่เกิดขึ้นถ้าคุณทำตามขั้นตอนที่ฉันเขียนไว้ข้างต้นเมื่อคุณมีเวลา คนอื่น ๆ รายงานปัญหาที่เกิดขึ้นเป็นระยะ ๆ ที่คุณเห็นและแก้ไขโดยการเดินสายเมตริกอย่างหนัก ( serverfault.com/questions/70792/… ) น่าเสียดายที่ฉันไม่มีการตั้งค่าที่คล้ายกันในการทดสอบ

— ank

ขอบคุณมากสำหรับ @ank ฉันจะให้มันอย่างแน่นอนในสัปดาห์หน้าเมื่อฉันกลับมาที่ออฟฟิศ บทความที่น่าสนใจ BTW ขอบคุณ

— ไบรอัน

1

มันเป็นการหลอกลวงสำหรับฉัน! เมทริกซ์ในการตั้งค่า IPv4 สำหรับ NIC ดูเหมือนจะไม่มีอะไรเกี่ยวข้องกับเมทริกซ์ในตารางเส้นทาง! การเปลี่ยนลำดับ GUID ใน HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind ตามที่ ZnArK เขียนเกี่ยวกับไม่ได้เปลี่ยนแปลงสิ่งใด ๆ เกี่ยวกับ NIC / DNS ที่ใช้ นี่คือการทดสอบใน Windows 10

— MrCalvin

4

ตามที่ระบุไว้นี่เป็นปัญหาการแยกช่องสัญญาณ

สามการแก้ไขแนะนำ # 2 เพราะง่ายและจะมีประสิทธิภาพที่ดีหากใช้กล่องที่ดีกับ VMware Workstation 8

1 - เปิดใช้งานการแยกอุโมงค์ - ไม่ปลอดภัยและอาจต้องทำงานกับฝั่งไคลเอ็นต์ ไม่น่าจะเกิดขึ้นการรักษาความปลอดภัยด้านไอทีจะปิดตัวคุณลง

2 - วิธีเดสก์ท็อปเสมือนจริง - P2V เดสก์ท็อปที่มีอยู่ของคุณและเปลี่ยนเป็น VM ใช้ VM เป็น VPN ไปยังไคลเอนต์ คุณเก็บเดสก์ท็อปของคุณและสามารถสลับเข้าและออกได้ตามต้องการ

3 - เซิร์ฟเวอร์เสมือน - P2V เดสก์ท็อปที่มีอยู่ของคุณและเปลี่ยนเป็น VM จากนั้นวางไว้บน ESXi เวอร์ชันฟรี คุณเก็บเดสก์ท็อปของคุณและสามารถสลับไปใช้ VM ได้ตามต้องการผ่านคอนโซล นี่อาจช้า ...

— เบรนแนน
แหล่งที่มา

+1; ฉันชอบความคิดในการมีระบบเวอร์ช่วลไลเซชั่นเฉพาะสำหรับงาน แต่ฉันไม่เห็นว่าการทำงานที่นี่ ณ เวลานี้ด้วยเหตุผลหลายประการ นี่จะเป็นทางออกที่ดีในอนาคต ขอบคุณ

— ไบรอัน

3

น่าเสียดายที่ Windows VPN ไม่สามารถทำ "แยก DNS" อย่างไรก็ตามคุณสามารถลบเซิร์ฟเวอร์ DNS ออกจากการเชื่อมต่อ VPN หลังจากที่คุณเชื่อมต่อกับไซต์ระยะไกล

คุณสามารถทำได้โดยการออก:

ส่วนต่อประสาน netsh ipv4 ลบชื่อ dnsservers = " ชื่อของ VPN " ที่อยู่ = ตรวจสอบความถูกต้องทั้งหมด = ไม่

คุณต้องทำสิ่งนี้ทุกครั้งที่คุณเชื่อมต่อกับเครือข่าย VPN

— MichelZ
แหล่งที่มา

FYI ... สิ่งนี้จะขัดขวางไม่ให้คุณใช้ DNS (VPN) ระยะไกล

— MichelZ

ปัญหาคือทันทีที่อุโมงค์เริ่มขึ้นฉันกำลังทุกข์ทรมานจากปัญหาที่อธิบายไว้ในคำถามของฉันดังนั้นคำสั่งจะช้าเกินไป นอกจากนี้เมื่อทดลองกับสิ่งนี้คำสั่งจะไม่ปรากฏว่าสร้างความแตกต่างใด ๆ ( nslookupยังคงใช้เซิร์ฟเวอร์ DNS ระยะไกลและipconfigยังแสดงรายการเซิร์ฟเวอร์ DNS ระยะไกล) ฉันได้แก้ไขการตั้งค่า DNS สำหรับการเชื่อมต่อช่องสัญญาณ VPN เพื่อใช้การตั้งค่า DNS ภายในของฉันเอง แต่สิ่งนี้ถูกละเว้นการรับส่งข้อมูล DNS ทั้งหมดของฉันยังคงปรากฏขึ้นเพื่อมุ่งไปยังเซิร์ฟเวอร์ DNS ระยะไกล

— ไบรอัน

1

ฉันลองสิ่งนี้เพราะฉันมีปัญหาเดียวกันและใช้งานได้ที่นี่ คุณได้ปรับ " ชื่อของ VPN " หรือไม่? นอกจากนี้ถ้าคุณมีความกังวลเกี่ยวกับเรื่องนี้ส่วนใหญ่จะเป็นหนึ่งในเซิร์ฟเวอร์ที่ไดรฟ์ของคุณเชื่อมต่อกับเพิ่มในแฟ้มครอบครัวของคุณและไม่มีอะไรที่จะสามารถที่จะแทนที่

— MichelZ

ขอบคุณฉันลองเปลี่ยนชื่อ (ตัดและวางจากipconfigผลลัพธ์และเมื่อฉันทำผิดฉันได้รับข้อผิดพลาดThe filename, directory name, or volume label syntax is incorrect) ดังนั้นฉันค่อนข้างมั่นใจว่าฉันได้รับคำสั่งที่ถูกต้อง อาจเป็นสิ่งที่อยู่บนเซิร์ฟเวอร์ PPTP ระยะไกลที่ไม่อนุญาตให้ฉันแทนที่การตั้งค่า DNS ฉันจะตรวจสอบ แต่ฉันชอบแนวคิดการป้อนไฟล์โฮสต์ ฉันจะไปให้ ดูการแก้ไขคำถามของฉันด้วย

— ไบรอัน

ฉันลองคำสั่งอีกครั้งและลบ DNS Server ออกจากการเชื่อมต่อ PPP คุณช่วยยืนยันด้วยได้ipconfig /allไหม ฉันคิดว่าอย่างไรก็ตามรายการโฮสต์ควรเป็นการแก้ไขที่ง่ายที่สุดสำหรับคุณ

— MichelZ

2

ช่องสัญญาณ VPN ของคุณอยู่ระหว่างไคลเอนต์และเครือข่ายไคลเอ็นต์ ฟังดูเหมือนว่ามันไม่ได้ใช้ช่องสัญญาณแยกซึ่งจะทำให้คุณไม่สามารถเข้าถึงทรัพยากรในเครือข่ายของคุณได้ในขณะที่อุโมงค์ทำงาน

ดังนั้นคุณ (หรือลูกค้าของคุณ) จำเป็นต้องเปิดใช้งานการแยกอุโมงค์หรือคุณต้องการการเชื่อมต่อเครือข่ายเพิ่มเติมและตารางเส้นทางที่กำหนดเองเพื่อเข้าถึงเครือข่ายทั้งสองในเวลาเดียวกัน

— dunxd
แหล่งที่มา

สำหรับข้อมูลฉันสามารถเข้าถึงทรัพยากรเครือข่ายในขณะที่อุโมงค์ทำงานได้มันเป็นเพียงความละเอียด DNS ที่ดูเหมือนว่าจะแตก ฉันไม่คุ้นเคยกับคำsplit tunnellingที่จะซื่อสัตย์ แต่เท่าที่ฉันสามารถบอกได้ว่าเกี่ยวข้องกับการทำให้แน่ใจว่าฉันไม่ได้ใช้เกตเวย์เริ่มต้นที่ไซต์ระยะไกลซึ่งแม้ฉันจะไม่ได้ระบุฉันก็ทำไปแล้ว ขอบคุณสำหรับการตอบกลับฉันจะแก้ไขคำถามของฉันเพื่อสะท้อนสิ่งนี้

— ไบรอัน

1

ในกรณีนี้ดูเหมือนว่า VPN ของลูกค้าไม่ได้รับการตั้งค่าสำหรับการแยก DNS ด้วยการแบ่ง DNS ตัวรวมช่องสัญญาณ VPN จะให้รายชื่อเซิร์ฟเวอร์ DNS ของคุณ (เหมือนที่เป็นอยู่ในปัจจุบัน) และรายการของโดเมนที่เป็นโดเมนเดียวที่ควรใช้กับเซิร์ฟเวอร์ DNS เหล่านั้น คนอื่น ๆ ทั้งหมดจะใช้ DNS เริ่มต้นของระบบของคุณ

— James Sneeringer

0

แม้ว่าคำถามนี้ถูกถามมานาน แต่การโพสต์คำตอบนี้อาจช่วยผู้อื่นได้ ฉันมีปัญหาเดียวกันกับ VPN ซึ่งเมื่อผู้ใช้เคยเชื่อมต่อกับ VPN ระยะไกล DNS ภายนอกของพวกเขาเคยหยุดเช่น google.comโดเมน บริษัท split-dnsเดียวที่ใช้ในการทำงานที่ถูกระบุไว้ใน

ปัญหาเกิดขึ้นเมื่อเครื่องโลคัลที่ใช้ทำทราฟฟิกเคียวรี dns ไปที่ vpn tunnel และถ้า dns ได้รับอนุญาตใน tunnel มันจะถอยกลับ เมื่อมันย้อนกลับมามันก็ใช้เพื่อเลือก ipv6 เป็นความละเอียดก่อนแล้วจึงไม่กลับไปที่ ipv4

ดังนั้นเพื่อทดสอบผลลัพธ์เราปิดการใช้งาน ipv6 เป็นครั้งแรกในเครื่องที่มันเริ่มทำงาน เพื่อแก้ไขอย่างถาวรสำหรับผู้ใช้ทุกคนเราได้เปิดใช้งานclient-bypass-protocolคำสั่งบนไฟร์วอลล์ ASA ซึ่งละเว้น IPv6 หากไม่ได้กำหนดค่าไว้ในพูล vpn

ดังนั้นหากคุณไม่สามารถควบคุมไฟร์วอลล์และรู้ว่าอุโมงค์ที่แยกและแยก DNS อยู่ในสถานที่ แต่มันล้มเหลวคุณสามารถลองปิดการใช้งานipv6บนเครื่องท้องถิ่นและถ้าคุณสามารถควบคุมมันได้แล้วคุณสามารถเปิดใช้งานคำสั่งข้างต้นตราบใดที่คุณไม่ใช้ ipv6 ในเครือข่ายระยะไกลของคุณ

สิ่งนี้ช่วยฉันได้หวังว่านี่จะช่วยคนอื่น :)

— Rsingh
แหล่งที่มา

0

มีบางอย่างที่ฉันมีประสบการณ์ด้วย!

ตั้งค่าการเชื่อมต่อ VPN กับเซิร์ฟเวอร์ DNS ในเครื่องและเชื่อมต่อกับ VPN ที่ใช้ nslookup เพื่อสอบถามชื่อโดเมน VPN คุณควรได้รับการตอบกลับด้วย IP ที่อยู่ภายใน VPN VPN ซึ่งหมายความว่าคุณใช้เซิร์ฟเวอร์ VPN DNS เพื่อแก้ไขแบบสอบถาม

ตอนนี้เปิดการเชื่อมต่อ LAN ของคุณและตั้งค่า DNS เป็น Local DNS หรือ ISP ของคุณด้วยตนเอง Volia !!! ใช้ปุ่มลูกศรและทำซ้ำแบบสอบถาม nslookup คุณจะได้รับ IP สาธารณะหมายถึงคุณใช้เซิร์ฟเวอร์ DNS ของท้องถิ่น / ISP เพื่อแก้ไขการสืบค้นของโดเมน VPN ปัง !!!!

— Graham.Fraser
แหล่งที่มา

0

ฉันเพียงแค่ลบตัวเลือกนี้ออกจากการกำหนดค่า VPN ไคลเอ็นต์

setenv เลือกบล็อกนอก -dns

มันแก้ไขปัญหา

— อิสมาอิล
แหล่งที่มา

0

ฉันมีปัญหานี้เมื่อไม่กี่ปีที่ผ่านมาและแก้ไขโดยการแก้ไขไฟล์การเชื่อมต่อ VPN เพียงแค่สร้างไฟล์ vpn.pbk (คุณสามารถหาได้ใน google) เปิดไฟล์นั้นผ่านตัวแก้ไขข้อความเช่น Notepad และเปลี่ยนค่า UseRasCredentials ให้เป็นศูนย์และคุณแก้ไขปัญหาได้แล้ว แต่ปัญหาเพียงอย่างเดียวคือการเชื่อมต่อในพื้นที่ของคุณลำดับความสำคัญของ DNS นั้นสูงกว่า VPN DNS และการแก้ไขชื่อจะใช้เวลามากกว่า (หากใช้ VPN เพื่อเชื่อมต่อกับอินเทอร์เน็ต)

— Mohsen Bigdeli
แหล่งที่มา

-1

ทำไมคุณถึงคิดว่า DNS ของมัน

หากคุณสูญเสียการเข้าถึงเครือข่ายที่ใช้ร่วมกันเมื่อคุณเชื่อมต่อกับ VPN - ดูเหมือนว่าเครื่องของคุณกำลังประสบปัญหา WINS / NETBIOS

กำหนดเซิร์ฟเวอร์ WINS และทดสอบอีกครั้ง

— Ben Lessani - Sonassi
แหล่งที่มา

ฉันไม่ทราบแน่ชัดว่านี่เป็นสาเหตุของปัญหาของฉัน แต่สิ่งที่ฉันรู้คือลูกค้า AD ควรใช้เซิร์ฟเวอร์ DNS ที่ใช้โฮสต์โฆษณาและนี่ไม่ใช่กรณี เนื่องจากปัญหาจะปรากฏขึ้นเมื่อฉันทำการเชื่อมต่อ VPN เท่านั้นและการแก้ไข DNS ของฉันในขณะเดียวกันดูเหมือนว่า DNS จะเป็นตัวเลือกที่เหมาะสม ฉันไม่ต้องการใช้เซิร์ฟเวอร์ DNS ระยะไกลเมื่อฉันเชื่อมต่อกับเครือข่ายอื่นโดยใช้ VPN

— ไบรอัน

คุณกำหนดเซิร์ฟเวอร์ WINS ตามคำแนะนำของฉันหรือไม่ ไม่ใช่เรื่องปกติของ Windows ที่จะใช้เซิร์ฟเวอร์ DNS บน VPN เว้นแต่ว่ามีการกำหนดไว้ใช้หรือมีการตั้งค่า "ใช้เกตเวย์ระยะไกล" ซึ่งคุณกล่าวว่าถูกปิดการใช้งาน นอกจากนี้คุณกำลังใช้ IP แบบคงที่บนอุโมงค์ VPN ดังนั้นทำไมคุณถึงตั้งค่ารายการ DNS เลย? ลบเซิร์ฟเวอร์ DNS เหล่านั้น (192.168.0.16-17) หรือตั้งค่าเซิร์ฟเวอร์ WINS

— Ben Lessani - Sonassi

ไม่ฉันไม่ได้ลองเพราะเราไม่มีเซิร์ฟเวอร์ WINS ที่จะชี้ลูกค้า ฉันไม่เชื่อว่า WINS จะช่วยให้ซื่อสัตย์ฉันจึงไม่กระตือรือร้นที่จะติดตั้งเซิร์ฟเวอร์ WINS บนเครือข่ายของเราเพราะอาจช่วยได้ ฉันจะจำความคิดไว้อย่างแน่นอนขอบคุณ IP ได้รับมอบหมายจากเซิร์ฟเวอร์ VPN และเป็นแบบไดนามิก หากฉันไม่ได้กำหนดเซิร์ฟเวอร์ DNS สำหรับการเชื่อมต่อ VPN เซิร์ฟเวอร์จะถูกกำหนดแบบไดนามิก ฉันได้เข้ารหัสเซิร์ฟเวอร์ DNS ของฉันเองอย่างหนักในคุณสมบัติการเชื่อมต่อ VPN แต่ก็ยังใช้เซิร์ฟเวอร์ DNS ที่ไซต์ระยะไกล

— ไบรอัน

ฉันไม่ต้องการหรือไม่ต้องการใช้เซิร์ฟเวอร์ DNS ระยะไกลฉันต้องการให้มีการแก้ปัญหา DNS บนเซิร์ฟเวอร์ภายในเสมอซึ่งจะช่วยแก้ไขปัญหาของฉันได้ดังนั้นคำถามของฉันจึงมุ่งเน้นไปที่ DNS ฉันอาจใช้กฎไฟร์วอลล์เพื่อบล็อกการเข้าถึงเซิร์ฟเวอร์ DNS ระยะไกล แต่สิ่งนี้ไม่ได้แก้ไขปัญหาการกำหนดค่าผิดพลาดพื้นฐาน

— ไบรอัน

1

การตีความนี้ไม่ถูกต้อง ที่อยู่ IP ถูกกำหนดโดยเซิร์ฟเวอร์ PPTP ซึ่งไม่ได้ใช้ DHCP จริงๆ เซิร์ฟเวอร์ PPTP มีพูลที่สามารถจัดสรรได้ แต่นี่ไม่ใช่ DHCP ฉันจะได้รับ IP ที่แตกต่างกันทุกครั้งที่ฉันเชื่อมต่อ นอกจากนี้ฉันยังไม่ได้ทำเครื่องหมายที่ช่องเพื่อใช้เกตเวย์ระยะไกลเช่นกันเนื่องจากคุณสามารถเห็นได้อย่างชัดเจนจากตารางเส้นทาง

— ไบรอัน