WSL2 কর্পোরেট VPN উত্তরাধিকার করে না, আর বাগটাই সেখানেই
WSL2 নিজের ভার্চুয়াল নেটওয়ার্কে চলে এবং হোস্টের VPN স্ট্যাক কখনও উত্তরাধিকার করে না। resolv.conf সম্পাদনার আগেই নামের ব্যর্থতা ও পাথের ব্যর্থতা আলাদা করুন।
Edge-এ অভ্যন্তরীণ উইকি লোড হয়, অথচ ডিস্ট্রিবিউশনের ভেতরে git clone টাইম আউট হয়। এই একটি পর্যবেক্ষণকেই সাধারণত «VPN WSL2-কে ব্লক করছে» বলে পড়া হয়, আর পরের এক ঘণ্টা যায় /etc/resolv.conf সম্পাদনায়। বেশি কাজে লাগে এমন পাঠ হলো: WSL2-এর কাছে হোস্টের নেটওয়ার্ক পাথ কখনওই ছিল না, কারণ এটি নিজের অ্যাডাপ্টার, নিজের রুট আর Windows-এর তৈরি করা resolver ফাইল নিয়ে একটি ইউটিলিটি VM-এ চলে। এরপর যা কিছু আসে তা নির্ভর করে এই তিনটির মধ্যে আসলে কোনটি আপনার নেই তার উপর।
VM-এর নিজের স্ট্যাক, মেট্রিক আর resolver আছে
ডিফল্ট NAT মোডে ডিস্ট্রিবিউশনটি একটি ভার্চুয়াল সুইচের পিছনে থাকে এবং হোস্টের মধ্য দিয়ে ইন্টারনেটে পৌঁছায়, কিন্তু হোস্টের অ্যাডাপ্টার দেখতে পায় না। ip addr একটি প্রাইভেট ঠিকানার একটি ইন্টারফেস দেখায়, ip route ওই সুইচের মধ্য দিয়ে একটি ডিফল্ট রুট দেখায়, আর /etc/resolv.conf হলো Windows-এর বেছে নেওয়া একটি stub resolver-এর দিকে নির্দেশ করা তৈরি ফাইল। Windows-এর দিকে একটি VPN ক্লায়েন্ট চালু হওয়ায় এর কোনোটিই বদলায় না।
এই কারণেই «ব্রাউজার কাজ করে» এত কম প্রমাণ করে। ব্রাউজার হোস্ট স্ট্যাক, টানেল আর হোস্টের resolver নীতি ব্যবহার করে। আপনার শেল ব্যবহার করে ভিন্ন একটি স্ট্যাক, যা কেবল দৈবক্রমে একটি ফিজিক্যাল নিক শেয়ার করে। ভালো ক্ষেত্রে দুটো মিলে যায়, আর ঠিক তখনই আলাদা হয় যখন VPN একটি ফিল্টার বসায়, DNS তালিকা পুনর্লিখন করে বা ভার্চুয়াল সুইচের সাবনেটের জন্য একটি রুট যোগ করে।
আপনি কোন জগতে আছেন তা দুটি পরীক্ষা ঠিক করে, আর সেগুলি ডিস্ট্রিবিউশনের ভেতরে চালাতে হবে:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confআক্ষরিক ঠিকানা উত্তর দিলেও নাম ব্যর্থ হলে সেটি resolver সমস্যা। নাম ও ঠিকানা একসঙ্গে ব্যর্থ হলে সেটি পাথের সমস্যা, আর resolver সম্পাদনা তার ছোঁয়াও পাবে না। এরপর আসে Windows-এর দিকের প্রমাণ: Get-NetAdapter | Get-DnsClientServerAddress আর route print -4 দেখায় টানেল আপনার VM যে সাবনেটে থাকে সেটি দখল করেছে কি না।
প্রথম ভুল ধারণা: কর্পোরেট DNS সার্ভারই সব ঠিক করে দেয়
resolver ফাইল সম্পাদনা করা ক্লাসিক পরামর্শ, আর এটি প্রায় অর্ধেক সময়ে ঠিক। যখন ঠিক, তখন নির্দিষ্ট একটি কারণে ঠিক: তৈরি ফাইলটি এমন resolver-এর দিকে দেখায় যা কেবল পাবলিক নাম জানে, তাই intranet.example.internal-এর কোয়েরি পাথ ঠিক থাকলেও অস্তিত্বহীন হিসেবে ফিরে আসে।
VPN-এর সার্ভার পিন করা মানে Windows-কে ফাইলটি পুনরায় তৈরি করা থেকে থামানো, কারণ হাতে লেখা যেকোনো ফাইল পরের শুরুতে প্রতিস্থাপিত হয়:
[network]
generateResolvConf = falseএটি /etc/wsl.conf হিসেবে সংরক্ষণ করুন, Windows থেকে wsl --shutdown চালান, তারপর ডিস্ট্রিবিউশন চালু করে /etc/resolv.conf লিখুন যেখানে টানেলের সার্ভার আগে আর একটি পাবলিক resolver কেবল ফলব্যাক হিসেবে থাকবে। এটি রক্ষণাবেক্ষণ খরচসহ একটি টেকসই পরিবর্তন: ফাইলটি আর হোস্ট অনুসরণ করে না, তাই কর্পোরেট DNS ঠিকানা বদলালে ডিস্ট্রিবিউশন পুরোনোগুলোই জিজ্ঞাসা করতে থাকে। কাউকে ওই ফাইলের দায়িত্ব নিতে হবে।
ব্যর্থতা আরও বিস্তৃত হলে এটিও কিছুই করে না। curl যদি 1.1.1.1-এ টাইম আউট হয়, তাহলে টানেল ক্লায়েন্ট ভার্চুয়াল সুইচ ফিল্টার করছে বা VM-এর সাবনেট টানেলে পাঠাচ্ছে, আর সঠিক resolver আপনাকে কেবল এমন নাম দেয় যেখানে এখনও পৌঁছানো যায় না।
দ্বিতীয় ভুল ধারণা: মেট্রিক পরিবর্তনটা টেকে
নাম রিজলভ হলে কিন্তু ট্রাফিক ফিজিক্যাল অ্যাডাপ্টার দিয়ে বেরোলে ইন্টারফেস মেট্রিকই লিভার। VPN অ্যাডাপ্টারকে উচ্চ খরচ আর WSL সুইচকে নিম্ন খরচ দিন:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1তারপর মনে রাখুন, অনেক ক্লায়েন্ট বিল্ডে টানেল অ্যাডাপ্টার প্রতিবার কানেক্টে নতুন করে তৈরি হয় আর মেট্রিক নিজের ডিফল্টে ফিরে যায়। এককালীন কমান্ড এমন একটি সমাধান যা চুপচাপ মেয়াদোত্তীর্ণ হয়, সাধারণত সপ্তাহান্তে, আর টিকিট ফিরে আসে «গত সপ্তাহে কাজ করছিল» নিয়ে। VPN ইভেন্টে চালু হওয়া নির্ধারিত টাস্ক, বা ব্যবহারকারীর কানেক্টের পর চালানো স্ক্রিপ্ট, এই মেরামতের সৎ সংস্করণ।
একই মেয়াদোত্তীর্ণতা একটি একগুঁয়ে প্রিফিক্সের জন্য যোগ করা হোস্ট রুটের ক্ষেত্রেও প্রযোজ্য। ডায়াগনস্টিক হিসেবে সেগুলি মূল্যবান, কারণ সমস্যাটি একটি গন্তব্য না পুরো পাথ তা তারা বলে দেয়, কিন্তু তারা কোনো আর্কিটেকচার নয়।
তৃতীয় ভুল ধারণা: একটি সমাধানই সব Windows বিল্ড ঢেকে দেয়
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit হলো sidecar প্যাটার্ন: একটি ছোট ডিস্ট্রিবিউশন হোস্টের দিকের পাথের মালিক হয় এবং ভার্চুয়াল সকেটের মাধ্যমে অন্য ডিস্ট্রিবিউশনের জন্য ফরোয়ার্ড করে, ফলে অ্যাপ্লিকেশন ট্রাফিক ফিল্টার করা সুইচের উপর নির্ভর করা ছেড়ে দেয়। স্টক পাথ কাজ করা দরকার, অর্থাৎ networkingMode আর dnsTunneling ওভাররাইড %UserProfile%\.wslconfig থেকে সরানো, প্রতিটি কার্যকর ডিস্ট্রিবিউশনে generateResolvConf = true পুনরুদ্ধার এবং লগইনে সার্ভিস চালু করা।
মিররড মোড Windows 11 22H2 ও তার পরে বিল্ট-ইন বিকল্প, আর এটি একটি সেটিং প্লাস একটি শাটডাউন:
[wsl2]
networkingMode=mirroredডিস্ট্রিবিউশনের ভেতরে ip addr তখন হোস্টের অ্যাডাপ্টারগুলি তালিকাভুক্ত করে, টানেল তাদের মধ্যে দেখা দিতে পারে, আর DNS টানেলিং Windows resolver-এর মাধ্যমে লুকআপ ফরোয়ার্ড করে এমনকি ক্লায়েন্ট DNS তালিকা পুনর্লিখন করলেও। এটি সর্বজনীন নয়: কিছু ফিল্টার ড্রাইভার এখনও মিররড পাথ ফেলে দেয়, আর Hyper-V ফায়ারওয়াল নিয়মের স্পষ্ট অনুমতি লাগতে পারে। Microsoft-এর WSL নেটওয়ার্কিং গাইড হলো সেই পৃষ্ঠা যা নতুনের জন্য লেখা রেসিপি প্রয়োগের আগে আপনার বিল্ডের সঙ্গে মিলিয়ে দেখা উচিত।
প্রতিটি পরিবর্তনের পরে তিনটি জিনিস পরীক্ষা করুন
প্রতি মেশিনে একটি প্রক্রিয়া বেছে নিয়ে লিখে রাখুন, কারণ দুটো একসঙ্গে খারাপভাবে মেশে। মিররড মোডের উপরে sidecar ফরোয়ার্ডিং দ্বিগুণ করে, আর .wslconfig-এ পুরোনো sidecar এন্ট্রিসহ মিররড হোস্ট আপগ্রেডের পরে ব্যর্থ হতে চায়, আগে নয়।
যা-ই বেছেছেন, গ্রহণযোগ্যতা পরীক্ষা ডিস্ট্রিবিউশনের ভেতরে একই তিনটি অনুরোধ: একটি অভ্যন্তরীণ নাম, একটি পাবলিক নাম আর একটি কাঁচা ঠিকানা। তারপর টানেল বিচ্ছিন্ন ও পুনঃসংযুক্ত করার পরে এবং wsl --shutdown-এর পরে সেগুলি পুনরাবৃত্তি করুন। কেবল অভ্যন্তরীণ নাম ব্যর্থ হলে তা resolver নীতি; অভ্যন্তরীণ ও পাবলিক নাম একসঙ্গে ব্যর্থ হলে আর ঠিকানা কাজ করলে তাও resolver নীতি; সব ব্যর্থ হলে তা পাথ।
একটি অভ্যন্তরীণ হোস্ট ব্যর্থ হয়ে বাকিগুলো কাজ করলে resolver-এর দিকে তাকানো বন্ধ করুন এবং ওই প্রিফিক্সের জন্য অনুপস্থিত রুট খুঁজুন। পরের পুনঃসংযোগ পর্যন্ত সব কাজ করলে আপনি রানটাইম অবস্থার উপর নির্ভরশীল একটি সমাধান পেয়েছেন, আর সেটি স্বয়ংক্রিয়ভাবে পুনরায় প্রয়োগ করতে হবে বা উপরের দুটি প্রক্রিয়ার একটি দিয়ে প্রতিস্থাপন করতে হবে।