إصلاح انقطاع VPN أثناء الخمول: قائمة تحقق لتوفير طاقة Wi-Fi

عالج انقطاعات VPN أثناء الخمول بالترتيب: أكّد التوقيت، وافصل الرابط اللاسلكي عن النفق، واقرأ حالة توفير الطاقة الفعلية، ثم غيّر إعدادًا واحدًا وأعد الاختبار.

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

الفحص الأول: هل يتبع الانقطاع الخمول؟

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

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

الفحص الثاني: هل هي حركة مرور VPN فقط؟

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

إذا تدفقت حركة المرور العادية بينما يبقى النفق صامتًا، فالرابط سليم والمشكلة تكمن في مؤقتات النفق نفسها أو في طريقة تعامل العميل مع الاستئناف. هذان إصلاحان مختلفان، فلا تتخطَّ هذه الخطوة. على حاسوب محمول فيه Wi-Fi وEthernet معًا، افصل الكابل وأعد اختبار الخمول: انقطاع الخمول الذي يختفي على Ethernet السلكي دليل قوي على طبقة الاتصال اللاسلكي.

الفحص الثالث: اقرأ حالة توفير الطاقة

معظم بيئات سطح المكتب تمنحك مربع اختيار، لكن مربع الاختيار ليس الحالة التي عليها برنامج التشغيل. اقرأ تقرير برنامج التشغيل نفسه أولًا، ثم قرّر. على Linux مع mac80211 تجيب الواجهة مباشرة:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

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

على Windows يطبع powercfg /q SCHEME_CURRENT المخطط النشط، ويُظهر فرع المحول اللاسلكي ما إذا كان يمكن إخبار المحول بتوفير الطاقة؛ والاختيار نفسه موجود أيضًا في إدارة الأجهزة على تبويب إدارة الطاقة الخاص بالمحول. على macOS لا تُعرض لك حالة توفير الطاقة 802.11 لكل واجهة، لذا انظر بدلًا من ذلك إلى pmset -g لسلوك السكون والاستعداد. هناك يتبين عادة أن العطل في مسار السكون والاستيقاظ لا في سلوك الخمول للرابط اللاسلكي.

الفحص الرابع: غيّر شيئًا واحدًا ثم أعد الاختبار

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

إبقاء الاتصال نشطًا هو المتغير المستقل الآخر، ويُخلط باستمرار مع توفير الطاقة. القيمة PersistentKeepalive = 25 في WireGuard تُبقي تعيين NAT دافئًا؛OpenVPN يستخدم keepalive إلى جانب ping-restart على الطرفين. كلاهما يولّد حركة مرور على نفق صامت لولا ذلك، لذا فإن إبقاء الاتصال النشط الذي يبدو أنه يصلح الانقطاع قد يخفي مشكلة في الرابط اللاسلكي بدل أن يحلها. اختبرهما منفصلين، واحدًا في كل مرة:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

الفحص الخامس: عندما يكون الرابط اللاسلكي بريئًا

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

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

قبل أن تجعله دائمًا

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

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

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

مقالات ذات صلة