Windows کنٹینرز میں UNC رسائی: پہلے نام، پھر شناخت

آپ کی سرنگ کے دوسری طرف موجود شیئر کی ضرورت والا 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 ماخذ اور شناخت کا انتظام تعیناتی نوٹس میں درج کریں۔ اگلی ناکامی انہی تین حقائق کے بارے میں ہوگی۔