انتشار پورت در Docker و منابع VPN: دو تطبیقی که از دست می‌دهید

قاعده می‌گوید نشانی سرور VPN را به سرویس منتشرشده اجازه دهید، و با این حال اتصال قطع می‌شود. این نتیجه رایج است و اشکال Docker نیست. دو تطبیق جداگانه اشتباه‌اند: منبعی که نوشته‌اید ممکن است همان منبعی نباشد که میزبان دریافت می‌کند، و پورتی که نوشته‌اید ممکن است همان پورتی نباشد که فیلتر می‌بیند. اصلاح هر دو نیازمند نگاه به مسیر بسته است، نه نمودار سرویس.

افسانه: به سرور VPN اجازه بده و تمام

یک VPN مسیریابی‌شده می‌تواند نشانی تونل مشتری را تا خود میزبان Docker حفظ کند. دروازه‌ای که ترجمه منبع انجام می‌دهد می‌تواند آن نشانی را با نشانی خودش جایگزین کند. هر دو طرح مشروع‌اند و برای یک کنش کاربر منابع متفاوتی تولید می‌کنند.

پس عبارت آی‌پی سرور 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 نصب‌شده از کدام backend استفاده می‌کند، چون backend nftables سیاست را به شکل دیگری ادغام می‌کند.