المضيف يصل إلى نظير IPsec، وحاوية Docker لا

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

يتتبع العرض أدناه وجهة واحدة عبر مصدرين، ويقرأ الحالة قبل تغيير أي شيء.

ابدأ بوجهة واحدة ومصدرين

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

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

اقرأ السياسات قبل أن تلمس Docker

تغطي فحوص المضيف للقراءة فقط قرارات التوجيه وقاعدة بيانات السياسات والقواعد التي تختار بينها:

ip rule show
ip route show table all
ip xfrm policy

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

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

تحقق من التصفية والترجمة بالترتيب

يمكن لجدار حماية الجسر في Linux الخاص بـ Docker أن يحجب إعادة التوجيه بشكل مستقل عن IPsec. مع خلفية iptables، افحص مسار FORWARD وقرارات DOCKER-USER، متذكرًا أن قاعدة أُضيفت بعد حكم سابق قد لا تُنفذ أبدًا. تتكامل خلفية nftables بشكل مختلف، لذا لا تنشئ سلسلة DOCKER-USER لمجرد أن مثال iptables سماها كذلك؛ تحقق من الخلفية التي يستخدمها عفريتك فعليًا.

ثم تحقق من ترجمة المصدر. قد تحوّل قاعدة MASQUERADE الواسعة حزمة كانت تطابق محدد IPsec إلى حزمة لم تعد تطابقه، ويبدو العطل تمامًا كمشكلة توجيه. دليل إعادة التوجيه من strongSwan يوثق استثناء NAT اللازم قبل هذه الترجمة للحركة التي تطابق سياسة بالفعل.

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

ثم قرر: موجّه أم مترجم

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

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

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

تحقق باتصال جديد لا بإعادة تشغيل

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

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