نشر منافذ Docker ومصادر VPN: مطابقتان تفوتهما

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

الأسطورة: اسمح بخادم VPN وكل شيء انتهى

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

لذا فإن عبارة عنوان IP لخادم VPN تصف افتراضًا لا ملاحظة. وإلى أن تعرف أي التصميمين أمامك، تبقى القاعدة تخمينًا.

المصدر: تجمع العملاء أم بوابة مترجَمة

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

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

المنفذ: DNAT يغيّر الرقم الذي تطابقه

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

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

حدّد أي رقم يعبّر عن القصد. طابِق منفذ الحاوية بعد DNAT عندما تحمي القاعدة الخدمة داخل الحاوية. وطابِق الوجهة الأصلية بخيار conntrack عندما يجب أن تصف القاعدة ما طلبه العميل، واقبل كلفة المطابقة الإضافية وعناية ترتيب القواعد التي تأتي معها.

السلسلة: DOCKER-USER لا INPUT

يضع دليل iptables الخاص بـ Docker سياسة تمرير المستخدم في سلسلة DOCKER-USER، التي تُقيَّم قبل قواعد التمرير الخاصة بـ Docker. أما القاعدة المنسوخة من خدمة على المضيف إلى سلسلة INPUT فتصفّي حركة موجهة إلى المضيف، لا حركة تُمرَّر إلى حاوية. ذلك الخطأ ينتج قاعدة تبدو صحيحة ولا أثر لها على مسار الحاوية.

أبقِ نطاق المصدر ومنفذ الوجهة الفعلي والبروتوكول وواجهة الدخول معًا في القاعدة نفسها. فقبول المصدر وحده لكل وجهة مُمرَّرة أوسع من السماح بخدمة منشورة واحدة.

تحقّق باتصالات جديدة

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

يوثّق دليل iptables في Docker ترتيب السلاسل وسلوك ترجمة المنفذ وراء هذه الفحوص. اقرأه قبل نسخ أي وصفة، وتأكد من الخلفية التي يستخدمها Docker المثبّت، لأن خلفية nftables تدمج السياسة بشكل مختلف.