لماذا يبقى عميل 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 يجعل الجهاز يعيش أطول من الجلسة ويبلغ الفحص عن صحة بينما لا شيء يُنقل.