VPN เข้ายึด DNS และทำให้ชื่อในเครื่องเสีย: ซ่อมรายการ

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

ซ่อมรายการอย่างตั้งใจ แล้วแยกจัดการกลไก push ทีหลัง เส้นทางเป็นหัวข้อที่สาม ไม่ใช่สิ่งที่ซ่อมที่นี่

แอปพลิเคชันใช้รายการใดจริง ๆ

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

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

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

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

ลบเซิร์ฟเวอร์ที่ถูกดันเข้ามา หรือจัดให้อยู่ต่ำลง

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

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 ถูกดูเป็นอันดับแรก ที่อยู่ที่ถูกดันเข้ามาจึงยังใช้ได้แต่ไม่ใช่คำตอบเริ่มต้นของทุกคำถามอีกต่อไป ธง validate=no ข้ามการทดสอบการเข้าถึงที่มักล้มเหลวขณะอุโมงค์ยังเข้าที่ จึงยืนยันผลด้วยคำสั่ง show แทนที่จะเชื่อรหัสออก

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

จะกรอง push ได้ที่ใด

การซ่อมที่ดีกว่าคือเอาโอกาสออกไปก่อนที่จะถูกใช้ ไคลเอนต์ Community OpenVPN กรองคำสั่งที่ถูกดันเข้ามาตามชื่อได้ ซึ่งทำให้การตั้งค่าของเซิร์ฟเวอร์ไม่ถูกแตะต้อง

pull-filter ignore "dhcp-option DNS "

ช่องว่างท้ายเป็นส่วนของการจับคู่ และตัวกรองระบุชื่อตัวเลือกไม่ใช่ที่อยู่เซิร์ฟเวอร์ ถ้าโปรไฟล์มีคำสั่ง block-outside-dns ด้วย การลบมันเปลี่ยนการป้องกันการรั่วไหล ไม่ใช่การแปลงชื่อ จึงตัดสินเรื่องนั้นแยกแทนที่จะรวมการแก้สองอย่างเข้าด้วยกัน

สำหรับชื่อโฮสต์ดื้อ ๆ หนึ่งชื่อ การเพิ่มหนึ่งบรรทัดในไฟล์ hosts ของ Windows นิ่งกว่าการจัดลำดับตัวแปลงใหม่ทั้งเครื่อง และยังมองไม่เห็นสำหรับคนถัดไป จึงบันทึกไว้ที่ที่เอกสารการตั้งค่าของเครื่องอยู่

ทำให้การซ่อมอยู่รอดหลังเชื่อมต่อใหม่

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

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

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

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