OpenVPN เริ่มทำงานแล้วแต่ไม่พิมพ์อะไรเลย: ตรวจ log-append ก่อน

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

ความเงียบมีคำอธิบายที่ต่างกันมากสองแบบ

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

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

หาคำสั่งให้เจอ แล้วจึงหากระบวนการ

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

หาปลายทางที่กระบวนการที่กำลังทำงานใช้อยู่

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

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

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

log กับ log-append: หลักฐานและการลบ

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

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

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

เมื่อตัวห่อบริการดักเอาเอาต์พุต

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

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

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

เพิ่มระดับความละเอียดหลังจากที่คุณอ่านมันได้แล้วเท่านั้น

การเพิ่มความละเอียดก่อนหาปลายทางเพียงสร้างข้อความมากขึ้นในที่ที่คุณไม่ได้ดู

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

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