الرد يخرج من الشبكة المحلية لا من النفق: السبب والطريقة

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

ما الذي يقرر فعلاً خروج الحزمة

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

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

لماذا تفوز الشبكة الفرعية المحلية

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

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

تغطية الأقران ليست كالمسارات المثبّتة

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

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

اختر الجدول حسب عنوان المصدر

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

أكّد المسار ثم الخدمة

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

ما لا يصلحه هذا

اترك إعادة التوجيه وقواعد جدار الحماية وسلوك ICMPv6 على البوابة كما كانت، لأن مسار المصدر لا يستبدل أيًا منها. رسالة Packet Too Big المفقودة لا تزال تكسر الردود الكبيرة أيًّا كان الجدول الذي فاز في البحث. أصلح ذلك قبل إضافة قواعد التوجيه، وإلا سيبقى العرض بعد التغيير.

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

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