د 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 کاري بار د مجازي ماشین پروکسي شاته چلېږي، او جلا مجازي ماشین چې خپل کاروونکی لري خپله تګلاره ساتي۔ یو په قصد وټاکئ او د کانټینر له داخل څخه یې ازمویه، ځکه د کاروونکي غوښتنه هماغه ځای پیدا کېږي۔