VPN সংযুক্ত হওয়ার পর WSL2 DNS হারিয়েছে? দুটি কারণ

পুরোনো resolver ফাইল আর প্রতিদ্বন্দ্বী রুট মেট্রিক WSL2-এর ভেতরে একই উপসর্গ তৈরি করে। দুই দিকের তথ্য নিন, তারপর যেটি সত্যিই নষ্ট সেটিই ঠিক করুন।

ঠিকানায় ping ডিস্ট্রিবিউশনের ভেতরে কাজ করে, প্যাকেজ ইনস্টল আর git টানার কাজ করে না, আর সমস্যাটি দেখা দিয়েছে টানেল চালু হওয়ার ঠিক পরেই। শুধু নাম রিজলভ হওয়া বন্ধ হয়েছে, যা DNS-এর দিকে ইঙ্গিত করে, সংযোগের দিকে নয়। প্যাকেজ আবার ইনস্টল করাই এখানে সবচেয়ে জনপ্রিয় ভুল প্রথম পদক্ষেপ। WSL2-এর কাছে ঠিক এই উপসর্গ তৈরির দুটি স্বতন্ত্র উপায় আছে, আর দুটিরই আলাদা মেরামত দরকার।

কেন ডিস্ট্রিবিউশন নিজের resolver রাখে

Windows-এর DNS ক্লায়েন্ট ডিস্ট্রিবিউশনের ভেতরে ব্যবহার হয় না। WSL2 চালু হওয়ার সময় নিজের resolver ফাইল তৈরি করে, যা এমন একটি stub ঠিকানার দিকে দেখায় যা Windows ইউটিলিটি VM-এর জন্য ভার্চুয়াল সুইচে প্রকাশ করে।

সাধারণ নেটওয়ার্ক পরিবর্তনে এই ব্যবস্থা স্থিতিশীল, কারণ এটি একবার লেখা হয় এবং পুনরায় ব্যবহার হয়। কিন্তু টানেল ক্লায়েন্ট ইউটিলিটি VM চালু হওয়ার পর হোস্ট অ্যাডাপ্টার তালিকা আবার লেখা শুরু করলে এই ব্যবস্থা আর সঠিক থাকে না।

ডিস্ট্রিবিউশনের ভেতরে কিছুই এই পরিবর্তন লক্ষ্য করে না, তাই ফাইলটি এমন ঠিকানার দিকে দেখাতেই থাকে যা আর পথে নাও থাকতে পারে। পরের লুকআপ তখন অপেক্ষা করে, সময় শেষ হয়, বা এমন সার্ভার থেকে উত্তর আসে যা অভ্যন্তরীণ জোনের কথা কখনো শোনেনি। ভেতর থেকে resolver কেবল উত্তর দেওয়া বন্ধ করে দেয়, আর সব নাম একসাথে ব্যর্থ হয়।

প্রথমে দুই দিকের প্রমাণ সংগ্রহ করুন

কোনোটি বদলানোর আগে ডিস্ট্রিবিউশন যা দেখে তা লিখুন, তারপর Windows যা দেখে তা। দুই দৃশ্য একসাথে মিলেই ব্যর্থতার ধরনগুলো আলাদা করে।

ডিস্ট্রিবিউশনের ভেতরে resolver ফাইল, রাউটিং টেবিল এবং একটি অভ্যন্তরীণ ও একটি পাবলিক লুকআপ ছাপুন:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows-এ প্রতিটি অ্যাডাপ্টারের DNS সার্ভার আর মেট্রিকসহ IPv4 টেবিল তালিকাভুক্ত করুন। VPN ক্লায়েন্ট সাধারণত WSL2 সাবনেটের জন্য একটি রুট ইনস্টল করে, আর তার মেট্রিকই ঠিক করে ওই ট্রাফিক টানেল দিয়ে বেরোবে না লোকাল থাকবে।

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

রুট মেট্রিক নাকি পুরোনো ফাইল

প্রথম ব্যর্থতাটি পুরোনো ফাইল। resolver-টি চালুর সময়ের অ্যাডাপ্টার অবস্থার জন্য লেখা হয়েছিল, আর টানেল ওই অবস্থা বদলে দিয়েছে। এর stub ঠিকানা এখন হয়তো পৌঁছানোর বাইরে, নয়তো এমন সার্ভারের নাম বলে যা অভ্যন্তরীণ জোন সম্পর্কে কিছুই জানে না।

