انقطاع VPN عند إطفاء الشاشة: أي دورة حياة؟

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

ثلاثة أعطال تبدو متطابقة

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

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

مقارنة النشط والخامل تحت السيطرة

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

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

قراءة سياسة الخلفية في المنصة

على أندرويد تكون دورة حياة خدمة VPN جزءًا من المنصة، و«always-on» و«block-without-VPN» مفتاحان منفصلان بتأثيرين منفصلين. العميل غير المفعل دائمًا يمكن إيقافه عندما يستعيد النظام الموارد، ولا يغيّر أي إعداد داخل التطبيق ذلك. يفرض iOS حدوده الخاصة على مزوّد النفق، والسلوك الموثق يختلف عن خدمة سطح مكتب تستمر ببساطة في العمل. اقرأ وثائق المنصة للمكوّن المعني بدلًا من دليل عام لتحسين البطارية.

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

ما يفعله الجهاز بعد الاستيقاظ

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

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