DNAT داخل حاوية VPN: إعادة توجيه لا INPUT
بعد DNAT يصبح الطلب الموجّه إلى عنوان النفق مرورًا معادًا توجيهه. اضبط نطاق قاعدة التمرير، واقرأ سلسلة Docker، واختر مسار العودة بوعي.
يصل الطلب موجّهًا إلى عنوان IP للنفق، ثم يغادر الحاوية نفسها موجّهًا إلى خدمة مجاورة. بين هاتين اللحظتين أعاد DNAT كتابة الوجهة، فتوقف الطلب عن أن يكون إدخالًا لحاوية VPN. صار الآن مرورًا معادًا توجيهه، تحكمه قاعدة مختلفة. يفسّر هذا التحول لماذا لا تؤثر قاعدة جدار حماية تبدو صحيحة لعنوان النفق في الاتصال المترجم.
تتبَّع الحزمة بعد الترجمة
خذ بركة عملاء 10.90.0.0/24 وعنوان نفق 10.90.0.1. تقع حاويتان على جسر واحد: 192.0.2.2 تشغّل VPN و192.0.2.3 تشغّل التطبيق. يتصل عميل بـ 10.90.0.1:8080، فتعيد قاعدة DNAT في نطاق الاسم لحاوية VPN كتابة ذلك إلى عنوان التطبيق الحقيقي ومنفذه. ثم يرسل مسار الحزمة عبر الجسر. هذه العناوين توضيحية وليست وصفة نشر.
قد يختلف المنفذ الذي يستمع عليه التطبيق فعليًا عن أي منفذ منشور على المضيف. اقرأ المستمع داخل الحاوية بدلًا من افتراض تطابق الرقمين.
الإذن ينتمي إلى مسار التمرير
تحتاج حاوية VPN إلى تمرير IP وإلى قرار تمرير محدود النطاق ببركة العملاء وعنوان التطبيق والمنفذ المقصود. تحتاج الردود القائمة إلى سماح خاص بها. القاعدة التي تطابق عنوان النفق الأصلي لن تطابق بعد DNAT، لأن الوجهة تغيّرت بالفعل. وسماح INPUT هو الخطاف الخاطئ لمرور لم يعد موجّهًا إلى هذا المضيف.
أبقِ النطاق ضيقًا: نطاق مصدر واحد، ووجهة واحدة، وخدمة واحدة. قاعدة التمرير المتساهلة أسهل في الكتابة وأصعب بكثير في الدفاع عنها لاحقًا.
docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD
سلاسل Docker ليست سلاسل حاويتك
القواعد داخل نطاق اسم الحاوية ليست قواعد مضيف Docker. عندما ينتقل المرور من واجهة النفق إلى الجسر، يمكن لجدار حماية الجسر على المضيف أن يتخذ قرارًا آخر. مع خلفية iptables في Docker، تظهر تلك السلاسل الموثّقة ونقطة المطابقة بعد DNAT هناك.
يصف مرجع جدار حماية Docker تلك السلاسل ومطابقة ما بعد DNAT. لا تعالج قبولًا ناقصًا بتعطيل إدارة جدار الحماية في Docker أو بجعل كل سلسلة متساهلة، لأن ذلك يزيل الحد الذي تحاول استخدامه.
اجعل مسار العودة خيارًا واعيًا
إذا حُفظ عنوان المصدر، رأى التطبيق 10.90.0.x ووجب عليه توجيه الردود عائدة عبر حاوية VPN. وإلا فسيرسلها بوابة Docker العادية إلى المضيف، وهو لا يملك النفق. البديل هو ترجمة مصدر ضيّقة النطاق عند حاوية VPN، تبسّط الرد لكنها تخفي العميل عن التطبيق. اختر بوعي واكتب أي الخيارين اخترت.
اختبر اتصالًا مسموحًا جديدًا من عميل عادي، ثم تأكد من بقاء المنافذ غير ذات الصلة مغلقة. عندما تختفي حزمة، افحص نطاق اسم VPN ونطاق اسم التطبيق وسجل التطبيق نفسه. ping إلى بوابة الجسر ليس اختبار قبول للخدمة.
أبقِ القواعد في إعداد بدء التشغيل المدعوم للحاوية، لأن التعديلات التفاعلية تزول عند إعادة إنشائها. نشر منفذ على المضيف مسار تعريض مختلف، وليس مطلوبًا لمجرد أن الخدمة يمكن الوصول إليها عبر النفق.