په Windows کنټینرونو کې UNC لاسرسی: لومړی نوم، بیا هویت
د کوربه Explorer نه د کنټینر DNS لاره ثابتوي او نه د هغه SMB هویت. له اجازو مخکې د کنټینر په داخل کې د نوم حل او پورټ 445 وګورئ.
هغه Windows کنټینر چې ستاسو د تونل بلې خوا ته شریک فولډر ته اړتیا لري په دوو خپلواکو لارو ناکامېږي، او د کوربه Explorer د دواړو څخه یو هم نه ثابتوي۔ کنټینر خپل شبکه یی پای ټکی او خپل پروسې هویت لري۔ هغه نوم چې په ډیسکټاپ کې حل کېږي او هغه ناسته چې فایل سرور هلته مني، ډیسکټاپ توصیفوي، نه کاري بار۔
د کوربه Explorer ثبوت نه دی
په کوربه باندې د شریک فولډر خلاصول د کوربه DNS کلاینټ، د کوربه د لارښوونې جدول او هغه حساب چې په کوربه ننوتل شوی کاروي۔ د کنټینر پروسه د دې څخه هیڅ په ضمني ډول نه ترلاسه کوي، حتی کله چې کنټینر په هماغه ماشین کې چلیږي او VPN کلاینټ هم هلته چلیږي۔ لومړۍ پوله شبکه یی لاره ده: آیا کنټینر نوم حل کولی شي، او آیا SMB پورټ ته TCP ناسته خلاصولی شي۔ دوهمه هویت دی: آیا فایل سرور هغه څه مني چې کنټینر وړاندې کوي، د کاري بار لپاره اړینو اجازو سره۔
دواړه یوه ستونزه ګڼل هغه پیژندل شوې چکر رامنځته کوي چې پکې د فایر وال قواعد پراخول کیږي ترڅو هغه څه سم کړي چې په حقیقت کې د شریک فولډر څخه د لاسرسي رد ځواب دی۔
د کنټینر خپله غوښتنه تعقیب کړئ
د Windows کنټینرونو شبکه د Host Networking Service لخوا اداره کیږي، چې پای ټکي د خپل شبکې نوم فضا سره جوړوي۔ هغه حالت چې تاسو غوره کړی هغه ټاکي چې پای ټکی ژباړل کیږي، پل کیږي، که د کوربه سره شریکې شبکې سره نښلول کیږي۔ دا پرېکړه یو ځل دوه شیان بدلوي: کنټینر څه حل کولی شي، او فایل سرور کوم سرچینه پته ویني۔
له هر څه بدلولو مخکې تایید کړئ چې کنټینر پخپله څه مشاهده کوي۔ هغه نوم چې بهر حل کیږي ممکن دننه ناکام شي، ځکه چې د کنټینر DNS ترتیب د کوربه نه دی، او ژباړل شوی پای ټکی ممکن هغه سرچینه وړاندې کړي چې د فایل سرور قواعد یې تمه نه لري۔
docker exec -it app powershell -Command "Resolve-DnsName files.corp.example" docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445" docker exec -it app powershell -Command "Get-NetIPConfiguration"
که حل ناکام شي، د پتې بدلولو پرځای په شبکې ترتیب کې DNS سم کړئ۔ نوم د IP سره بدلول ممکن د تصدیق او سرور هویت چلند بدل کړي، چې یوه ستونزه په دوه بدلوي۔ د VPN کلاینټ خپله تګلاره بله هغه څه ده چې باید وګورئ، ځکه ممکن د کوربه پروسو او هغه ټرافیک چې له کنټینر څخه راځي سره جلا چلند وکړي۔
هویت جلا پرېکړه ده
هغه ډرایو توری چې متقابل کارونکي یې نقشه کوي د اپلیکیشن انٹرفیس نه دی۔ هغه په یوه ننوتلو ناسته کې شتون لري، او د کنټینر پروسه د هغې برخه نه ده۔ UNC لاره وکاروئ او کاري بار ته هغه هویت ورکړئ چې د ځای پرځای کولو ماډل یې ملاتړ کوي۔ چېرې چې ډومین ملاتړ کوي، ګروپ مدیریت شوی خدمت حساب (gMSA) د سند مشخصاتو له لارې مدیریت شوی هویت برابروي۔
د Microsoft د کنټینر gMSA لارښود هغه د سند مشخصاتو ترتیب او د هغه مخکیني شرطونه تشریح کوي، چې په کې د ډومین غړیتوب او هغه کوربه شامل دي چې سند ترلاسه کولی شي۔ حساب، ترلاسه کول، د کنټینر په داخل کې د پروسې هویت او د شریک فولډر اجازې باید ټولې سره سمون ولري۔ د VPN ننوتل هغه هویت نه دی، او د کوربه کارونکي ناستې د بیا تولید لپاره په یوه عکس کې پټنوم پخول تلپاته خطر رامنځته کوي۔
ناکامه پړاو ښکاره وساتئ
د حل ناکامي، د اړیکې رد او د لاسرسي رد بیلابېل شواهد غواړي۔ هغه په ترتیب سره DNS پوښتنه، د لارښوونې یا فلټر پوښتنه، او د تصدیق یا اجازې پوښتنه ده۔ هغه ځواب ولولئ چې کنټینر ترلاسه کړی، نه د اپلیکیشن عمومي تېروتنه۔
د کاري بار په خپل هویت ازموینه وکړئ او رد هم ازموئ۔
د بیا نښلولو پلان جوړ کړئ
VPN لارې غورځي۔ کله چې تونل بېرته راشي، پای ټکی ممکن په بله ژباړل شوې پته بېرته راشي، او موجوده SMB ناسته ممکن پرته له دې چې اپلیکیشن پوه شي مړه وي۔ دا په اپلیکیشن کې اداره کړئ: لاره او هویت بیا جوړ کړئ، عملیات بیا هڅه کړئ، او د نامعلومې پایلې فایل عملیات سره سمون راوړئ پرته له دې چې فرض کړئ هیڅ نه دی شوی۔
د شبکې حالت، DNS سرچینه او د هویت ترتیب په ځای پرځای کولو یادښتونو کې ثبت کړئ۔ راتلونکې ناکامي به سم د همدې درې حقیقتونو په اړه وي۔