هل تخفي ذاكرة مسارات VPN تغييرك؟ افحص ثلاثة أمور

تفريغ ذاكرة المسارات هو أول ما يتبادر إلى الذهن عندما لا يسري تغيير، وهو على Linux الحديث جهد مهدور: أُزيلت ذاكرة مسارات IPv4 العامة منذ سنوات، لذا لا يطبع ip route show cache شيئًا ولا يوجد ما يُمسح. الحالة التي تخدعك تعيش طبقةً أعلى: في مقبس، أو تعيين NAT، أو مُحلِّل، أو مدير شبكة أعاد تطبيق ملف التعريف القديم. ثلاثة أسئلة تفصل بين هذه الحالات: هل يأتي المسار الخاطئ من تدفق جديد أم من اتصال قديم، وهل تخزّن منصتك المسارات أساسًا، وهل الحالة في التوجيه أم فوقه. أجب عنها قبل أن تعيد ضبط واجهة.

الفحص الأول: هل يأتي المسار القديم من تدفق جديد؟

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

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

إذا سلك تدفق جديد المسار الصحيح ولم يتعافَ القديم، فتوقف عن النظر إلى التوجيه. كان المسار صحيحًا؛ وكانت الجلسة قديمة.

الفحص الثاني: هل تحتفظ منصتك بذاكرة مسارات أصلًا؟

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

تختلف المنصات الأخرى، وهنا يخطئ نسخ النصائح. تحتفظ Windows بذاكرة وجهة يمكنك مسحها عبر netsh interface ip delete destinationcache. تعرض BSD وmacOS عمليات بحث لكل وجهة عبر route -n get، وتنتهي ذاكراتها وفق جدولها الخاص. الأمر الذي يعمل على إحداها لا يفعل شيئًا على Linux إطلاقًا، ولهذا يبدو الإصلاح نفسه فاشلًا لنصف من يجربه.

جدول NAT أو conntrack ليس ذاكرة مسارات، وإن أنتج العَرَض نفسه. التدفق الذي تُرجم قبل تغييرك يحتفظ بترجمته، وسيظهره conntrack -L بعد أن تكون سياسة التوجيه قد تغيّرت بمدة طويلة. تلك حالة قديمة، لكن مسح المسارات لن يمسها.

الفحص الثالث: هل الحالة في التوجيه أم فوقه؟

اقرأ البحث الحالي قبل أي شيء آخر: ip route get للوجهة، ثم الأمر نفسه مع from وعنوان المصدر، ثم ip rule show. إذا اتفقت هذه الثلاثة مع ما قصدته، فالتوجيه ليس الطبقة التي يجب إصلاحها، وجاءت الملاحظة القديمة من مكان آخر.

ثلاثة مشتبه بهم شائعون يجلسون فوق التوجيه. يمكن لمدير شبكة أن يعيد تركيب مسار من ملف تعريف محفوظ بعد ثوانٍ من حذفه، فيبدو تغييرك وكأنه ارتد؛ افحص nmcli connection show --active وحالة الوحدة قبل تعديل الجدول مرة أخرى. تعيد ذاكرة المُحلِّل عنوانًا قديمًا، وهو ما يبدو فشل توجيه حتى تستعلم عن الاسم نفسه بأداة تكسر الذاكرة. تحتفظ مجموعة اتصالات التطبيق بمقبس عامل إلى الوجهة القديمة ولا تسأل النواة أبدًا عن قرار جديد.

ما تسمح لك الإجابات الثلاث باستنتاجه

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

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

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

أبقِ الحالات الثلاث منفصلة في ملاحظاتك

الإعداد المحفوظ والبحث الحالي والتدفق المرصود ثلاثة حقائق مختلفة، ودمجها في «الذاكرة» هو ما يجعل العطل صعب التكرار. اكتب ملف التعريف أو الوحدة التي تملك المسار، ومخرجات ip route get، ومصدر الاتصال الفعلي ووجهته.

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