انقطاع VPN عند إطفاء الشاشة: قفل أم تعتيم أم تعليق؟
قفل الجلسة وتعتيم الشاشة وتعليق الجهاز ثلاثة أحداث مختلفة. اربطها بسجل journalctl قبل أن تلوم آلية الإبقاء على الاتصال في VPN.
عندما يقول أحدهم إن VPN مات حين أظلمت الشاشة، فالسؤال المفيد الأول هو أي من ثلاثة أحداث وقع فعلًا: قُفلت الجلسة، أم أُطفئت الشاشة، أم نام الجهاز كله. هذه آليات منفصلة على مؤقتات منفصلة، وواحدة منها فقط تستطيع أن تمنع جدولة أي عملية على الإطلاق. اتبع الفحوص أدناه بالترتيب. توقّف عند أول فحص يجيب عن السؤال، لأن كل فحص بعده يجيب عن شيء آخر.
الفحص الأول: افصل القفل عن التعتيم عن النوم
القفل يغيّر من يُسمح له باستخدام الجلسة؛ مدير التركيب يواصل الرسم، ومكدّس الشبكة يواصل العمل، وعميل VPN لا يلاحظ شيئًا. تعتيم الشاشة يطفئ اللوحة بعد فترة خمول ويترك الجهاز مستيقظًا تمامًا. التعليق يوقف وحدات المعالجة المركزية، أي أنه لا تُجدول أي عملية في مساحة المستخدم على الإطلاق، فلا يمكن لأي إبقاء على الاتصال أن ينطلق مهما قصّرت الفاصل الزمني.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
هذا الجدول هو سبب أن «أظلمت الشاشة» ليست تشخيصًا. حاسوب مكتبي مضبوط على التعتيم عند خمس دقائق وعلى التعليق عند ثلاثين سيعرض شاشة معتمة في الدقيقة السادسة مع نفق سليم تمامًا. الفشل عند الدقيقة الثلاثين حدث آخر بحل مختلف، وكلاهما يبدو متطابقًا من الجهة الأخرى للغرفة.
الفحص الثاني: ضع أحداث الطاقة والشبكة على خط زمني واحد
اقرأ السجل لنافذة محددة بدلًا من الإقلاع كله، وأدرج مدير تسجيل الدخول ومالك الاتصال معًا:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listالأمر الأول يُظهر طلبات النوم والاستئناف وتحولات الشبكة التي تبعتها. والثاني يُظهر ما يحتفظ حاليًا بقفل مانع، وهذا يخبرك هل يمنع شيء ما النوم عمدًا وأي برنامج هو. عدّل أسماء الوحدات إن لم يكن مالك اتصالك هو NetworkManager، وتذكّر أن قراءة وحدة مستخدم آخر أو سجل النظام تعتمد على السياسة المحلية.
السطر المفقود ليس نتيجة سلبية. إذا لم تكن وحدة السجل المختارة مرئية لحسابك، فغياب سجل التعليق لا يثبت شيئًا، واستنتاج «لم ينم قط» من مرشّح فارغ هو الطريق الذي ينتهي به الناس إلى ضبط الإبقاء على الاتصال أسبوعًا كاملًا.
الفحص الثالث: إن كان قد عُلّق، فقرّر هل كان ذلك مقصودًا
بمجرد أن يصبح انتقال النوم على الخط الزمني، يتغيّر السؤال من لماذا انكسر VPN إلى هل كان ينبغي للجهاز أن ينام أصلًا. على حاسوب محمول تكون الإجابة غالبًا نعم، وانقطاع النفق سلوك متوقع ينبغي للعميل أن يتعافى منه عند الاستئناف. وعلى محطة عمل يُفترض أن تبقى متاحة، فإن سياسة النوم هي الشيء الذي يجب تغييره. تحديد أي من هذين الجهازين تنظر إليه يتطلب سؤالًا واحدًا، وهو سؤال لا يستطيع السجل الإجابة عنه نيابةً عنك.
غيّرها من خلال عناصر التحكم التي تنتمي إلى الجلسة المسجّلة، أو من خلال آلية يدعمها المسؤول إذا كان الشرط على مستوى الجهاز كله. تحرير إعداد مدير العرض أثناء تسجيل الدخول بحساب آخر ليس الفعل نفسه، وسيبدو كأنه نجح حتى تبدأ الجلسة التالية. تعطيل إدارة الطاقة بالكامل استجابة أولى عريضة تكلّف عمر البطارية وتخفي سؤال السياسة الحقيقي.
الفحص الرابع: إن بقي مستيقظًا، فانظر إلى الشبكة والعميل
الجهاز المستيقظ الذي فقد نفقه له واحدة من ثلاث قصص: سقطت شبكة الوصول، أو توقف عميل VPN أو أُعيد تشغيله، أو أفسح الجانب الخادم للارتباط بالانتهاء بينما ظل العميل يعتقد أنه متصل. قارن الطوابع الزمنية لحدث الوصلة الأساسي مع حدث النفق، وكن دقيقًا في تحديد أيهما جاء أولًا.
ثم اختبر مسار التعافي منفصلًا عن الجلسة الأصلية. الطلب الجديد عبر النفق المتعافي قد ينجح بينما تبقى جلسة التطبيق الطويلة التي فُتحت قبل الانقطاع معطوبة، لأن التطبيق يحتفظ بمقبس قديم أو بعنوان مخزّن مؤقتًا. هذه مشكلة تطبيق، وليست دليلًا على أن النفق فشل في العودة.
ما الذي يحتويه تقرير مفيد
اكتب التسلسل مع الطوابع الزمنية والمالكين: متى قُفلت الجلسة، ومتى أُطفئت الشاشة، وهل سُجّل طلب نوم، ومتى سقطت الوصلة وعادت، ومتى غيّر النفق حالته، وماذا فعل التطبيق فعليًا. لكل بند مالك، فيمكن تسليم كل بند إلى الشخص المناسب بدلًا من أن يصبح شكوى عامة عن لينكس.
إذا كان أي من هذه الصفوف مفقودًا، فهذا هو الشيء التالي الذي يجب قياسه لا الشيء التالي الذي يجب تغييره. الخط الزمني الذي فيه فجوة أكثر إفادة من تغيير إعدادات مبني على حدس.