كيف تميّز المسارات المدفوعة عبر VPN عن المسارات الثابتة على Linux

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

الخطوة 1: سمِّ الآلية التي تثبّت البادئات

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

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

الخطوة 2: قارن الجدول عبر اتصال

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

التقطه بالأمر ip route show table main > /tmp/route-down.txt، ثم اتصل والتقط مرة أخرى. افعل الشيء نفسه مع ip -6 route إذا كان الموقع يستخدم IPv6، لأن غياب بادئة هناك ينتج أعطالًا تبدو غير متعلقة بالتوجيه.

الخطوة 3: اقرأ المقياس، لا مجرد الوجود

يمكن أن يتعايش إدخالان للبادئة نفسها، وتختار النواة المقياس الأقل. المسار الثابت بمقياس 50 سيظل يفوز على مسار مدفوع بمقياس 100 رغم أن كليهما مرئي، ولهذا فإن «المسار موجود» و«الحركة تستخدمه» عبارتان مختلفتان.

اسأل النواة مباشرة بالأمر ip route get 10.20.5.7 واقرأ الواجهة التي يذكرها. إذا غادرت الحركة عبر المحول الفيزيائي بينما يجلس مسار النفق في الجدول، فالمقياس أو طول البادئة يفسر ذلك، لا عميل VPN. أعد البحث عن مضيف تعرف أنه خلف النفق وعن آخر تعرف أنه ليس كذلك، وسيظهر الفرق ما إذا كان التقسيم يعمل كما هو مقصود.

الخطوة 4: اعثر على الإدخالات التي تعيش أطول من النفق

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

افحص الجانب الدائم في المكان الذي يستخدمه توزيعك، سواء كان وحدة systemd-networkd أو ملف تعريف NetworkManager أو سكربت في دليل up الخاص بالعميل. إصلاح الجدول الحالي بالأمر ip route del يصمد فقط حتى الاتصال التالي. اعتبر ذلك الحذف اختبارًا للفرضية وليس الإصلاح.

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

الخطوة 5: أكّد مسار العودة قبل لوم العميل

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

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

الخطوة 6: اختبر المورد، لا ping

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

ثم أعد الفحص كله بعد إعادة الاتصال. قيمة التسلسل أنه يتنبأ بما سيفعله الاتصال التالي، ولهذا ينتمي كل من المقارنة والمقياس إلى التذكرة.