OpenVPN แสดง active (exited)? หาอินสแตนซ์ที่คุณเริ่มไว้

คุณตรวจสอบทันเนล รัน systemctl status openvpn แล้วได้ active (exited) โดยไม่มี Main PID และมีรายการโปรเซสว่าง การอ่านตามธรรมชาติคือบริการเริ่มแล้วตายไป คุณจึงเปิด unit หา /bin/true แล้วสรุปว่าแพ็กเกจเสีย ในแพ็กเกจ Debian สถานะนั้นคือ wrapper ที่ทำงานตามที่ออกแบบ และทันเนลอาศัยอยู่ใน instance unit ตัวใดตัวหนึ่งที่มันเริ่ม unit รวมจะไม่มีวันบอกคุณว่าอินสแตนซ์ใดสร้างมันขึ้นมา

active (exited) บน unit นี้หมายความว่าอะไรจริง ๆ

unit ที่แพ็กเกจมาเป็นงานครั้งเดียว: ExecStart ของมันคือ /bin/true และ RemainAfterExit=yes คือสิ่งที่ทำให้ unit ที่จบแล้วยังถูกรายงานเป็น active (exited) ถ้าถอดไดเรกทีฟนั้นออก งาน /bin/true ที่สำเร็จแบบเดียวกันจะจบใน inactive (dead) ซึ่งเป็นสถานะที่ผู้คนคาดหวังและอ่านผิดไปในทางตรงข้าม คำสั่งเป็นเพียงตัวแทน และ unit รายงานเกี่ยวกับงานที่ unit อื่นทำ ไม่มีอะไรเสียในการจัดวางนี้ และการแทนที่ /bin/true เปลี่ยนสัญญาการแพ็กเกจ ไม่ใช่ทันเนล

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

อ่านสามบรรทัดของผลลัพธ์ status ไม่ใช่คำในวงเล็บ Loaded ระบุไฟล์ unit ที่ systemd อ่าน Active มีตราเวลาของการรันสำเร็จครั้งล่าสุด และการไม่มี Main PID เข้ากับงานครั้งเดียวที่จบแล้ว สามบรรทัดนั้นยังเป็นวิธีแยก wrapper นี้ออกจากบริการที่ล้มหนึ่งวินาทีหลังเริ่ม

แสดงรายการ unit ก่อนอ่าน status อีกครั้ง

ถาม systemd ว่ามีอะไรอยู่ก่อนถามว่าอะไรกำลังทำงาน เทมเพลตอาจติดตั้งอยู่โดยยังไม่มีอินสแตนซ์ใดถูกสร้าง และมีเพียง unit ที่สร้างแล้วเท่านั้นที่พาทันเนล เริ่มจากชุดที่โหลดแล้ว:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

อ่านทั้งสองรายการด้วยกัน เพราะเทมเพลตในรายการที่สองกับอินสแตนซ์ในรายการแรกเป็นคำตอบที่ต่างกัน เทมเพลตที่มีอยู่กับอินสแตนซ์ที่ทำงานอยู่ไม่ใช่ข้อเท็จจริงเดียวกัน และมีเพียงอย่างที่สองที่หมายถึงทันเนล เลย์เอาต์แพ็กเกจยังต่างกันระหว่างดิสทริบิวชันและเวอร์ชัน OpenVPN เทมเพลต openvpn@ แบบเก่า คู่ client และ server ที่แยกกัน และ wrapper ของดิสทริบิวชันล้วนชอบด้วยกฎหมายในการแพ็กเกจของตนเอง

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

ตามชื่ออินสแตนซ์ไปยังไฟล์ที่มันอ่าน

ในเทมเพลต client upstream ไดเรกทอรีทำงานของ unit คือ /etc/openvpn/client และคำสั่งของมันดึง %i.conf จากที่นั่น ดังนั้น openvpn-client@office อ่าน /etc/openvpn/client/office.conf ยืนยันการแมปนั้นบน unit ที่ติดตั้งแทนการเชื่อมตัวอย่าง เพราะเทมเพลตที่คุณมีอาจเก่ากว่าหรือถูกดิสทริบิวชันเขียนใหม่:

systemctl cat [email protected]

อ่าน drop-in ที่ปรากฏท้ายผลลัพธ์นั้น เพราะไฟล์ใต้ .d/ เปลี่ยน ExecStart ไดเรกทอรีทำงาน หรือเส้นทางการกำหนดค่าได้ โปรไฟล์ที่คุณดาวน์โหลดเป็น office.ovpn ไม่ใช่ ไฟล์ที่อินสแตนซ์เปิด ช่องว่างนั้นคือสาเหตุปกติที่ข้อผิดพลาดระบุเส้นทางที่คุณไม่เคยแก้ไข

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

เริ่มมัน แล้วอ่านบันทึกของอินสแตนซ์นั้น

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

การเริ่มกับการเปิดใช้งานเป็นการตัดสินใจแยกกัน: start รัน unit ตอนนี้ enable จัดการบูตถัดไป และ enable --now ทำทั้งสองอย่างในขั้นเดียว daemon-reload อ่านนิยาม unit ใหม่ ไม่รีสตาร์ตโปรเซสที่ทำงานอยู่ และไม่ใช้โปรไฟล์ที่แก้ไข หลังจากแก้ไขโปรไฟล์แล้ว ให้รีสตาร์ตอินสแตนซ์ เพราะนั่นคือสิ่งที่อ่านไฟล์ใหม่

อย่าวางตัวจัดการตัวที่สองบนทันเนลเดียวกัน

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

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

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