OpenVPN ส่งเซิร์ฟเวอร์ DNS มา แต่ Linux ไม่สนใจ

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

การตรวจข้อที่หนึ่ง: การเชื่อมต่อเริ่มอย่างไร

เจ้าของการเชื่อมต่อเป็นตัวกำหนดว่าใครจะใช้ค่าของตัวแปลงชื่อได้ คำสั่ง openvpn โดยตรงจากเชลล์ไม่ได้เป็นเจ้าของอะไรนอกจากโปรเซสของตัวเอง ขณะที่ยูนิต systemd, NetworkManager หรือไคลเอนต์ของผู้จำหน่ายต่างก็มีวิธีประกาศ DNS ของตัวเอง อ่านรายการโปรเซสและชื่อยูนิตก่อนจะสันนิษฐานสิ่งใด

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

จดเจ้าของไว้ก่อนดำเนินการต่อ การตรวจทุกข้อหลังจากนี้ขึ้นอยู่กับมัน

การตรวจข้อที่สอง: ลิงก์ของตัวแปลงชื่อถืออะไรอยู่จริง

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

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

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

การตรวจข้อที่สาม: เนมสเปซเลือกลิงก์นั้นหรือไม่

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

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

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

การตรวจข้อที่สี่: เจ้าของหนึ่งราย ไม่ใช่สองราย

หาก NetworkManager จัดการ VPN และสถานะของตัวแปลงชื่ออยู่แล้ว การเพิ่มสคริปต์ฮุกที่ไม่เกี่ยวข้องจะสร้างผู้เขียนที่แข่งขันกัน ฮุกที่แพ็กเกจจัดให้สำหรับ systemd-resolved เป็นการผสานรวมที่รองรับ และคาดหวังวงจรชีวิตที่เฉพาะเจาะจง: script-security 2 เส้นทาง up up-restart เส้นทาง down และ down-pre ตัวเลือกเหล่านี้ทำให้การลงทะเบียนและการถอดออกเกิดขึ้นในจังหวะที่ถูกต้อง ไม่ใช่เฉพาะเมื่อเชื่อมต่อครั้งแรก

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

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

การตรวจข้อที่ห้า: ผลลัพธ์เดิมหลังเชื่อมต่อใหม่

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

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