ทำไมไคลเอนต์ OpenVPN ของคุณจึงยังล่มอยู่หลังหมดเวลาหนึ่งครั้ง

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

เริ่มจากสิ่งที่ยูนิตทำจริง ไม่ใช่จากสิ่งที่การมอนิเตอร์อ้าง systemctl status openvpn-client@office และ journalctl -u openvpn-client@office -n 50 แสดงเหตุผลของการออกและบรรทัดสุดท้ายที่ไคลเอนต์เขียนไว้ก่อนจากไป

โปรเซสออกไปก่อนที่ใครจะสังเกตเห็น

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

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

เลือกระหว่าง ping-exit กับ ping-restart

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

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

การกำกับดูแลที่รีสตาร์ตยูนิตจริง

บนโฮสต์ systemd การเปลี่ยนแปลงถาวรที่เล็กที่สุดคือไฟล์ drop-in หนึ่งไฟล์: Restart=on-failure และ RestartSec=10 ใน /etc/systemd/system/[email protected]/restart.conf ไฟล์ drop-in จะถูกอ่านก็ต่อเมื่อ systemd โหลดคำจำกัดความของตัวเองใหม่ จึงรัน systemctl daemon-reload หลังจากนั้น ตรวจสอบด้วย systemctl show -p Restart -p ExecMainStatus openvpn-client@office แทนการถือว่าค่าลงแล้ว สถานะในชื่อไฟล์ต้องเป็นโปรไฟล์ที่ยูนิตโหลดจริง ดังนั้นไฟล์ที่เขียนสำหรับ office จึงไม่มีผลกับ openvpn-client@home

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

Restart=always ยังทำงานหลังการหยุดโดยเจตนา ใช้ systemctl stop สำหรับงานบำรุงรักษา และมาสก์ยูนิตหากต้องให้มันปิดอยู่ระหว่างที่คุณทำงาน

จับการรั่วไหลขณะที่อุโมงค์ล่ม

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

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

ทดสอบโดยหยุดไคลเอนต์โดยเจตนา รัน systemctl stop openvpn-client@office แล้วจึง curl -m 5 https://example.com ซึ่งควรล้มเหลวแทนที่จะสำเร็จผ่านลิงก์จริง ความสำเร็จหมายความว่ากฎไฟร์วอลล์ขาดหายหรืออนุญาตมากเกินไป

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