OpenVPN เมื่อบูตบน Ubuntu: NetworkManager หรือ systemd?

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

ทุกอย่างที่เหลือ ตั้งแต่การติดตั้งเส้นทางจนถึงพฤติกรรมการเชื่อมต่อใหม่ ล้วนตามมาจากการตัดสินใจแรกนั้น

พวงกุญแจคือความแตกต่างที่ไม่มีใครพูดถึง

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

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

การผูก VPN เข้ากับการเชื่อมต่อไม่ใช่การรับประกันการบูต

ใน nm-connection-editor ให้เลือกการเชื่อมต่อแบบมีสายหรือไร้สายแทน VPN เปิดแท็บ General ติ๊กตัวเลือกเชื่อมต่อ VPN อัตโนมัติ และตั้งชื่อโปรไฟล์ จากนั้น NetworkManager จะเปิดใช้งาน VPN เป็นการเชื่อมต่อรองเมื่อการเชื่อมต่อหลักเข้าสู่สถานะเชื่อมต่อแล้ว นี่คือการพึ่งพา ไม่ใช่กฎไฟร์วอลล์ แพ็กเก็ตยังออกไปได้ในช่วงวินาทีก่อนอุโมงค์จะขึ้น และความลับที่บันทึกไว้ซึ่งปลดล็อกไม่ได้จะทำให้เครื่องออนไลน์โดยไม่มีอุโมงค์

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

อินสแตนซ์ systemd ต้องการชื่อไฟล์ที่ตรงกัน

วางโปรไฟล์ไว้ในไดเรกทอรีไคลเอนต์ที่แพ็กเกจคาดหวัง เช่น /etc/openvpn/client/office.conf และอ้างอิงไฟล์ข้อมูลรับรองจากภายในด้วย auth-user-pass office.cred ชื่ออินสแตนซ์คือชื่อไฟล์ที่ไม่มีส่วนขยาย ดังนั้น openvpn-client@office จึงอ่าน office.conf เปิดใช้งานด้วย sudo systemctl enable --now openvpn-client@office และยืนยันการจับคู่ด้วย systemctl cat openvpn-client@office แทนที่จะเชื่อตัวอย่างจากบล็อก

เส้นทางภายในโปรไฟล์ถูกแก้ไขโดยอิงไดเรกทอรีทำงานของยูนิต ไม่ใช่ตัวโปรไฟล์เอง บรรทัด ca หรือ auth-user-pass แบบสัมพัทธ์จึงอาจล้มเหลวตอนบูตทั้งที่ทำงานเมื่อทดสอบด้วยมือ ใช้เส้นทางแบบสัมบูรณ์สำหรับทุกสิ่งที่ยูนิตต้องหา จากนั้นอ่าน journalctl -u openvpn-client@office -b หลังบูตจริง ยูนิตที่รายงานว่าทำงานอยู่โดยไม่มีอุโมงค์มักระบุไฟล์ที่หายไปในบันทึกนั้น

แพ็กเกจรุ่นเก่ามีชื่อเทมเพลตที่ต่างออกไป ดังนั้น systemctl list-unit-files 'openvpn*' จะตัดสินว่าแบบใดมีอยู่ในโฮสต์นี้

พฤติกรรมการเชื่อมต่อใหม่เป็นการตัดสินใจแยกต่างหาก

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

การหยุดก็ตรงตัวเช่นกัน: sudo systemctl disable --now openvpn-client@office หยุดอินสแตนซ์ที่ทำงานอยู่และลบลิงก์บูต การปิดใช้งานอย่างเดียวจะปล่อยให้อุโมงค์ทำงานจนกว่าจะรีบูตครั้งถัดไป ซึ่งทำให้ใครก็ตามที่ทดสอบด้วยการปิดใช้งานแล้วเห็นอินเทอร์เฟซยังขึ้นอยู่ต้องประหลาดใจ

รีบูต แล้วตรวจสี่อย่างตามลำดับ

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

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

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