کانتینرهای Windows و VPN: چرا شبکه محلی از کار می‌افتد
کانتینر Windows از جدول مسیریابی میزبان استفاده می‌کند، پس VPNی که زیرشبکه محلی را مسدود می‌کند پیشوند کانتینر را هم با خود می‌برد. حالت Linux مسیر دیگری می‌رود.
روی یک لپ‌تاپ، با یک کارخواه VPN متصل، کانتینرهای Linux به گفتگو با یکدیگر ادامه می‌دهند و کانتینرهای Windows متوقف می‌شوند. متغیر تصویر نیست؛ مسیری است که بسته‌ها به میزبان می‌پیمایند. کانتینرهای Windows روی شبکه پیش‌فرض جدول مسیریابی و ترجمه میزبان را قرض می‌گیرند، پس سیاستی که مسیریابی میزبان را تغییر می‌دهد آن‌ها را هم تغییر می‌دهد. این را با یک جستجوی مسیر پیش از نصب دوباره هر چیزی تأیید کنید.
بسته‌های کانتینر Windows از کجا وارد میزبان می‌شوند
کانتینری روی شبکه پیش‌فرض nat نشانی را از یک پیشوند سرویس Host Networking Service می‌گیرد، معمولاً جایی داخل 172.16.0.0/12، و از طریق یک آداپتور مجازی به میزبان می‌رسد. میزبان صاحب مسیر آن پیشوند است و ترافیک را به سمت آداپتوری که اکنون فعال است ترجمه می‌کند. هیچ ماشین مجازی جداگانه‌ای در میانه آن مسیر نیست.
همین طراحی است که شکست را مکانیکی می‌کند. وقتی کانتینر بسته‌ای می‌فرستد، میزبان برای پیشوند کانتینر یک جستجوی مسیر انجام می‌دهد. هر مسیری که برنده شود بسته به همان جا می‌رود و کانتینر هیچ نظری درباره آن ندارد.
کارخواه VPN چه چیزی را در آن مسیر تغییر می‌دهد
کارخواه شرکتی اغلب مجموعه گسترده‌ای از مسیرها و یک فیلتر نصب می‌کند که تا وقتی تونل بالاست دسترسی به زیرشبکه محلی را رد می‌کند. قصد دفاعی است: شبکه محلی آلوده نباید به ماشین محافظت‌شده برسد. اثر جانبی این است که مسیر میزبان به پیشوند کانتینر دیگر شبکه NAT محلی نیست.
در عوض جستجو با تونل منطبق می‌شود و بسته به دروازه‌ای تحویل داده می‌شود که هرگز نام آن نشانی کانتینر را نشنیده است. Ping شکست می‌خورد، برنامه از مهلت رد می‌شود و کانتینر خراب به نظر می‌رسد در حالی که نماد VPN می‌درخشد. هنگام اتصال جدول میزبان را ببینید و مسیر رقیب دیده می‌شود.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
چرا کانتینرهای Linux متفاوت رفتار می‌کنند
موتور Linux کانتینرها را درون یک ماشین مجازی سبک اجرا می‌کند و اتصالات خروجی از آن ماشین را یک واسط سمت میزبان به نمایندگی از کانتینر باز می‌کند. میزبان سوکت را آغاز می‌کند، پس قاعده VPN درباره پیشوند کانتینر به همان شکل بر آن اعمال نمی‌شود و بار کاری همچنان به شبکه می‌رسد.
این تفاوت همچنین توضیح می‌دهد چرا دستورهای Linux منتقل نمی‌شوند. کانتینر Linux که به تونل خودش نیاز دارد یک دستگاه TUN به‌همراه توانایی NET_ADMIN می‌گیرد. کانتینرهای Windows هیچ رابطی را به‌عنوان دستگاه ارائه نمی‌دهند، پس آن الگو در آن سمت معادلی ندارد.
مسیر را اثبات کنید، سپس طرحی انتخاب کنید
شواهد را از میزبان جمع کنید نه از کانتینر، چون میزبان جستجو را انجام می‌دهد:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"خروجی مسیرها را یک بار پیش از اتصال VPN و یک بار پس از آن اجرا کنید. اگر در خروجی دوم پیشوند کانتینر به آداپتور تونل اشاره کرد، عیب‌یابی کامل است و راه‌اندازی دوباره کانتینرها کمکی نمی‌کند.
گزینه اول یک تصمیم سیاستی است: از صاحب شبکه بپرسید آیا دسترسی LAN محلی برای این دستگاه مجاز است. چند کارخواه شرکتی آن را به‌صورت تنظیم ارائه می‌دهند، اما این مرز عامدانه‌ای را ضعیف می‌کند. آن را به‌عنوان استثنایی مستند با صاحب و تاریخ بازبینی بخواهید. کلیدی برای هر دستگاه که هیچ‌کس دوباره به آن سر نمی‌زند همان راهی است که یک سیاست دفاعی بی‌صدا ناپدید می‌شود.
جایی که سیاست باید بماند، بار کاری را جابه‌جا کنید نه اینکه با مسیر بجنگید. شبکه شفافی با زیرشبکه و دروازه صریح کانتینرها را روی پیوند محلی می‌گذارد، بار کاری Linux پشت واسط ماشین مجازی اجرا می‌شود، و یک ماشین مجازی جداگانه با کارخواه خودش سیاست خودش را نگه می‌دارد. یکی را عامدانه انتخاب کنید و آن را از درون کانتینر بیازمایید، چون درخواست کاربر همان‌جا شکل می‌گیرد.