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

1. قرّر ما إذا كان الإدخال قديماً أم مقصوداً

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

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

2. سجّل الحقول الأربعة التي تسمّي الإدخال

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

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

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

3. عاين الإزالة ثم أزل إدخالاً واحداً

يقبل Remove-NetRoute البادئة وفهرس الواجهة نفسيهما اللذين طبعهما Get-NetRoute، وله مفتاح معاينة، فلا حاجة إلى التخمين. شغّل الزوج بهذا الترتيب:

Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42

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

4. اعثر على المكوّن الذي يعيده

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

Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore

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

5. تحقّق من البحث والجيران والملاحظة

النتيجة النظيفة ليست «اختفى المسار»؛ بل بحث يختار الآن الواجهة التي توقعتها. اسأل الآلة إلى أين ستذهب حزمة إلى البادئة المتأثرة، لأن البقايا لا تزال تسمّي الفهرس الميت بينما الجواب النظيف يسمّي الواجهة على الرابط أو البوابة الصحيحة. يجيب Find-NetRoute عن ذلك لعنوان واحد في كل مرة:

Find-NetRoute -RemoteIPAddress 10.20.4.7

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

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