দ্বিতীয়টি রাউটিং সমস্যা। VPN যখন WSL2 সাবনেট ঢাকা একটি রুট যোগ করে হোস্ট লিংক রুটের চেয়ে কম মেট্রিকে, তখন ইউটিলিটি VM-এর জন্য ঠিকানা দেওয়া প্যাকেট টানেলে ঢুকে পড়ে। তখন শুধু DNS নয়, প্রতিটি WSL2 পরিষেবা সময় শেষে ব্যর্থ হয়।

পার্থক্য নির্ণয়ের পরীক্ষায় এক লাইন লাগে। পাবলিক resolver-এর মতো সংখ্যাভিত্তিক ঠিকানা যদি নাম ব্যর্থ হওয়া সত্ত্বেও ping-এ উত্তর দেয়, তবে পথ অটুট আর সমস্যা DNS-এ। এটিই সেই ক্ষেত্র যেখানে resolver বদলানো ন্যায্য, আর যে ক্ষেত্রে ন্যায্য নয় সেটিও স্পষ্ট হয়ে যায়। সংখ্যাভিত্তিক পরীক্ষাও ব্যর্থ হলে ইউটিলিটি VM তার রুট হারিয়েছে এবং কোনো resolver ফাইল তা সারাবে না।

রাউটিংয়ের ক্ষেত্রে টানেল অ্যাডাপ্টারের স্বয়ংক্রিয় মেট্রিক বাদ দিন এবং WSL2 লিংক রুটের উপরে একটি সংখ্যা দিন:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

বন্ধ করাটা জরুরি। মেট্রিক বদলালে চলমান ইউটিলিটি VM আবার লেখা হয় না, তাই পরিবর্তনটি দেখা যাওয়ার আগে ডিস্ট্রিবিউশন আবার তৈরি করতে হয়।

ফাইলটি সচেতনভাবেই নিজের হাতে নিন

রাউটিং ঠিক থাকলে এবং কেবল অভ্যন্তরীণ নাম ব্যর্থ হলে দোষ resolver-এর, আর আপনি জেনারেটর থামাতে পারেন। এটি রক্ষণাবেক্ষণ ব্যয়সহ সচেতন পরিবর্তন, হালকাভাবে প্রয়োগ করার মতো কোনো কাজ চালানোর উপায় নয়।

ডিস্ট্রিবিউশনের ভেতরে জেনারেশন বন্ধ করে এমন নেটওয়ার্ক বিভাগসহ /etc/wsl.conf তৈরি করুন, তারপর resolver ফাইলটি নিজেই লিখুন, আগে কর্পোরেট সার্ভার আর পরে পাবলিক ফলব্যাক:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

ক্রম গুরুত্বপূর্ণ। পাবলিক resolver অভ্যন্তরীণ নামের উত্তর দিতে পারে না, আর ফলব্যাক কেবল ইন্টারনেট লুকআপের জন্য। ফাইলটি একবার আপনার হলে আর কিছুই তা পুনরায় তৈরি করে না, তাই স্থান বদলানো কর্পোরেট resolver এমন বিভ্রাট হয়ে দাঁড়ায় যা আপনাকেই খেয়াল করতে হবে।

আগে নাম দেখুন, তারপর প্যাকেজ

সিস্টেম resolver দিয়ে একটি অভ্যন্তরীণ ও একটি পাবলিক নাম যাচাই করুন, তারপর যে কাজটি ব্যর্থ হয়েছিল তা আবার করুন। প্যাকেজ ম্যানেজার কখনো নিজের resolver ব্যবহার করে, তাই ভাঙা ইনস্টলের পাশেও কাজ করা getent থাকতে পারে।

পুনর্লিখন স্বয়ংক্রিয় করলে সেটি একই ফল দিতে হবে: কোনো টানেল না থাকলে খালি সার্ভার তালিকা লেখার বদলে আগে থেকে থাকা ফাইলটিই রাখুন।

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

ডিস্ট্রিবিউশনের ভেতর থেকে কাজ করা একটি অভ্যন্তরীণ লুকআপ আর কাজ করা একটি পাবলিক লুকআপই লিপিবদ্ধ করার যোগ্য ফল। হোস্টে সবুজ VPN আইকন দুটির কোনোটিই প্রমাণ করে না।

সম্পর্কিত নিবন্ধ