keepalive في OpenVPN أم إعادة تشغيل systemd: أيّهما يستعيد النفق؟

ثمة ثلاثة أشياء مختلفة قد تسوء في النفق، و لكل منها ردّ فعل مختلف. فقد يتوقف الطرف الآخر عن الرد، أو تموت عملية الخدمة الخفية، أو يتوقف التطبيق الذي يعمل خلف النفق عن تقديم خدمته. والإعداد الذي يعيد تشغيل الخدمة عند أيٍّ منها ليس إشرافًا دقيقًا؛ بل هو إجراء واحد فظّ يُطبَّق على أعطال غير مترابطة. ومقارنة ما يمكن لكل آلية أن ترصده فعلًا تجعل تقسيم العمل واضحًا.

ثلاثة أعطال تبدو كعطل واحد

صمت الطرف الآخر يعني أنه توقف عن الإرسال، و OpenVPN يستطيع كشف ذلك بنفسه لأنه يملك نبضة الحياة. وموت العملية يعني أن الخدمة الخفية خرجت، وهو ما يلحظه مدير الخدمات ولا يستطيع OpenVPN ملاحظته. وفشل التطبيق يعني أن النفق سليم وأن شيئًا خلفه ليس كذلك، ولا تملك أي من الآليتين الأخريين سبيلًا لمعرفة ذلك. وكل حالة تحتاج ردًّا مختلفًا، ولا واحدة منها تشبه ملاحظة أن النفق قائم.

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

اكتب الحالات الثلاث قبل تغيير أي مؤقت. والقائمة نفسها تُظهر عادةً أن آلية واحدة يُطلب منها تغطية الثلاث جميعًا.

إلى ماذا يتمدد keepalive فعلًا

توجيه keepalive اختصار، والتمدد يختلف بحسب الوضع. فعلى الخادم يتحول keepalive 10 60 إلى ping محلي كل عشر ثوانٍ، ومهلة إعادة تشغيل محلية مقدارها 120 ثانية، وقيمتين 10 و60 تُدفعان إلى العملاء. ومهلة الخادم تُضاعف عن قصد حتى يحصل العميل على فرصة لإعادة التشغيل قبل أن يستسلم الخادم. واقرأ الصيغة الممددة في الإعداد الجاري لا الاختصار في الملف الشخصي.

هذه المضاعفة هي سبب خطأ أي وصف يزعم أن الطرفين يعيدان التشغيل بعد ستين ثانية. وهي تفسر أيضًا لماذا لا يرفرف الطرفان بالتوازي عندما يتدهور المسار.

نبضة الحياة هي حركة نظراء OpenVPN، وليست مسبار ICMP لبعض المضيفين العامين. والرد يثبت فقط أن الطرف البعيد من النفق حي. ولا يقول شيئًا عن قاعدة البيانات أو خدمة الويب التي يحتاجها المستخدم فعلًا.

ما لا يراقبه Restart=on-failure

اقرأ الوحدة المثبتة قبل إضافة تجاوز. و Restart=on-failure يستجيب لحالات فشل العملية الموثقة، وهذا ليس مثل مراقبة حالة الاتصال. وهو لا يُطلق لأن إعادة اتصال داخلية بدأت، وللخروج النظيف دلالة مختلفة عن الانهيار.

هذا التمييز مهم لأن إعادة التشغيل الداخلية تبقي العملية نفسها حية. فالوحدة لا ترى شيئًا، والنفق يستعيد نفسه، وتلك هي النتيجة الصحيحة.

اضبط RestartSec وحدود البدء عن قصد، وإلا فإن حلقة انهيار ستنهك البوابة وتدفن الخطأ الحقيقي تحت رسائل إعادة التشغيل. وحد إعادة التشغيل الذي يُطلَق يترك الوحدة فاشلة، وهو أمر مرئي، أما الحلقة غير المحدودة فليست كذلك.

ping-restart و ping-exit ليسا قابلين للتبادل

ping-restart يطلق إعادة التشغيل الداخلية في OpenVPN ويبقي العملية. و ping-exit ينهي العملية عند المهلة نفسها، وهذا يسلم القرار إلى مدير الخدمات. وهما متعارضان، واختيار الثاني يغير من يملك الاستعادة. والفرق هو من يقرر المحاولة مرة أخرى، وكم من الحالة ينجو من المحاولة.

إذا اخترت الخروج عند انتهاء المهلة، فتحتاج الوحدة إلى سياسة إعادة تشغيل ومعالجة لحالة الخروج تتوافقان، وإلا بدا فشل الحياة كتوقف دائم. ويمكن لخيارات الاستمرارية أيضًا حفظ الواجهات والمسارات عبر إعادة تشغيل داخلية، لكن ليس عبر خروج العملية.

اختر دورة حياة واحدة لكل عملية نشر واكتب سببها. فالملف الشخصي الذي يحمل التوجيهين معًا هو ملف لم يقرر بعد.

اختبر كل فشل كحالة مستقلة

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

الاستعادة المتكررة ليست إصلاحًا أيضًا. فبيانات الاعتماد المرفوضة أو عميلان يتشاركان اسمًا فعّالًا سيظلان يتبادلان الحلول، والمؤقتات الأسرع تجعل ذلك الرفرفة أسرع فقط.