โดเมน VPN ของคุณใน dnsmasq ไม่ใช่การถ่ายโอนโซน

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

สิ่งที่ไคลเอนต์ยอมรับไม่ใช่สิ่งที่เกตเวย์เสนอ

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

ความแตกต่างนั้นอธิบายรายงานส่วนใหญ่เกี่ยวกับโดเมนที่ไม่เคยมาถึง มันถูกเสนอ และมันไม่ได้ถูกนำไปใช้

รายการโดเมนสองชนิด

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

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

localhost ใน resolv.conf ไม่ใช่บั๊ก

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

การแทนที่รายการนั้นด้วยตัวแก้ไขสาธารณะคือการแก้ไขผิดแบบคลาสสิก มันคืนการแก้ชื่อสาธารณะและทิ้งนโยบายแบบมีเงื่อนไขในการแก้ไขเดียวกัน

อย่าสับสนระหว่าง backend

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

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

ทดสอบเนมสเปซ ไม่ใช่แค่คำตอบ

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

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