VPN يقول متصل لكن لا شيء يُوجَّه: مكانان للفحص

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

أولًا، اسأل النواة أي جهاز ستستخدمه

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

الحالة الثانية هي المعتادة بعد أن يحل كابل محل الشبكة اللاسلكية، وهي تعرض نفسها كـ VPN معطّل.

ip route show default
ip route get 203.0.113.9

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

ثم اقرأ المحلِّل لكل ارتباط، لا لكل ملف

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

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

resolvectl status
resolvectl query app.internal.example

إذا حُلّت العناوين وفشلت الاتصالات، فالمحلِّل سليم والمسار ليس كذلك. وإذا لم تُحلّ العناوين إطلاقًا، فهذا هو المكان الصحيح للبدء.

كيف ينجو مسار قديم من التغيير

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

ملف VPN لا يرفع نفسه، لذا فإن الاقتران أهم بكثير من تفضيل الاتصال التلقائي للملف نفسه.

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

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

ميّز الحالة القديمة من الأب المفقود

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

إعادة التشغيل تخفي أي الثلاث حالات كانت لديك، ولهذا بالضبط تبدو كإصلاح.

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