ทำไมรายการ /etc/hosts ของคุณจึงไปไม่ถึง DNS ของ VPN

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

Hosts เป็นการแทนที่แบบท้องถิ่น ไม่ใช่การอัปเดตโซน

ไฟล์นี้คือรายการการแมปที่ไลบรารีบริการชื่อตรวจดูก่อนหรือแทนการถามเซิร์ฟเวอร์ DNS บรรทัดอย่าง 10.40.0.20 build.corp.example เปลี่ยนสิ่งที่แอปพลิเคชันบนเครื่องเดียวนั้นสรุป มันไม่ได้สร้างระเบียน ไม่ได้เดินทางผ่านอุโมงค์ และเซิร์ฟเวอร์ DNS ที่อุโมงค์ชี้ไปก็ไม่รู้ว่ามันมีอยู่

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

สองคำสั่ง สององค์ประกอบที่ต่างกัน

วิธีที่เร็วที่สุดในการยุติการโต้แย้งคือทำให้ความแตกต่างมองเห็นได้ในสองคำสั่ง ทั้งสองรันบนไคลเอนต์ที่มีรายการ hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

ลำดับนั้นกำหนดค่าได้ และควรค่าแก่การตรวจสอบก่อนสรุปสิ่งใดเกี่ยวกับดิสทริบิวชันหนึ่ง ๆ ดูบรรทัด hosts: ใน /etc/nsswitch.conf hosts: files dns ตรวจดูไฟล์ก่อน อย่าคัดลอกตัวอย่างนั้นทับการกำหนดค่าที่ทำงานอยู่เพียงเพื่อเปลี่ยนลำดับ เพราะระบบจริงมักแสดงแหล่งที่มาเพิ่มเติมและรายการบริการแบบมีเงื่อนไขที่ตัวอย่างไม่มี

systemd-resolved ทำให้การทดสอบคลุมเครือ

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

resolvectl query build.corp.example
resolvectl status

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

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

อะไรที่แบ่งปันชื่อข้าม VPN จริง ๆ

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

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

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

ชื่อที่แก้ได้ไม่ใช่เส้นทาง

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

ดังนั้นเมื่อรายงานว่า “ชื่อแก้ได้แต่บริการเข้าถึงไม่ได้” ให้เปรียบเทียบการค้นหาของระบบกับการสอบถามที่ชัดเจนไปยังเซิร์ฟเวอร์ DNS ของ VPN แล้วตรวจสอบที่อยู่ที่คุณได้กับที่อยู่ที่บริการใช้จริง เอกสารอ้างอิง systemd-resolved บันทึกแหล่งที่มาท้องถิ่นที่มันตรวจดู และนั่นคือแผนที่ที่คุณต้องใช้สำหรับการเปรียบเทียบนั้น

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