VPN ميت بعد السكون: نفق سقط أم تطبيق قديم؟

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

ثلاثة أشياء يمكن أن تتعطل بعد الاستيقاظ

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

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

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

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

أولًا: هل عاد النفق؟

انظر إلى الواجهة وحالة النظير بدلًا من نص الحالة الخاص بالعميل. الواجهة التي تحمل عنوانًا بلا مصافحة حديثة نفق قائم بالاسم فقط.

ip -brief addr show
wg show
ip route show table all | head -20

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

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

ثانيًا: هل طلب شيء عودته؟

هنا تُثبت المقارنة قيمتها. ملف إضافة OpenVPN واتصال WireGuard الأصلي يعالجهما NetworkManager بشكل مختلف، كما أن مرجع إعدادات الاتصال صريح في أن connection.autoconnect لا ينشّط ملفات VPN؛ والآلية التي ترفع VPN مع اتصال هي connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

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

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

ثالثًا: هل يحتفظ التطبيق بحالة قديمة؟

افتح جلسة جديدة تمامًا إلى الوجهة نفسها قبل أن تلمس VPN. إذا نجحت الجلسة الجديدة وفشلت القديمة، فالنفق سليم والتطبيق يمسك اتصالًا ميتًا.

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

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

اجعل المقارنة قابلة للتكرار

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

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

لا يظهر keepalive الدائم في WireGuard في هذه الصورة إلا كـ keepalive لتعيين NAT. إنه يرسل حزمًا لإبقاء تعيين مفتوحًا؛ ولا يمنع الجهاز من السكون ولا يستطيع مواصلة الإرسال بينما العملية معلّقة.

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