OpenVPN เริ่มไม่ขึ้นโดยไม่มีข้อผิดพลาด? ดูที่ journal

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

มีสี่ที่ที่รับเอาต์พุตไว้: journal ของ unit, ปลั๊กอินที่เป็นเจ้าของการเชื่อมต่อ, ปลายอีกด้านของอุโมงค์ และไบนารีที่ต่างจากที่คุณคิดว่ากำลังทำงาน แต่ละที่มีการตรวจสอบของตัวเอง

ความเงียบหมายความว่าคุณไม่ได้ดูช่องทางที่ถูกต้อง

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

เพิ่ม systemctl show -p Result -p ExecMainStatus openvpn-client@office เพื่อแยกการออกที่สะอาดออกจากสัญญาณ สถานะ 1 กับ Result=exit-code เป็นการตัดสินใจของโปรแกรม; Result=signal หรือ timeout ชี้ไปที่สภาพแวดล้อมแทน และการแก้ไขโปรไฟล์ไม่ว่าจะมากเพียงใดก็ไม่เปลี่ยนสิ่งนั้น บันทึกทั้งสองค่าก่อนรีสตาร์ตอะไร เพราะการรีสตาร์ตล้างสถานะชั่วคราวที่สร้างค่าเหล่านั้น

ชื่อ instance เป็นส่วนหนึ่งของเส้นทาง

unit เทมเพลตที่แพ็กเกจมาไม่รับเส้นทางไฟล์ มันรับชื่อ instance และชื่อนั้นถูกต่อเข้ากับไดเรกทอรีเพื่อหาโปรไฟล์: office ในแพ็กเกจ Debian และ Ubuntu จะแปลงเป็น /etc/openvpn/client/office.conf. ไฟล์ชื่อ office-v2.conf ที่เริ่มเป็น @office จะไม่ถูกอ่านเลย และ unit จะออกอย่างเงียบ ๆ เพราะจากมุมมองของมันไม่มีอะไรต้องทำ ไดเรกทอรีค้นหาแตกต่างกันระหว่างโหมด client และ server ดังนั้นข้อผิดพลาดเดียวกันจึงชี้ไปที่อื่นโดยสิ้นเชิงเมื่อคุณเปลี่ยนเทมเพลต

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

เมื่อปลั๊กอินเป็นเจ้าของอุโมงค์ เทอร์มินัลจะไม่เห็นอะไรเลย

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

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

ไบนารีสองตัว PATH เดียว

บิลด์ที่ติดตั้งด้วยมือใต้ /usr/local ชนะในการเรียกจากเชลล์ เพราะ /usr/local/sbin มาก่อน /usr/sbin ใน PATH เริ่มต้นของ Ubuntu unit ไม่ได้ใช้ PATH ของคุณ มันรันเส้นทางสัมบูรณ์ที่เขียนไว้ใน ExecStart. ดังนั้นเวอร์ชันที่ทำงานในเทอร์มินัลของคุณกับเวอร์ชันที่ล้มเหลวในฐานะบริการอาจเป็นโปรแกรมที่ต่างกันจริง ๆ

เปรียบเทียบทั้งสองก่อนสร้างอะไรใหม่ คำสั่งที่สามคือตัวที่ตัดสินข้อโต้แย้ง

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

ความแตกต่างของสภาพแวดล้อมอีกอย่างซ่อนอยู่ในที่เดียวกัน unit ที่แพ็กเกจมาพึ่งพาไดเรกทอรีรันไทม์ใต้ /run ที่ systemd สร้างให้ unit แทนที่ที่เขียนด้วยมือซึ่งละเว้นการตั้งค่านั้นอาจล้มเหลวก่อนเปิดไฟล์แม้แต่ไฟล์เดียว และความล้มเหลวดูเหมือนการปฏิเสธทั่วไปโดยไม่มีข้อความ OpenVPN

ความล้มเหลวที่ไคลเอนต์รายงานไม่ได้

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

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

ทำทีละชั้นตามลำดับ: unit มีอยู่และชื่อ instance ถูกต้องหรือไม่ มีอะไรไปถึง journal หรือไฟล์ --log, ไบนารีและโปรไฟล์ใดทำงานจริง และความล้มเหลวอยู่ในเครื่องหรือระยะไกล ทุกคำตอบเอาชั้นหนึ่งออก เริ่มจากโปรไฟล์หมายถึงเขียนไฟล์ที่อาจไม่เคยถูกเปิดใหม่