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 কাজের চাপ VM প্রক্সির পেছনে চলে, এবং নিজস্ব ক্লায়েন্টসহ আলাদা একটি ভার্চুয়াল মেশিন নিজের নীতি ধরে রাখে। একটি সচেতনভাবে বেছে নিন এবং কন্টেইনারের ভেতর থেকে পরীক্ষা করুন, কারণ ব্যবহারকারীর অনুরোধ সেখানেই উৎপন্ন হয়।