ยูนิต -.mount ถูกมาสก์: ไคลเอนต์ OpenVPN จะไม่เริ่มทำงาน

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

ข้อผิดพลาดระบุชื่อเมานต์ราก ไม่ใช่โปรไฟล์ของคุณ

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

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

ดูไดเรกทอรีขณะรันก่อนที่คุณจะดีบัก OpenVPN

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

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

เครื่องปกติไม่มีไฟล์แบบนั้น และรายการที่ถูกมาสก์ไม่มีเมานต์ราก ถ้าคำสั่งแรกพิมพ์ลิงก์สัญลักษณ์ไปยัง /dev/null แสดงว่าการวินิจฉัยชัดเจน ไดเรกทอรีเดียวกันอาจมีมาสก์ tmp.mount ที่สร้างโดยเครื่องมือเดียวกัน และนั่นทำให้เกิดความล้มเหลวประเภทเดียวกันภายใต้ชื่ออื่น ให้ดูไดเรกทอรีทั้งหมด ไม่ใช่แค่ชื่อในข้อผิดพลาด

ls -la /run/systemd/system/*.mount

ถ้าไดเรกทอรีสะอาดและยูนิตยังถูกมาสก์ การมาสก์อยู่ที่อื่นในเส้นทางการค้นหา และ systemctl cat -.mount จะแสดงว่าไฟล์ใดถูกโหลด

ลบไฟล์ โหลดใหม่ แล้วเริ่มอีกครั้ง

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

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

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

journalctl -u [email protected] -b --no-pager

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

ป้องกันไม่ให้มันกลับมาจากอิมเมจ

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

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

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