لماذا يموت OpenVPN بعد استيقاظ الحاسوب المحمول؟

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

أعد إنتاج الاستئناف قبل أن تؤتمته

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

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

أين يوجد خطاف السكون في systemd فعليًا

تشير أدلة كثيرة قديمة إلى /etc/pm/sleep.d، وهو دليل تملكه pm-utils ولا يستشيره تعليق قائم على systemd أبدًا. يقرأ systemd الخطافات من /usr/lib/systemd/system-sleep/ و /etc/systemd/system-sleep/، ويمرّر المرحلة أولًا والعملية ثانيًا، لذا فإن pre و post هما القيمتان الوحيدتان التي يتفرع عليهما الخطاف. احتفظ بالنسخة المحلية تحت /etc بدل تحرير ملف من الحزمة، وتذكّر أن السكربت يعمل بصلاحية الجذر في منتصف الانتقال، لذا عليه أن يعود سريعًا.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart لا يمس وحدة إلا إذا كانت نشطة أصلًا، لذا فإن نفقًا أغلقته عن قصد يبقى مغلقًا عبر الاستئناف. يمنع --no-block الخطاف من الانتظار بينما يتفاوض العميل، وهذا مهم حين لا تكون الشبكة قد نهضت بعد. معًا تعني العلامتان خطافًا يفشل بهدوء بدل أن يعطّل سلسلة الاستئناف كلها. لا يحدث شيء على الإطلاق حين تكون الوحدة متوقفة أصلًا، وهو بالضبط النتيجة التي تريدها هناك.

استعد الخدمة واترك tun0 كما هو

إن إنزال tun0 يدويًا يترك الخادم الخفي يشرف على واجهة لم يعد يملكها، والتحول التالي في الحالة ينتج أخطاء مربكة. استهدف الخدمة أو ملف تعريف اتصالها بدل الواجهة؛ تحقق من اسم الوحدة الدقيق أولًا، لأن حزم التوزيعات وOpenVPN 3 وNetworkManager تختار أسماء مختلفة. يعود ملف تعريف NetworkManager عند إعادة تدوير ذلك الاتصال، لذا فإن وحدة systemd ليست الهدف هناك. وأيًّا كان الميكانيزم، ينبغي أن يكون الفعل نفسه الذي تحققت منه يدويًا.

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

تعامل مع التوقيت الذي لا تتحكم فيه

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

تحليل الأسماء سباق منفصل، لأن مكدس شبكة سطح المكتب قد يستعيد DNS بعد أن يكون النفق قائمًا بالفعل. اختبر الاستعلامات وحدها باستخدام resolvectl query internal.example بدل استنتاجها من مسار عامل. النفق الذي يوجّه بشكل صحيح ولا يحلّ شيئًا هو مشكلة DNS، لا مشكلة خطاف.

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