DNS ของ OpenVPN ค้างอยู่หลัง SIGKILL: ตรวจสอบเจ้าของก่อน

DNS หยุดแก้ชื่อหลังจากไคลเอนต์ OpenVPN ถูกฆ่า และสัญชาตญาณแรกคือเขียน /etc/resolv.conf ใหม่ การแก้ไขนั้นอาจทำให้ตัวแก้ไขที่ทำงานอยู่พัง ในขณะที่สถานะเก่าจริงอยู่ที่อื่น คำถามที่ต้องตัดสินก่อนคือใครเป็นเจ้าของการตั้งค่า DNS ที่อุโมงค์ติดตั้งไว้ และการออกที่ข้ามการล้างข้อมูลมีความหมายจริงหรือไม่

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

ตัดสินใจว่าเกิดการออกแบบใด

ในรุ่น Community ของ OpenVPN ทั้ง SIGINT และ SIGTERM เป็นคำขอออกอย่างเรียบร้อย SIGKILL จับไม่ได้: ไม่สามารถบล็อกหรือจัดการได้ จึงไม่มีรูทีนปิดระบบใดได้โอกาสทำงาน Ctrl+C ปกติในเทอร์มินัลเบื้องหน้าสร้าง SIGINT ขณะที่ผู้ควบคุมที่เลิกรอปกติจะยกระดับเป็น SIGKILL ความแตกต่างสำคัญเพราะมีเพียงกรณีหลังเท่านั้นที่รับประกันว่าฮุกถูกข้ามไป

การรันใน screen หรือ tmux ไม่เปลี่ยนว่าสัญญาณใดที่ Ctrl+C ส่ง ตรวจสอบว่าโปรเซสได้รับอะไรจริง ไม่ใช่สิ่งที่เทอร์มินัลปกติทำ

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

ตัดสินใจว่าใครเป็นเจ้าของตัวแก้ไข

systemd-resolved สคริปต์สไตล์ resolvconf และการเขียนไฟล์ใหม่ตรง ๆ เป็นเจ้าของที่แตกต่างกันสามราย รายแรกเก็บการตั้งค่าต่อลิงก์ไว้ในหน่วยความจำและทิ้งเมื่ออินเทอร์เฟซหายไป รายที่สองเก็บบันทึกที่คงอยู่จนมีบางอย่างลบออก รายที่สามเขียนไฟล์และปล่อยการคืนค่าให้คนที่เขียนมัน

ระบุเจ้าของก่อนเลือกคำสั่งซ่อม อาการเดียวกันมีคำตอบที่ถูกต้องต่างกันสามแบบขึ้นกับว่ากำลังใช้ตัวใด

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

ฮุก down ทำอะไรได้และทำอะไรไม่ได้

สคริปต์ down ทำงานหนึ่งครั้งหลังจากอุปกรณ์ TUN/TAP ถูกปิด การเพิ่ม down-pre กลับลำดับนั้นและรันสคริปต์ในขณะที่อุปกรณ์ยังอยู่ ซึ่งตัวช่วยที่ต้องการลิงก์ที่ยังมีชีวิตต้องใช้

ไม่มีคำสั่งใดทำให้ฮุกรันหลัง SIGKILL สิทธิพิเศษก็ไม่ถูกคืนด้วย down-pre: หากเดมอนลดลงไปที่ user หรือ group หรือเข้าไปใน chroot ฮุกจะทำงานด้วยสิทธิ์เข้าถึงที่สิ่งนั้นเหลือไว้ ฮุกที่ถูกเรียกอาจยังอัปเดตตัวแก้ไขไม่สำเร็จ เอกสารอ้างอิง OpenVPN ครอบคลุมสัญญาณและวงจรชีวิตของคอลแบ็ก

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

ตรวจสอบสถานะที่เหลืออยู่จริง

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

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

กู้คืนโดยไม่ขโมยลิงก์อื่น

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

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