نشر منافذ Docker مقابل الـ VPN: إلى أين يذهب الرد

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

تتبَّع التوبل عبر DNAT الوجهة

خُذ مضيفاً على 192.0.2.10 ينشر TCP 2222 إلى حاوية على 172.30.240.5:22. طلب من 198.51.100.25 يُترجَم قبل أن يصل إلى الحاوية، والحاوية ترد بهويتها.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

لماذا تفوتها قاعدة خاصة بالمضيف وحده

قاعدة تختار جدول WAN فقط للحزم القادمة من 192.0.2.10 تغطي خدمات المضيف نفسها وتفوّت هذا الرد المُمرَّر تماماً. عنوان المصدر في الرد هو 172.30.240.5، لا المضيف.

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

مطابقة ما بعد DNAT خطاف مختلف

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

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

التصميم A: حمل القرار كحالة اتصال

يمكن لعلامة الاتصال أن تحمل قرار الدخول عبر الترجمة، لكن يجب إعادتها إلى الحزمة قبل بحث التوجيه المهم. المراحل هي:

1. احجز حقلاً من العلامة وأولوية قاعدة لا تتصادم مع Docker أو الـ VPN أو مالك سياسة آخر.
2. حدِّد فقط اتصال WAN الجديد المقصود عند نقطة قبل DNAT حيث تتبع الاتصالات متاح.
3. سجّل القرار على علامة الاتصال، دون إجبار الطلب الأصلي نفسه على جدول WAN.
4. في اتجاه الرد، أعِد بتات علامتك وحدها إلى الحزمة قبل التوجيه.
5. اختر جدول WAN كاملاً مبكراً بما يكفي حتى لا تفوز قاعدة VPN أولاً.

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

التصميم B: أنهِ الاتصال على المضيف

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

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

تحقق من التغيير، لا من النية

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

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