เซิร์ฟเวอร์ DNS ผิดใน Windows VPN: เมตริก ลำดับการผูกพันธะ หรือซัฟฟิกซ์
กลไกสามอย่างของ Windows เลือกตัวแปลงชื่อ DNS และล้มเหลวต่างกัน ตัดสินจากขอบเขตของเนมสเปซ ลำดับระดับโลก หรือว่าการแก้ไขอยู่รอดหลังการเชื่อมต่อใหม่หรือไม่
ไคลเอนต์ Windows อาจมีอุโมงค์ที่ทำงานได้ มีตัวแปลงชื่อขององค์กร และยังส่งชื่อภายในไปยังเราเตอร์ที่บ้าน สามกลไกที่แตกต่างกันเป็นตัวกำหนดว่าเซิร์ฟเวอร์ใดจะตอบ และแต่ละกลไกก็ล้มเหลวต่างกัน เราไม่จำเป็นต้องแก้ทั้งสาม: อาการบอกได้ว่าตัวใดกำลังเกี่ยวข้อง แผนผังการตัดสินใจด้านล่างใช้เวลาไม่กี่นาทีและป้องกันผลลัพธ์ที่พบบ่อย คือการเปลี่ยนเมตริก การจัดเรียงรีจิสทรีใหม่ และกฎ NRPT มาพร้อมกันแล้วไม่มีใครรู้ว่าอันไหนทำอะไร
สามกลไกเป็นตัวตัดสิน และมักมีหนึ่งที่ผิด
เมตริกของอินเทอร์เฟซจัดลำดับอะแดปเตอร์สำหรับตระกูลที่อยู่หนึ่ง ลำดับการผูกพันธะภายใต้ Tcpip\Linkage เป็นรายการระดับเครื่องของตัวระบุอินเทอร์เฟซที่เส้นทางโค้ดเก่ายังคงตรวจสอบ ตารางนโยบายการแปลงชื่อ (NRPT) ผูกเนมสเปซกับเซิร์ฟเวอร์เฉพาะ และรายการซัฟฟิกซ์เป็นตัวตัดสินว่าชื่อสั้นจะถูกขยายหรือไม่ ทั้งสามเป็นอิสระต่อกัน จึงเป็นเหตุให้ตัวแปลงชื่อที่ถูกต้องบนอะแดปเตอร์ VPN แพ้ให้กับการตั้งค่าเก่าที่อื่น
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
ไม่มีกลไกใดในนี้เป็นอีกด้านของอุโมงค์ ถ้าเซิร์ฟเวอร์ที่ VPN ดันมาไม่สามารถแปลงชื่อได้ การตั้งค่าฝั่งไคลเอนต์ทั้งหมดก็เป็นเพียงเครื่องประดับ ดังนั้นการตัดสินใจแรกคือตัวแปลงชื่อเองตอบได้หรือไม่เมื่อถามตรง ๆ
การตัดสินใจที่หนึ่ง: ตัวแปลงชื่อที่ดันมาตอบได้หรือไม่
ถามเซิร์ฟเวอร์อย่างชัดเจนแล้วเทียบกับการค้นหาปกติ ช่องว่างระหว่างคำตอบแยกปัญหาการเลือกออกจากปัญหาการเข้าถึง และนี่คือทางแยกที่เร็วที่สุด:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aถ้าอันแรกสำเร็จและอันที่สองล้มเหลว แปลว่าตัวแปลงชื่อเข้าถึงได้และ Windows เลือกไม่ดี ให้ไปที่การตัดสินใจเรื่องเนมสเปซและลำดับด้านล่าง ถ้าอันแรกก็ล้มเหลวด้วย ไม่มีอะไรบนไคลเอนต์จะช่วยได้ ตรวจสอบว่า UDP และ TCP 53 ไปถึงเซิร์ฟเวอร์ผ่านอุโมงค์หรือไม่ ไฟร์วอลล์ของโฮสต์บนเซิร์ฟเวอร์ไม่ได้ทิ้งพูล และตัวส่งต่อของเซิร์ฟเวอร์เองอยู่ในสภาพดีหรือไม่
หยุดที่ทางแยกนี้ การใช้กฎ NRPT กับตัวแปลงชื่อที่เข้าถึงไม่ได้ให้ผลล้มเหลวเดิมพร้อมการตั้งค่าที่ต้องย้อนกลับมากกว่า และซ่อนข้อบกพร่องจริงไว้หลังกฎที่ดูมีอำนาจ
การตัดสินใจที่สอง: เนมสเปซเดียวหรือทุกคำขอ
ขอบเขตเป็นตัวกำหนดเครื่องมือ เมื่อมีเฉพาะชื่อองค์กรที่ล้มเหลว ให้ผูกเนมสเปซแทนการจัดเรียงเครื่องใหม่: กฎ NRPT ส่งซัฟฟิกซ์นั้นไปยังตัวแปลงชื่อของอุโมงค์และปล่อยอย่างอื่นไว้ เมื่อทุกการค้นหาได้รับผลกระทบ ปัญหาคือลำดับความสำคัญของอะแดปเตอร์ระดับโลก และเมตริกคือจุดที่ควรเริ่มเพราะไม่เปลี่ยนการตั้งค่าเซิร์ฟเวอร์ใด ๆ
ตั้งเมตริกแยกตามตระกูลที่อยู่ บนอินเทอร์เฟซทั้งสอง แล้วยืนยันลำดับภายหลัง:
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 ด้วย ifIndex ของอะแดปเตอร์อุโมงค์จากบรรทัดด้านบน ถ้า 11 เป็นอะแดปเตอร์ LAN คำสั่งเดียวกันจะลดเส้นทางที่ผิด การเพิ่มอะแดปเตอร์ LAN แทนจะไปถึงลำดับเดียวกันจากอีกด้าน: netsh int ip set interface interface="Ethernet" metric=15 และ netsh int ipv6 set interface interface="Ethernet" metric=15 สำหรับตระกูลที่สอง เพราะ int ip แตะเฉพาะ IPv4
ลำดับการผูกพันธะเป็นทางเลือกสุดท้ายไม่ใช่ก้าวแรก HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage เก็บรายการ Bind ของตัวระบุอุปกรณ์ และการย้ายตัวระบุอุโมงค์ขึ้นหน้าเปลี่ยนว่าอะแดปเตอร์ใดถูกถามก่อนจริง แต่เป็นค่ารีจิสทรีระดับเครื่องที่ไม่มีขอบเขตตามเนมสเปซ ส่งออกก่อนแก้ไขแล้วเชื่อมต่ออุโมงค์ใหม่ภายหลัง เพื่อให้ลำดับมีผลในสภาวะที่ไคลเอนต์คาดหวัง
สำหรับเนมสเปซเดียว ให้เลือกเครื่องมือที่แคบกว่า:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersการตัดสินใจที่สาม: การแก้ไขอยู่รอดหลังการเชื่อมต่อใหม่หรือไม่
เมตริกที่ใช้ได้จนถึงการเชื่อมต่อแบบ dial-up ครั้งถัดไปไม่เคยถูกบันทึก โปรไฟล์การเชื่อมต่อ L2TP/IPsec และอื่น ๆ ถูกสร้างใหม่เมื่อการเชื่อมต่อเริ่ม ดังนั้นค่าที่บันทึกจึงอยู่ในรายการสมุดโทรศัพท์เป็น IpInterfaceMetric ไม่ใช่เฉพาะบนอินเทอร์เฟซที่ทำงานอยู่ บางสภาพแวดล้อมเขียนฟิลด์นั้นด้วยสคริปต์ด้วยเหตุผลนี้เอง บางแห่งดันการตั้งค่าจากนโยบายการจัดการและปล่อยปลายทางไว้
แคชและการลงทะเบียนเป็นอีกชั้นหนึ่ง การเรียกใช้สิ่งเหล่านี้หลังอุโมงค์ขึ้นจะแก้ไขรายการที่ล้าสมัยและลงทะเบียนไคลเอนต์ใหม่ แต่ทั้งสองไม่จัดเรียงอะแดปเตอร์ใหม่:
ipconfig /registerdns
ipconfig /flushdnsมีสวิตช์ปิดในชั้นเดียวกัน การปิดการลงทะเบียนแบบไดนามิกบนอะแดปเตอร์กายภาพป้องกันไม่ให้ไคลเอนต์ประกาศที่อยู่ฝั่ง VPN ภายใต้ชื่อที่ผิด และนั่นเป็นการซ่อมแซมที่ต่างจากการรีเฟรชด้านบน
IPv6 สมควรมีบรรทัดของตัวเองในการตัดสินใจ ถ้าอะแดปเตอร์กายภาพมีที่อยู่ IPv6 แบบทั่วโลกในขณะที่อุโมงค์พาเฉพาะ IPv4 Windows อาจเลือกเส้นทางที่ไม่ผ่านอุโมงค์สำหรับการแปลงชื่อ ตรวจสอบตระกูลนั้นแยก เพราะเมตริกที่ตั้งไว้สำหรับ IPv4 ไม่ได้บอกอะไรเกี่ยวกับตระกูลนั้นเลย:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricการปิด IPv6 บนอะแดปเตอร์ LAN จะลบเส้นทางนั้นและโปรโตคอลไปด้วย การเปลี่ยนเมตริกบนอินเทอร์เฟซ IPv6 หรือกฎ NRPT สำหรับเนมสเปซองค์กรจะคงตระกูลไว้และแก้ไขลำดับความสำคัญ เลือกอันที่แคบกว่า เว้นแต่คุณจะตัดสินใจว่าลิงก์นั้นไม่ควรมี IPv6
ตรวจสอบด้วยแหล่งที่ระบุชื่อ และรักษาเจ้าของเพียงหนึ่งเดียว
ตรวจสอบด้วยเครื่องมือที่รายงานว่าแหล่งใดมีผล ไม่ใช่เพียงว่าเพจโหลดได้:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aจากนั้นแยกการกรองออกจากการเลือก เพราะจากภายในแอปพลิเคชันทั้งสองดูเหมือนกัน block-outside-dns ของ OpenVPN บล็อกพอร์ต 53 บนอะแดปเตอร์อื่น มันไม่ได้เลือกตัวแปลงชื่อ ถ้าตอนนี้ทุกคำขอล้มเหลว ตัวกรองอาจกำลังบล็อกเซิร์ฟเวอร์เดียวที่เข้าถึงได้ ถ้าตัวแปลงชื่อที่กำหนดค่าไว้ถูกเพิกเฉย ลำดับหรือกฎเนมสเปซผิด การเปลี่ยนทั้งสองพร้อมกันทำให้คำขอที่ถูกบล็อกกับคำขอที่ถูกเพิกเฉยแยกไม่ออก
รักษาเจ้าของนโยบาย DNS เพียงหนึ่งเดียว: โปรไฟล์ VPN นโยบายการจัดการ หรือกฎ NRPT ไม่ใช่สองอย่าง ก่อนปิดงาน:
- ตัวแปลงชื่อที่ดันมาตอบเมื่อระบุชื่ออย่างชัดเจน และการค้นหาปกติใช้มัน
- กฎหรือเมตริกที่คุณเปลี่ยนครอบคลุมตระกูลที่อยู่ที่พาคำขอจริง
- การตั้งค่าอยู่รอดหลังการตัดการเชื่อมต่อและการเชื่อมต่อใหม่ หรือคุณย้ายมันไปยังโปรไฟล์ที่บันทึกไว้
- มีกลไกเดียวเท่านั้นที่มีอำนาจ และกลไกอื่นถูกปล่อยไว้ตามเดิม
มองลำดับเป็นสภาวะของสภาพแวดล้อม ไม่ใช่สิ่งที่ต้องทำให้เสร็จ ตรวจสอบซ้ำหลังการเชื่อมต่อใหม่และหลังการอัปเดต Windows ที่แตะสแตกเครือข่าย เพราะอย่างใดอย่างหนึ่งอาจนำอะแดปเตอร์กายภาพกลับขึ้นมาข้างหน้า