สองเซิร์ฟเวอร์ DNS บนอะแดปเตอร์เดียวไม่ได้แยกเนมสเปซ

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

ความเชื่อผิด: ที่อยู่สองรายการแยกสองโดเมน

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

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

Windows ใช้อะไรจริง ๆ ในการเลือก

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

หนึ่งกฎต่อเนมสเปซ เก็บออบเจ็กต์ไว้

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

จุดนำหน้าหมายถึงการจับคู่ส่วนต่อท้าย ดังนั้นกฎจึงครอบคลุม app.svc.internal.example และสิ่งอื่นใดใต้ชื่อนั้น สองที่อยู่ที่นี่เป็นของแผนการกำหนดเส้นทางของห้องปฏิบัติการนี้เอง กฎไม่ได้สร้างโซน ไม่ได้ติดตั้งเส้นทาง และไม่ได้อนุญาตแอปพลิเคชันที่เชื่อมต่อในที่สุด และเอกสารอ้างอิง Add-DnsClientNrptRule อธิบายอย่างแม่นยำว่าพารามิเตอร์ใดทำอะไร

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

พิสูจน์ว่าไคลเอนต์เลือกเซิร์ฟเวอร์

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

ลบสิ่งที่คุณสร้างอย่างแม่นยำ

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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