VPN ของคุณส่งเซิร์ฟเวอร์ DNS สามตัว: ตัวไหนตอบ?
รายการเพิ่มเติมอาจเป็นตัวสำรอง เส้นทางต่อโดเมน หรือเศษที่เหลือจากลิงก์กายภาพ จับคู่แต่ละรายการกับขอบเขตก่อนจะเรียกรายการนี้ว่ารั่ว
เปิดหน้าตั้งค่าหลังเชื่อมต่อแล้วจะเห็นที่อยู่ DNS สามรายการ คำถามของการตรวจสอบคือรายการใดจัดการคำค้นครั้งล่าสุดของคุณ จำนวนอย่างเดียวไม่ตอบอะไร เพราะการพุชจากไคลเอนต์ อินเทอร์เฟซกายภาพ และนโยบายต่อโดเมนต่างเขียนลงในมุมมองเดียวกัน รายการเหล่านี้มีขอบเขตต่างกัน และขอบเขต ไม่ใช่ตำแหน่ง เป็นตัวกำหนดว่าใครตอบ เริ่มจากการแยกแหล่งที่มา แล้วทดสอบแหล่งที่เป็นเจ้าของชื่อที่คุณสนใจ
ทำไมรายการจึงยาวกว่าโปรไฟล์ของคุณ
ไคลเอนต์ VPN พุชที่อยู่ของตัวแก้ไขชื่อสำหรับลิงก์อุโมงค์ และระบบปฏิบัติการเก็บไว้ข้างสิ่งที่อินเทอร์เฟซกายภาพมีอยู่แล้ว เราเตอร์ สัญญาเช่า DHCP ขององค์กร VPN ตัวที่สอง และนโยบายต่อโดเมนต่างเพิ่มรายการของตัวเอง ดังนั้นที่อยู่สามรายการบนหน้าอาจหมายถึงสามขอบเขต ไม่ใช่สามผู้สมัครสำหรับงานเดียว การอ่านจำนวนเป็นหลักฐานของการรั่วไหลเป็นความผิดพลาดแรกของการตรวจสอบนี้
ภายในอินเทอร์เฟซเดียว ไคลเอนต์ลองเซิร์ฟเวอร์ตามลำดับจริง รายการที่เรียงลำดับจึงไม่ไร้ความหมาย สิ่งที่ไม่ใช่คิวคือมุมมองรวม ซึ่งรายการจากโปรไฟล์ ลิงก์กายภาพ และกฎต่อโดเมนวางเคียงกันโดยไม่มีอันดับเดียว ความแตกต่างนี้กำหนดสิ่งที่คุณทดสอบ ลำดับอธิบายพฤติกรรมภายในขอบเขตเดียว และขอบเขตอธิบายอย่างอื่นทั้งหมด
DNS ที่เข้ารหัสทำให้ภาพแตกจากภายในแอปพลิเคชัน เบราว์เซอร์หรือไคลเอนต์แชทที่มีตัวแก้ไขชื่อ DNS-over-HTTPS ของตัวเองส่งคำค้นข้ามรายการของระบบปฏิบัติการไปทั้งหมด ที่อยู่บนหน้าตั้งค่าจึงอธิบายการรับส่งที่แอปไม่เคยสร้าง ตรวจสอบการตั้งค่าตัวแก้ไขชื่อของแอปเองก่อนโทษโปรไฟล์สำหรับชื่อที่ออกมาผิด
แต่ละการตรวจสอบทั้งสามบอกอะไร
แต่ละแหล่งทิ้งร่องรอยไว้คนละที่ และไม่มีคำสั่งเดียวที่แสดงทั้งหมด นี่คือการจับคู่ที่ควรเก็บไว้ข้างหน้าตั้งค่า
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
บนระบบที่ใช้ systemd-resolved คำสั่ง resolvectl status เป็น authoritative เพราะรายงาน DNS ต่อลิงก์พร้อมโดเมนเส้นทาง macOS ตอบผ่าน scutil --dns ซึ่งไล่ตัวแก้ไขชื่อที่มีขอบเขตตามลำดับที่ลอง Windows แยกสองครึ่ง Get-DnsClientServerAddress สำหรับเซิร์ฟเวอร์ต่ออินเทอร์เฟซ และ Get-DnsClientNrptPolicy สำหรับกฎซัฟฟิกซ์ รันคำสั่งที่เป็นของตัวแก้ไขชื่อที่ใช้จริง เพราะเครื่องที่มีรันไทม์คอนเทนเนอร์และตัวแก้ไขชื่อเดสก์ท็อปอาจติดตั้งไว้มากกว่าหนึ่ง
ตัวแก้ไขชื่อสำรองที่ไม่สามารถตอบโซนของคุณได้
รายการที่สองมักมีไว้เพื่อความพร้อมใช้งาน และความพร้อมใช้งานได้ผลก็ต่อเมื่อตัวสำรองรู้จักชื่อ ถามตัวแก้ไขชื่อสาธารณะเกี่ยวกับชื่อโฮสต์ภายใน มันจะคืน NXDOMAIN หรือคำตอบไวลด์การ์ดจากโดเมนค้นหาที่ไม่เกี่ยวข้องกับคุณ การสลับสำรองที่ไม่มีใครตรวจสอบจะสร้างเหตุขัดข้องในจังหวะที่ต้องการมันพอดี
Split DNS มีอยู่เพื่อป้องกันสิ่งนั้น ซัฟฟิกซ์ของบริษัทไปยังตัวแก้ไขชื่อที่ถือโซน และชื่อสาธารณะอยู่บนเส้นทางค่าเริ่มต้น การออกแบบนั้นแข็งแรง และขึ้นกับรายการซัฟฟิกซ์ที่ครบถ้วน Microsoft เอกสาร นโยบายตัวแก้ไขชื่อต่อซัฟฟิกซ์ที่ขับเคลื่อนสิ่งนี้บน Windows และแนวคิดเดียวกันปรากฏเป็นโดเมนเส้นทางใน systemd-resolved และเป็นตัวแก้ไขชื่อที่มีขอบเขตบน macOS
เปรียบเทียบโซนที่ตัวสำรองตอบได้กับซัฟฟิกซ์ที่มีอยู่ในนโยบาย การเปรียบเทียบนั้นพบช่องว่างก่อนผู้ใช้จะรายงานว่าไซต์ภายในหนึ่งแห่งหยุดแก้ชื่อหลังการเปลี่ยนอุโมงค์
สอบถามผ่านนโยบาย ไม่ใช่อ้อมนโยบาย
สอบถามผ่านตัวแก้ไขชื่อของระบบปฏิบัติการ เพราะการสอบถามตรงไปยังเซิร์ฟเวอร์ข้ามนโยบายและรายงานเพียงสิ่งที่เซิร์ฟเวอร์นั้นจะพูด ช่องว่างระหว่างคำตอบสองแบบคือประเด็นทั้งหมด
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53หากการสอบถามของระบบคืนที่อยู่ส่วนตัว ในขณะที่การสอบถามตรงคืน NXDOMAIN แสดงว่านโยบายทำงานและจุดอ่อนคือตัวสำรอง หากทั้งสองคืนคำตอบสาธารณะเดียวกัน ชื่อกำลังถูกแก้ไขนอกขอบเขตที่คุณตั้งใจ และรายการซัฟฟิกซ์คือที่ที่ต้องดู เก็บผลลัพธ์ทั้งสองไว้ เพราะการโต้แย้งเรื่องตัวแก้ไขชื่อจบเร็วกว่าด้วยสองบรรทัดมากกว่าภาพหน้าจอของหน้าตั้งค่า
จากนั้นฝึกเส้นทางความล้มเหลว เพราะตัวสำรองที่ไม่มีใครทดสอบเป็นเพียงสมมติฐาน ทำให้ตัวแก้ไขชื่อที่ต้องการเป็นหลุมดำสำหรับคำค้นหนึ่งครั้ง แล้วดูว่าที่อยู่ใดกลับมา
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32ลบเส้นทางนั้นทันทีที่คำค้นจบ มิฉะนั้นคนถัดไปจะได้ปริศนาไป หากชื่อภายในยังแก้ได้ในช่วงนั้น แสดงว่ามีบางสิ่งนอกขอบเขตที่ตั้งใจตอบชื่อเหล่านั้น หากกลับหมดเวลาแทน แสดงว่าตัวสำรองหายไปหรือถูกจำกัดขอบเขตอย่างถูกต้อง และบันทึกของตัวแก้ไขชื่อเองจะบอกว่าเป็นแบบไหน
ตัดสินใจ: เก็บ จำกัด หรือลบ
เก็บตัวแก้ไขชื่อตัวที่สองไว้เมื่อมันตอบเนมสเปซที่คุณต้องการและยังเข้าถึงได้ภายใต้โปรไฟล์ จำกัดขอบเขตเมื่อมันควรเห็นซัฟฟิกซ์เดียวและไม่มีอย่างอื่น และลบออกเมื่อมันไม่มีทั้งขอบเขตและวัตถุประสงค์ที่บันทึกไว้ รายการที่ไม่มีงานคือการรั่วไหลในอนาคตโดยไม่มีประโยชน์ และค่าเริ่มต้นของผู้ขายไม่ใช่วัตถุประสงค์
บันทึกผลลัพธ์เป็นสี่คอลัมน์: ซัฟฟิกซ์ ตัวแก้ไขชื่อ อินเทอร์เฟซ และเจ้าของ บรรทัดนั้นตอบคำถามการตรวจสอบครั้งถัดไปได้เร็วกว่าภาพหน้าจอใด ๆ และทนต่อการอัปเดตไคลเอนต์ที่จัดเรียงรายการใหม่โดยไม่ส่งเสียง