ทำไม Windows จึงส่งชื่อ VPN ของคุณไปยังเซิร์ฟเวอร์ DNS ที่คุณไม่เคยตั้งค่า

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

คุณเปลี่ยนอะไร และอะไรเป็นตัวตัดสินจริง ๆ

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

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

ตารางจับคู่ชื่ออย่างไร

กฎถูกทำดัชนีตามเนมสเปซ และการตรงกันที่เฉพาะเจาะจงที่สุดเป็นผู้ชนะ กฎสำหรับ corp.example ใช้กับ vpn.corp.example และไม่ใช้กับ example.net กฎที่มีเนมสเปซ . ครอบคลุมทุกอย่างที่กฎอื่นไม่ครอบ ซึ่งทำให้เป็นรายการที่อันตรายที่สุดในรายการ และเป็นรายการที่ควรตรวจเมื่อเว็บไซต์ที่ไม่เกี่ยวข้องถูกแก้ผ่านอุโมงค์

กฎยังพกความคิดเห็น นโยบายที่ปิดใช้งานรายการ และการตั้งค่าความปลอดภัยที่ไม่เกี่ยวกับที่อยู่ DNS ได้ กฎที่ปิดใช้งานยังมองเห็นได้ในการกำหนดค่าแต่ไม่มีผล ดังนั้นรายการที่ดูถูกต้องบนกระดาษอาจไม่ทำงานเลยหลังเปลี่ยนโปรไฟล์

อ่านตารางที่ใช้จริง ไม่ใช่รายการความปรารถนา

กฎที่กำหนดค่าไว้กับกฎที่ใช้จริงเป็นสองคำถามที่ต่างกัน Get-DnsClientNrptRule แสดงรายการสิ่งที่มีอยู่ในเครื่อง Get-DnsClientNrptPolicy -Effective แสดงสิ่งที่ไคลเอนต์จะใช้จริง พร้อมค่าที่รวมจากนโยบายและการตั้งค่าท้องถิ่น

เปรียบเทียบส่วนต่อท้ายในผลลัพธ์นั้นกับชื่อที่คุณทดสอบ ทีละอักขระ กฎสำหรับ corp.example ไม่จับชื่อที่ลงท้ายด้วย corp.example.com และจุดที่ท้ายในที่หนึ่งแต่ไม่มีในอีกที่หนึ่งก็เพียงพอที่จะเปลี่ยนการตรงกัน

เมื่อไม่มีกฎ Windows จะถามมากกว่าหนึ่งอะแดปเตอร์

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

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

เส้นทางที่ข้ามตัวแก้ไขไปเลย

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

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

ทดสอบด้วยชื่อที่ล้มเหลว

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

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