چرا نگاشت پورت VPN در Docker شما هرگز به OpenVPN نمی‌رسد
پورت میزبان، پورت کانتینر و ترابری سه تصمیم جداگانه‌اند. یک تلاش UDP را پیش از دست زدن به گواهی‌ها از هر مرز دنبال کنید.
کانتینر شما می‌تواند روی UDP 1195 گوش دهد در حالی که میزبان 1194 را منتشر می‌کند، و این درست است تا زمانی که نگاشت همین را بگوید. اعداد یک جدول ترجمه می‌سازند: کلاینت پورت میزبان را شماره‌گیری می‌کند، Docker مقصد را به پورت کانتینر بازنویسی می‌کند، و OpenVPN روی پورتی که پیکربندی خودش نام می‌برد پاسخ می‌دهد. هر ناهماهنگی در هر یک از این حلقه‌ها یک شکست خاموش می‌سازد که شبیه فایروال به نظر می‌رسد. گواهی‌ها و رمزها پایین‌دست این قرار دارند و نمی‌توانند آن را درست کنند.
پیش از تغییر هر چیزی در احراز هویت، یک بسته را از کلاینت تا فرایند دنبال کنید.
سه عدد، یک اتصال
این سه عدد مقصد دوری است که کلاینت استفاده می‌کند، نگاشت منتشرشده روی میزبان، و شنونده درون کانتینر. لازم نیست برابر باشند، اما باید زنجیره بسازند. اعداد برابر یک حالت خاص است که اتفاقاً رایج‌ترین است، و به همین دلیل ناهماهنگی را یک بار آسان می‌نویسند و بعد سخت می‌بینند.
پیش از اشکال‌زدایی زنجیره را در یک خط بنویسید: نشانی و پورت کلاینت، نگاشت میزبان، شنونده کانتینر، ترابری. نقص در زنجیره به شکل عددی ظاهر می‌شود که دو بار با مقادیر متفاوت می‌آید.
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
سینتکس کوتاه واقعاً چه می‌گوید
در شکل کوتاه، سمت چپ پورت میزبان و سمت راست پورت کانتینر است، و پسوند اسلش ترابری را انتخاب می‌کند. اگر پسوند را حذف کنید، Docker نگاشت را TCP می‌داند، پس یک شنونده UDP پشت نگاشت بدون پروتکل شنونده‌ای است که هیچ‌کس به آن نمی‌رسد. این پیش‌فرض مستند شده است و هنوز کسانی را که اعداد را جور کردند و کار را تمام‌شده پنداشتند شگفت‌زده می‌کند.
شکل بلند نشانی اتصال و پروتکل را صریحاً تثبیت می‌کند، که ارزش خطوط اضافه را برای هر چیزی که رو به شبکه است دارد. نگاشت منتشرشده را دوباره بخوانید، نه اینکه به فایلی که آن را ساخته اعتماد کنید.
ports:
- 1194:1195/udpبسته کجا می‌تواند بایستد
یک درخواست می‌تواند پیش از Docker، در Docker یا در شنونده دور انداخته شود. جلوی Docker ممکن است یک فایروال ابری یا یک روتر باشد که خودش ارسال می‌کند، و آن دستگاه به پورت رو به میزبان و ترابری درست نیاز دارد. درون Docker، نگاشت به پورت اشتباه کانتینر به یک سوکت بسته ارسال می‌کند.
سپس شنونده: پیکربندی OpenVPN یک پورت و پروتکل نام می‌برد، و کلاینتی که درون کانتینر به پورت دیگری برسد به هیچ چیز نمی‌رسد. آزمودن یک سرویس UDP با TCP در هیچ‌یک از این مراحل چیزی را ثابت نمی‌کند، پس همان ترابری را به کار ببرید که کلاینت به کار خواهد برد.
نشانی‌های اتصال دسترس‌پذیری را تعیین می‌کنند
نگاشت منتشرشده‌ای که به loopback مقید شده فقط از میزبان دسترس‌پذیر است، در حالی که یکی که به همه رابط‌ها مقید شده هر جا فایروال اجازه دهد دسترس‌پذیر است. این دو در فایل Compose که نشانی را حذف می‌کند یکسان به نظر می‌رسند، و پیش‌فرض Docker همان گسترده است.
تصمیم بگیرید استقرار کدام نمایان‌شدن را می‌خواهد، سپس آن را صریح بنویسید. یک آزمون داخلی که از طریق loopback وصل می‌شود و یک کلاینت دوردست که نمی‌تواند وصل شود می‌توانند هر دو توصیف دقیق همان کانتینر باشند.
وضعیت در حال اجرا را بخوانید
نگاشت مؤثر کانتینر در حال اجرا و شنونده در فضای نام شبکه‌اش را بررسی کنید. ممکن است فایل Compose پس از آغاز کانتینر ویرایش شده باشد، فراداده تصویر ممکن است پورتی را اعلام کند بدون انتشار آن، و کانتینر دومی ممکن است پورت میزبان را در اختیار داشته باشد. اعلام پورت در تصویر به معنای انتشار آن نیست، و هیچ‌کدام هم‌معنی گوش دادن نیست.
سه وضعیت متفاوت، سه فرمان متفاوت، و تنها فرمان آخر به OpenVPN مربوط است.
پس از درست شدن نگاشت
وقتی بسته به OpenVPN رسید، گزارش آن جایی است که درباره TLS و احراز هویت می‌خوانید. تولید دوباره گواهی‌ها برای درست کردن بسته‌ای که هرگز نرسید کاری تلف‌شده است که متغیر دومی اضافه می‌کند. یادداشت نگاشت را کنار نمایه کلاینت نگه دارید تا نفر بعدی یک خط بخواند نه اینکه هر سه عدد را دوباره کشف کند. یک بار ضبط بسته در سمت میزبان روشن می‌کند کدام‌یک از سه حلقه غلط است، و هزینه‌اش از تولید دوباره گواهی کمتر است.
انتشار پل همان حالتی است که اینجا توصیف شده است. شبکه میزبان و نشانی‌های مسیریابی‌شده کانتینر از ترجمه می‌گذرند، پس همان اعداد در آن طرح‌ها معنای دیگری دارند.