إلى متى ينبغي أن يواصل OpenConnect إعادة محاولة الاتصال بشبكة VPN منقطعة؟

--reconnect-timeout يجيب عن سؤال ضيّق واحد: بعد سقوط النفق، كم تظلّ هذه العملية العميلة تحاول قبل أن تستسلم وتخرج. تسجّل صفحة دليل OpenConnect هذا الخيار بقيمة افتراضية موثّقة قدرها 300 ثانية لإعادة المحاولات التي تتبع فقدان الرابط أو توقّف الطرف الآخر عن الرد، والرقم هو موعد نهائي لعملية عميلة واحدة قيد التشغيل لا دليلًا على بقاء شبكة VPN قابلة للوصول. وهو أيضًا ليس سياسة لإبقاء العملية حيّة، وهنا يبدأ معظم الالتباس.

يتضاعف الالتباس عندما تجلس آلية ثانية فوق ذلك. فالمشرف الذي يعيد تشغيل العميل، والمراقب الذي يرسل نبضات إلى البوابة، ونافذة إعادة المحاولة المدمجة، يمكن أن تتفاعل جميعها مع عطل واحد، فتُنتج الحادثة ثلاثة خطوط زمنية لا يستطيع أحد التوفيق بينها.

ما تحكمه نافذة إعادة الاتصال فعليًا

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

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

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

إعادة تشغيل المشرف وإعادة محاولة العميل طبقتان

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

تفصيلان في ذلك السطر يحملان وزنًا. --background يفصل العملية، لذا يصبح ملف pid المقبض الوحيد الموثوق عليها، ولا تُنفق المهلة إلا ما دامت العملية نفسها حيّة؛ والمشرف الذي يقتلها لا يترك أي رصيد للمتابعة.

الانقطاعات المتعمّدة تحتاج إشارتها الخاصة. التوقف المخطط والانقطاع الحقيقي يبدوان متطابقين لمراقب ساذج، وكلاهما يُقرأ كـ«غير متصل». وجّه التوقف عبر عملية الإيقاف لدى المشرف، أو عبر علامة يفهمها الغلاف، حتى لا يطلق التوقف المتعمّد إعادة تشغيل لم يطلبها أحد.

منع تسليم المهمة من التسابق مع حلقة إعادة المحاولة

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

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

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

ما يجب التحقق منه أثناء الانقطاع وبعده

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

أبقِ الفحوصات موجهة إلى الخارج، لأن جدول العمليات يثبت القليل جدًا بمفرده. راقب ثبات ملف pid خلال الانقطاع القصير، ثم تأكد من أنه اختفى واستُبدل مرة واحدة بعد الانقطاع الطويل:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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