تم تثبيت VPN على Windows، لكن إقلاع Linux بلا شبكة: ما الذي يجب فحصه
كل إقلاع يشغّل حزمة شبكته الخاصة، لذا لا يعمل مرشّح VPN الخاص بـ Windows داخل Linux. افحص الوصلة والعنوان والمسار وDNS قبل إعادة تعيين أي شيء.
تثبّت VPN في Windows، ثم تعيد الإقلاع إلى Linux، فتجد الاتصال السلكي ميتًا. القصة البديهية تكتب نفسها: الـ VPN ترك شيئًا خلفه. القصة خاطئة، لأن الإقلاعين يشغّلان نواتين منفصلتين بمشغّلات منفصلة وجداول توجيه منفصلة ومحلّلات أسماء منفصلة. مرشّح الشبكة في Windows لا يعمل داخل Linux، لذا فإن الخطأ إمّا في حزمة Linux أو في شيء يشترك فيه الإقلاعان حقًا، مثل العتاد أو البرنامج الثابت أو الموجّه.
العرض والاستنتاج الخاطئ
الجزء المفيد من الملاحظة هو التوقيت: ظهر الخطأ بعد تغيير. الجزء غير المفيد هو القفزة السببية إلى VPN الخاص بـ Windows، وهو لا يمكن أن يعمل في نظام التشغيل الآخر. والفصل بين الأمرين هو المهمة كلها. اكتب الخط الزمني قبل أن تلمس أي كابل.
ما يشترك فيه الإقلاعان فعلًا هو المحوّل الفيزيائي والكابل ومنفذ المبدّل وما يقع في المنبع. تلك متغيّرات مشتركة حقيقية، وتستحق فحصًا بعد فحص حزمة Linux.
التقط صورة لحزمة Linux بأربعة أوامر
ابدأ بوضع القراءة فقط وسجّل الحالة قبل تغيير أي شيء: ip -br link لوجود الواجهات، ثم ip -br address للعناوين، ثم ip route لمسارات IPv4، ثم ip -6 route حيث يهم IPv6. يفرّق مرجع أداة ip بين هذه الأجسام، وظهور واجهة في القائمة ليس دليلًا على امتلاكها عنوانًا عاملًا أو مسارًا صالحًا.
احفظ الخرج في ملف حتى تقارنه لاحقًا بإقلاع يعمل. الصورة التي لا تستطيع إعادة إنتاجها ليست إلا ذكرى لحالة.
هل المشكلة في الوصلة أم العنوان أم المسار أم الاسم؟
أربعة أعطال مختلفة تبدو متشابهة من المتصفّح. قد يكون الجهاز غائبًا تمامًا، أو موجودًا بلا حامل إشارة، أو موصولًا بلا عنوانه المتوقّع، أو معنونًا بلا مسار إلى الوجهة. وفشل تحليل الأسماء مع عمل العناوين الخام حالة خامسة، وهي تخصّ المحلّل لا المشغّل.
كل حالة تشير إلى عمل مختلف: المشغّل أو البرنامج الثابت لجهاز غائب، والكابلات أو المبدّل عند غياب الحامل، وDHCP أو التهيئة الثابتة لعنوان ناقص، والتوجيه أو السياسة لمسار مفقود. ومشكلة المحلّل تشير إلى systemd-resolved أو NetworkManager أو تهيئة DNS محلية.
تحقّق مما إذا كان تثبيت Linux يملك VPN خاصًا به أو تهيئة جدار ناري دائمة. النفق المحلي أو مجموعة قواعد nftables سبب من جهة Linux، وهو أرجح بكثير لتفسير العطل من برنامج Windows لا يعمل.
ثم قارن انتقال الإقلاع
Fast Startup في Windows إغلاق هجين يحتفظ بحالة جلسة النواة بدلًا من تنفيذ إقلاع كامل. توثيق Microsoft لحالات الطاقة يفصل بينه وبين إعادة التشغيل والإغلاق الكامل، ولهذا يمكن أن يتصرف العتاد نفسه بشكل مختلف عبر الانتقالين.
إذا كان العطل يعتمد على الانتقال من نظام تشغيل إلى الآخر، فقارن إعادة تشغيل موثّقة أو إغلاقًا كاملًا بالمسار المعتاد، بعد حفظ عملك. النتيجة التي تتبع الانتقال تبرّر فحص حالة المشغّل أو الجهاز أو البرنامج الثابت، وهي لا تثبت بحد ذاتها أن Fast Startup سبب عطلًا معينًا في المحوّل.
سجّل أي نظام تشغيل استخدم المحوّل آخر مرة، ونوع الانتقال، وحالة الوصلة في Linux، وأول عملية فشلت. الفرق القابل للتكرار بين بدء بارد وانتقال دافئ أثمن بكثير من إزالة برنامج VPN من التثبيتين دون معرفة أي حزمة انكسرت.
ما لا يجب تغييره
لا تعد ضبط حزمتي الشبكة كخطوة أولى. ذلك يدمّر المقارنة وغالبًا لا يصلح شيئًا، لأن السبب الفعلي لم يُحدَّد قط. لا تعد تثبيت VPN في Windows لإصلاح Linux، ولا تغيّر إعدادات البرنامج الثابت عشوائيًا لأن انتقال إقلاع ارتبط بعطل.
يوثّق مرجع أداة ip أجسام الوصلة والعنوان والمسار المستخدمة أعلاه. اقرأ جانب Linux أولًا، واحتفظ بالصورة، وبعد ذلك فقط قرّر ما إذا كانت طبقة العتاد المشتركة تستحق التحقيق.