إعادة تشغيل خدمة عند حدث up في OpenVPN: الخطافات أفضل من 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.

احتفظ بمسار استرداد مستقل عندما تحمل الخدمة التابعة وصول الإدارة الخاص بك. الخطاف الذي يعيد تشغيل الشيء الذي تتصل عبره تغيير قد يمنعك من الدخول.