ทำไม resolv.conf แสดง DNS ของ VPN แต่การค้นหากลับไม่สนใจ

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

สามวัตถุที่ชื่อ resolv.conf

บนโฮสต์ที่ใช้ resolved โดยปกติ /etc/resolv.conf เป็นลิงก์สัญลักษณ์ไปยัง /run/systemd/resolve/stub-resolv.conf ปลายทางนั้นเก็บที่อยู่ของตัวฟัง stub ในเครื่อง 127.0.0.53 พร้อมโดเมนค้นหาที่ resolved คำนวณไว้ นี่คือมุมมองของสถานะ ไม่ใช่สถานะเอง

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

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

ติดตามการค้นหาหนึ่งครั้งผ่าน NSS

glibc อ่าน /etc/nsswitch.conf เพื่อตัดสินว่าใครตอบชื่อ บรรทัด hosts ที่มี resolve จะส่งคำถามไปยัง nss-resolve ซึ่งถาม resolved ผ่าน D-Bus และได้คำตอบแยกตามลิงก์ บรรทัดที่มีเพียง files dns จะส่งคำค้นไปยังที่อยู่ที่ /etc/resolv.conf ถืออยู่

บรรทัดเดียวนี้ธิบายความขัดแย้งส่วนใหญ่ระหว่างเบราว์เซอร์กับ dig dig อ่าน resolv.conf โดยตรงและไม่แตะ NSS เลย จึงทดสอบ stub หรือเซิร์ฟเวอร์ต้นทางแทนเส้นทางที่แอปพลิเคชันใช้ ส่วน getent hosts internal.example ผ่าน NSS และการเทียบคำตอบกับของ dig คือการวัดที่มีประโยชน์ครั้งแรก

แอปพลิเคชันที่พกตัวแก้ชื่อของตัวเองมาด้วย หรือพูด DNS ผ่าน HTTPS กับปลายทางคงที่ จะข้ามทั้งสองเส้นทาง ไม่มีอะไรใน resolv.conf หรือในสถานะของ resolved จำกัดมัน

ตรวจว่าใครเป็นเจ้าของไฟล์และมันชี้ไปที่ใด

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

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

บรรทัดแรกพิมพ์ลิงก์และปลายทางพร้อมกัน และไฟล์ธรรมดาที่สคริปต์ VPN เป็นเจ้าของหมายความว่าตัวแก้ชื่อไม่เคยถือการเขียนนั้นเป็นอินพุต เอาต์พุตสถานะระบุเซิร์ฟเวอร์แยกตามลิงก์พร้อมโดเมนเส้นทางที่กำหนดว่าคำค้นแต่ละคำไปที่ใด บรรทัด nsswitch บอกว่ามีการปรึกษา stub หรือไม่ ถ้ามีที่อยู่ stub ในไฟล์แต่ไม่มี resolve ตรงนั้น แปลว่าคำค้นไปถึงตัวฟังในเครื่องแต่ไม่มีอะไรจัดการการแยก รายการสุดท้ายก็สำคัญ เพราะโฮสต์ที่ไม่มี stub-resolv.conf ไม่ได้ใช้รูปแบบที่อธิบายไว้ที่นี่

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

ซ่อมที่เจ้าของลิงก์

การเชื่อมต่อ VPN ควรลงทะเบียนเซิร์ฟเวอร์และโดเมนของตนบนลิงก์ของตัวเอง แล้วถอนออกเมื่อตัดการเชื่อมต่อ การผสาน resolved ของ NetworkManager และตัวช่วยของไคลเอนต์เองทำงานแบบนั้น สคริปต์ที่เพียงเขียน resolv.conf ใหม่ไม่ได้ทำเช่นนั้น

บนลิงก์ที่มีอยู่แล้ว การตั้งค่าเมื่อทำงานแสดงกลไกให้เห็น resolvectl dns tun0 10.40.0.53 แนบเซิร์ฟเวอร์ และ resolvectl domain tun0 '~corp.example' แนบโดเมนเส้นทาง เครื่องหมาย tilde เป็นตัวรับน้ำหนัก มันจำกัดคำค้นของส่วนต่อท้ายนั้นไว้กับลิงก์นี้และปล่อยอย่างอื่นไว้ตามเดิม ขณะที่ค่าเดียวกันโดยไม่มีมันจะกลายเป็นโดเมนค้นหาและการแยกก็หายไป ที่อยู่เหล่านั้นเป็นตัวอย่างในห้องทดลอง ไม่ใช่คอนฟิกถาวร ยืนยันด้วย resolvectl query host.corp.example แล้วอ่านว่าลิงก์ใดตอบ

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

สถานะที่ใช้งานได้หน้าตาอย่างไร

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

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