خطاف الإسبات وحده لا يُعيد شبكة VPN إلى العمل

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

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

الخطاف يعمل، ثم ماذا؟

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

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

تعامل مع وسيط المرحلة كجزء من التصميم. محاولة إعادة الاتصال في المرحلة السابقة pre تحدث بينما الآلة على وشك أن تفقد كل شيء، ولا يمكن أن تنجح.

الجذر وبيئة محدودة ومستخدم خاطئ

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

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

الاتصال التلقائي ليس مسار الـVPN

يقدّم NetworkManager آليتي تفعيل: علم اتصال تلقائي على الملف الشخصي، واتصالات ثانوية تبدأ عند تفعيل ملف أساسي. أنواع الأجهزة الأصلية تنفّذ الأولى؛ أما إضافات VPN فقد نفّذت تاريخياً الثانية فقط، لذا قد لا يكون لتحديد الاتصال التلقائي على ملف OpenVPN أي أثر على الإطلاق. افحص الخاصيتين، ثم اربط VPN كاتصال ثانوي لملف Wi-Fi أو Ethernet بدلاً من ذلك.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

واجهة WireGuard يديرها وحدة systemd تحتاج إلى ذلك الملف الإضافي بدلاً من خطاف، مرتباً بعد أن تصبح الشبكة متصلة.

انتظر الشبكة، بحدٍّ أقصى

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

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

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

علّق النظام مرة واحدة، ثم اقرأ السجل بحثاً عن مخرجات الخطاف نفسه. هذا هو الاختبار الوحيد الذي يثبت الترتيب.