‏VPN يقول إنه متصل لكن المسار الافتراضي ميت

يُبلّغ العميل بأنه متصل، وأيقونة شريط النظام تبدو طبيعية، ولا شيء يُحمَّل. بدأت المشكلة مباشرة بعد انتقالك من Wi-Fi إلى كابل، أو مباشرة بعد انتهاء ترقية التوزيعة. الذي تعطّل ليس الملف الشخصي بل الحالة التي بُنيت لاتصال الأساس السابق. لا يزال في النواة مسار افتراضي يشير إلى جهاز نفق لا يملكه أحد، أو لا يزال المُحلِّل يسرد خوادم على وصلة اختفت. كلا الفشلين يبدوان كشبكة ميتة، وكلاهما قابل للإصلاح في مكانه.

الأجزاء القديمة كانت خاطئة أصلًا قبل أن تلاحظها. مجرد فصل الكابل جعلها مرئية.

اسأل النواة إلى أين ستذهب الحزمة

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

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

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

المُحلِّل يحتفظ بالوصلة الميتة أيضًا

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

resolvectl status
resolvectl query intranet.example.com

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

أصلح التسجيل بدلًا من /etc/resolv.conf. في إصدارات Ubuntu وFedora الحالية ذلك المسار رابط رمزي إلى حالة المُحلِّل وقت التشغيل، لذا فإن أي تعديل إما يُتجاهل أو يُستبدل عند أول حدث شبكي.

‏VPN لا يبدأ من تلقاء نفسه أبدًا

يرفع NetworkManager الـVPN فوق اتصال أساس، ويتعلّم أي أساس يتبعه من connection.secondaries الموجود على ذلك الأساس. ويذكر مرجع إعدادات الاتصال صراحةً أن الاتصال التلقائي غير مُنفّذ لملفات VPN. وهذه هي الآلية الكاملة وراء هذه الفئة من الأعطال: غيّر الأساس، فيصبح على الـVPN أن يُقرن من جديد أو يُنشّط يدويًا.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

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

قد تُسقط الترقية إعدادات دون رسالة

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

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

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

ثلاث حالات وثلاثة إصلاحات مختلفة

حدّد في أي حالة أنت قبل أن تلمس أي شيء، لأن إعادة التشغيل تدمّر الدليل ويعود العطل عند أول تغيّر شبكي.

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