วิธีอ่านเส้นทาง DNS ของ VPN แต่ละลิงก์จาก resolvectl

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

แต่ละบล็อกของลิงก์บอกอะไรคุณ

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

ที่อยู่สตับเช่น 127.0.0.53 ใน /etc/resolv.conf บอกเพียงว่าสตับอยู่ด้านหน้า ไม่ได้ระบุต้นทางที่ตอบ ดังนั้นการวินิจฉัยที่อาศัยเฉพาะ resolv.conf จะติดขัด

อ่านรายการโดเมนสามประเภทให้ถูกต้อง

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

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

ถามชื่อและดูว่าลิงก์ใดตอบ

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

resolvectl status
resolvectl query host.corp.example

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

แยกเส้นทางของชื่อออกจากเส้นทางของแพ็กเก็ต

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

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

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

ตรวจสอบอีกครั้งหลังจากลิงก์เปลี่ยน

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

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