DNAT در کانتینر VPN: ارسال، نه INPUT

درخواست با نشانی 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 به دروازه پل آزمون پذیرش سرویس نیست.

قواعد را در پیکربندی راه‌اندازی پشتیبانی‌شده کانتینر نگه دارید، چون ویرایش‌های تعاملی هنگام بازسازی آن ناپدید می‌شوند. انتشار پورت روی میزبان مسیر افشای دیگری است و فقط به این دلیل که سرویس از طریق تونل در دسترس است لازم نیست.