รายงาน DNS ของ VPN: ควรรวมอะไรเพื่อให้ทำซ้ำได้

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

หมวดหมู่ของชื่อ ไม่ใช่คำตัดสิน

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

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

บันทึกเส้นทางของรีโซลเวอร์

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

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

ระบุการเปรียบเทียบที่ควบคุมได้

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

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

ปิดบังเนมสเปซ เก็บความสัมพันธ์ไว้

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

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