التوجيه التكراري: عندما يلتقط النفق حزمه الخاصة
يمكن للنفق أن يلتقط الحزم التي تنشئه. قارن المسار إلى الخادم قبل تغيير المسار الافتراضي وبعده، ثم أصلح مالك ذلك المسار.
يرتفع النفق، ويُظهر السجل اكتمال المصافحة، وبعد ثانية واحدة تنتهي الجلسة نفسها وتعيد الاتصال في حلقة. لهذا النمط سبب محدد: المسار إلى الخادم يشير الآن إلى داخل النفق، لذا تُرسل الحزم التي تحمل النفق عبر النفق. لم يتغير شيء في المصادقة، ولهذا لا فائدة من إعادة إدخال بيانات الاعتماد. قارن المسار الخارجي قبل تغيير المسار وبعده، وسيصبح التكرار مرئيًا.
افحص المسار الخارجي أولًا
هناك حزمتان في الأمر، لا واحدة. الحزمة الداخلية تخص التطبيق ويجب أن تكون مشفرة، أما الحزمة الخارجية فهي موجهة إلى الخادم ويجب أن تصل إليه عبر مسار لا يعتمد على النفق.
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints
اسأل النواة عن المسار إلى عنوان الخادم بعد تشغيل النفق، ثم مرة أخرى بعد تغيير المسار الافتراضي. القفزة التالية التي تهبط على جهاز النفق هي التكرار نفسه، وهي مرئية دون أي التقاط للحزم. قد يجعل ربط الواجهة أو العلامات أو فضاء أسماء الشبكة البحث العادي غير مكتمل، لذا استخدم السياق الذي يستخدمه العميل نفسه. عندما تبدو الإجابة صحيحة لكن الجلسة ما زالت تدور، اقرأ قواعد سياسة التوجيه بدلًا من الجدول الرئيسي فقط.
لماذا تصمد الجلسة للحظة
تكتمل المصافحة قبل تثبيت المسار الجديد، لذا تبدو الثواني الأولى سليمة. وبمجرد أن يضيف العميل المسار الافتراضي، تتبعه الحزمة الخارجية التالية إلى الواجهة التي تحتاج تلك الحزمة للعبور عبرها. لا يرى الخادم شيئًا، ويعيد العميل الإرسال، فإما تنتهي المهلة أو تُقتل الجلسة وتبدأ من جديد.
يفسر هذا الترتيب لماذا قد يعمل النفق على حاسوب محمول ويفشل على موجه، ولماذا يبدأ الفشل غالبًا عند بدء حركة المرور لا عند الاتصال. ويفسر أيضًا الحلقة: كل إعادة تشغيل تعيد إنشاء الجلسة قبل أن يجعل المسار ذلك مستحيلًا.
اعرف من يملك استثناء نقطة النهاية
يرتب العملاء المدعومون استثناءهم الخاص: مسار مضيف إلى الخادم عبر البوابة الأصلية، أو علامة تُبقي المقبس الخارجي خارج النفق. السؤال هو هل أزاله شيء آخر أو تجاوزه.
في IPsec القائم على المسارات، افحص محددات السياسة التي تقرر أي الحزم تدخل النفق، وتأكد من استثناء عنوان النظير منها. وفي WireGuard، تُبقي علامة جدار الحماية للواجهة وقواعد سياستها حزم النقل خارج النفق، لذا فإن مسارًا افتراضيًا مضافًا يدويًا يمكن أن يفسد ذلك الترتيب. ملف تعريف VPN ثانٍ أو نص إداري يعيد كتابة المسار الافتراضي هو السبب الشائع. النتيجة المعتادة هي قواعد تجاوز واسعة تُضاف واحدة تلو الأخرى، فتحول خطأ في التوجيه إلى جدول لا يستطيع أحد صيانته.
أعد الفحص بعد تغيير الشبكة
مسار مضيف عبر بوابة Wi-Fi يبقى صحيحًا حتى تنتقل الآلة إلى شبكة أخرى. حينها يعود العرض نفسه دون أي تغيير في الإعدادات.
سجل عنوان نقطة النهاية، والمسار قبل الاتصال وبعده، والواجهة التي استخدمها كل منهما. هذه الحقائق الثلاث تفصل عادة بين خطأ العميل والتجاوز، وتبقى بعد الشخص الذي جمعها.
أعد الاتصال على الشبكة الجديدة وكرر القراءة. إذا غاب الاستثناء مرة أخرى، فالإصلاح مكانه في ملف التعريف الذي يملكه، لا في أمر لمرة واحدة يُكتب أثناء انقطاع.