OpenVPN เริ่มไม่ขึ้น: อ่านบรรทัดแรก ไม่ใช่ไฟล์คอนฟิก

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

มีคำสั่งอ่านอย่างเดียวสามคำสั่งที่พาไปถึงตรงนั้น: journalctl -u openvpn@server -b --no-pager ก่อน systemctl status openvpn@server ต่อมา และ ss -lunp สำหรับผู้รับฟัง UDP และเจ้าของของมัน

บรรทัดแรกเป็นตัวเลือกสาขา

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

ระวังลูปพยายามซ้ำที่ซ่อนบรรทัดเดิมไว้ ยูนิตที่มี นโยบายรีสตาร์ต อาจฝังความล้มเหลวแรกไว้ใต้บรรทัดที่เหมือนกันเป็นโหล ดังนั้น journalctl -b ที่กรองตามยูนิตและอ่านจากด้านบนจึงดีกว่าอ่านจากท้าย

ใครอีกที่ถือพอร์ต 1194

ตัวการมักไม่ใช่เซิร์ฟเวอร์ตัวที่สองที่ใครตั้งใจกำหนดค่า ให้คาดว่าจะเป็นไคลเอนต์ที่เริ่มด้วยมือซึ่งยังมีชีวิตอยู่ในเทอร์มินัลอื่น โปรไฟล์ที่สองที่บังเอิญเลือกพอร์ตเดียวกัน หรือชุดของผู้ขายที่อุโมงค์ของมันเองถือ 1194 อยู่ เจ้าของซ็อกเก็ตปรากฏใน ss -lunp ส่ง PID นั้นให้ systemctl status เพื่อดูว่ามียูนิตใดรับผิดชอบ หยุดมันผ่านเส้นทางควบคุมของมันเอง ไม่ใช่ด้วยสัญญาณ

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

ยูนิตที่หลงเหลือหลังการล้าง

การล้างจะลบไบนารี แต่ไฟล์ยูนิตที่เขียนด้วยมือ ซึ่งมักอยู่ใต้ /etc/systemd/system จะรอดไปได้ Systemd จึงพยายามซ้ำกับยูนิตที่ชี้ไปยังเส้นทางที่ไม่มีอยู่แล้ว และข้อความนั้นเกี่ยวกับไฟล์ที่หายไป ไม่ใช่การถอนเมื่อวาน systemctl status แสดงเส้นทางชิ้นส่วนของยูนิตไว้ใกล้ด้านบน ดังนั้นตรวจสอบด้วย dpkg -S ก่อนจะลบอะไร เมื่อกำพร้าหมดไป systemctl daemon-reload และ systemctl reset-failed จะล้างสถานะ มิฉะนั้นการตรวจสถานะครั้งต่อ ๆ ไปจะรับมันมา

เมื่อ which openvpn ตอบกลับด้วยอะไรบางอย่างใต้ /usr/local ไบนารีที่ใช้งานอยู่มาจากตัวติดตั้งของผู้ขาย ไม่ใช่จาก apt ตัวติดตั้งแบบนี้มักนำผู้รับฟังของตัวเอง รายการบูตของตัวเอง และไดเรกทอรีคอนฟิกของตัวเองมาด้วย ดังนั้นการลบคำสั่งที่มองเห็นจึงทิ้งซ็อกเก็ตไว้ถูกครอบครอง

ถอนการติดตั้งด้วยวิธีที่ผู้ขายระบุ ยืนยันว่าพอร์ตว่างด้วย ss -lunp และเพิ่มไคลเอนต์ของดิสทริบิวชันเฉพาะเมื่อคุณต้องการมัน

จัดสถานะให้เรียบร้อยก่อนลองใหม่

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

จดสาขาที่คุณเลือกไว้: พอร์ตชนกัน ไบนารีหาย คอนฟิกหาย ครั้งต่อไปจะจำได้เร็วขึ้น