รีสตาร์ตบริการตอน OpenVPN up: hooks ชนะ tun0.device

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

ตัดสินใจว่าบริการต้องการเงื่อนไขใดก่อนเลือกทริกเกอร์ เพราะตัวเลือกทั้งสามใช้แทนกันไม่ได้

ยูนิตอุปกรณ์ติดตามอะไรกันแน่

systemd สร้างยูนิตอุปกรณ์จากมุมมองของเคอร์เนลต่ออินเทอร์เฟซเครือข่าย tun0.device จึงกลายเป็นแอ็กทีฟเมื่ออินเทอร์เฟซปรากฏ และไม่แอ็กทีฟเมื่อถูกถอดออก ด้วย persist-tun การรีสตาร์ตแบบนุ่มนวลคงอินเทอร์เฟซไว้ที่เดิม ยูนิตจึงไม่กระพริบ และไม่มีอะไรที่ผูกกับมันถูกทริกเกอร์ แม้ไม่มีการคงอยู่ ยูนิตก็ไม่บอกอะไรเกี่ยวกับเส้นทาง DNS หรือว่าปลายทางไกลตอบหรือไม่

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

up, route-up และ up-restart มีความหมายต่างกัน

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

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

ส่งการกระทำโดยไม่รอ

ฮุกที่เรียก systemctl restart แบบซิงโครนัสอาจติดตายกับยูนิตที่ลำดับรอทันเนล systemctl --no-block try-restart vpn-dependent.service จัดงานเข้าคิวและกลับมา ซึ่งป้องกันไม่ให้ฮุกบล็อกการเชื่อมต่อที่มันกำลังตอบสนอง try-restart ทำงานกับยูนิตที่ทำงานอยู่เท่านั้น ขณะที่ restart ก็เริ่มยูนิตที่ไม่แอ็กทีฟด้วย เลือกอย่างตั้งใจ ไม่ใช่ตามนิสัย

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

นโยบายรีสตาร์ตอยู่ในยูนิต ไม่ใช่ในฮุก

ยูนิต oneshot ที่มี RemainAfterExit=yes ยังแอ็กทีฟอยู่หลังจากคำสั่งจบ และคำขอเริ่มที่สองไม่ทำอะไรเพราะ systemd ถือว่าเริ่มแล้ว หากการกระทำต้องทำงานทุกการเชื่อมต่อ ยูนิตต้องมีรูปแบบที่อนุญาต

After= จัดลำดับยูนิต และ BindsTo= ผูกอายุการใช้งาน แต่ทั้งสองไม่ได้หมายความว่า 'รีสตาร์ตสิ่งนี้ทุกครั้งที่ VPN เชื่อมต่อใหม่' ยูนิตที่ผูกกับทันเนลจะหยุดเมื่อทันเนลหยุด มันไม่รีสตาร์ตตัวเองเมื่อทันเนลกลับมา เว้นแต่มีบางอย่างเริ่มมันอีกครั้ง

ทดสอบการเชื่อมต่อใหม่สามครั้ง ไม่ใช่ครั้งเดียว

การบูตเย็น การรีสตาร์ตไคลเอนต์เต็มรูปแบบ และการเชื่อมต่อใหม่แบบนุ่มนวล ต่างฝึกเส้นทางที่แตกต่างกัน การเชื่อมต่อใหม่แบบนุ่มนวลคือสิ่งที่เปิดเผย up-restart ที่หายไป สภาพแวดล้อมที่ลดลง หรือยูนิตอุปกรณ์ที่ไม่เคยกลายเป็นไม่แอ็กทีฟ รันทั้งสามและยืนยันทั้งสองทิศทาง บริการทำงานเมื่อทันเนลขึ้น และไม่รีสตาร์ตเมื่อลิงก์เปลี่ยนแปลงที่ไม่เกี่ยวข้อง เช่น การโรมมิ่ง Wi-Fi

รักษาเส้นทางการกู้คืนที่เป็นอิสระเมื่อบริการที่พึ่งพาแบกการเข้าถึงของผู้ดูแลของคุณเอง ฮุกที่รีสตาร์ตสิ่งที่คุณเชื่อมต่อผ่านคือการเปลี่ยนแปลงที่อาจล็อกคุณออก