DNS รั่วไหลใน VPN ของ Windows: ทำไมเมตริกจึงชนะเส้นทาง

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

คำอธิบายสองอย่างสำหรับการรั่วไหลครั้งเดียว

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

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

เทียบเมตริกและตัวแก้ชื่อไปพร้อมกัน

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

ยกอุโมงค์ขึ้นแล้วตรวจซ้ำ

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

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

ทำให้ทนต่อการเชื่อมต่อใหม่

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

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