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 উৎস ও পরিচয়ের ব্যবস্থা ডিপ্লয়মেন্ট নোটে লিখে রাখুন। পরের ব্যর্থতা ঠিক এই তিনটি তথ্য নিয়েই হবে।