VPN সংযোগ করলে WSL কেন কাজের হোস্টনেম হারায়?
একই নাম Windows-এ কাজ করে আর টানেল ওঠার পরেই WSL-এর ভিতরে ব্যর্থ হয়। রিজলভার যোগ করার আগে প্ল্যাটফর্মের DNS মোড ও পুরনো ওভাররাইডগুলো যাচাই করুন।
Windows অভ্যন্তরীণ হোস্টটি কোনো আপত্তি ছাড়াই রিজলভ করে, আর একই নাম টানেল ওঠার মুহূর্তেই WSL-এর ভিতরে ব্যর্থ হয়। চিরাচরিত সমাধান হল ডিস্ট্রিবিউশনে একটি পাবলিক রিজলভার লিখে দেওয়া, যা সাধারণ ব্রাউজিং ফিরিয়ে আনে এবং কাজের হোস্টনেমটিকে অরিজলভযোগ্য করে তোলে। এটি এক ব্যর্থতার বিনিময়ে আরেকটি ব্যর্থতা আনে, আর যে স্তরটি আসলে ভেঙেছে সেটিকে ঢেকে দেয়। যেকোনো রিজলভার লাইন যোগ বা সরানোর আগে নির্ণয় করুন তিনটি স্তরের কোনটি ব্যর্থ হচ্ছে।
প্রথমে রাউটিং ব্যর্থতা বাদ দিন
উভয় দিকে হুবহু একই পূর্ণরূপে যোগ্য নাম কোয়েরি করুন, একই রকম দেখতে দুটি নাম নয়। একই স্ট্রিংয়ের জন্য Windows-এ সাফল্য আর WSL-এ ব্যর্থতা দুটি ভিন্ন রিজলিউশন পথের স্বাক্ষর, আর এই নকশাটি এত পরিষ্কারভাবে আর খুব কম জিনিসই তৈরি করে। যদি WSL তার জানা সংখ্যাসূচক ঠিকানায় সার্ভিসটিতে পৌঁছাতেও না পারে, তবে রাউটিং বা ফিল্টারিং সমস্যাও আছে। সেক্ষেত্রে DNS-এর কাজ এটি প্রকাশ করবে না, আর বিকেলটা চলে যাবে ভুল স্তরে।
তিনটি লক্ষণ এই বেশিরভাগ ক্ষেত্রেই ঢেকে দেয়, আর প্রতিটি ভিন্ন জায়গায় ইশারা করে। কনফিগারেশন ফাইল খোলার আগে মিলে যাওয়া সারিটি পড়ুন:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
মাঝের সারিটি মানুষ ভুল পড়ে, কারণ যে পরিবর্তনটি এটি ভেঙেছে তা সপ্তাহখানেক আগে করা হয়েছিল এবং তখন সফল মনে হয়েছিল। তৃতীয় সারিটি মানুষ ভুল নির্ণয় করে, কারণ রিজলভ হওয়া একটি নাম নেটওয়ার্ক সুস্থ থাকার প্রমাণ বলে মনে হয়। দুটি সারিই আপনাকে নিচের ভিন্ন ভিন্ন অংশে পাঠায়।
DNS টানেলিংয়ের একটি সংস্করণ নিম্নসীমা আছে
Microsoft এমন একটি WSL নেটওয়ার্কিং মোড নথিভুক্ত করে যা ভার্চুয়ালাইজেশন চ্যানেলের মাধ্যমে DNS অনুরোধ Windows রিজলভারে টানেল করে। সমর্থিত Windows 11 বিল্ডে এটি ডিফল্টভাবে সক্রিয় থাকে, তাই একই কর্পোরেট নেটওয়ার্কের দুটি মেশিন ভিন্নভাবে আচরণ করে। পরিবর্তনশীলটি বিল্ড নম্বর, কর্পোরেট নীতি নয়।
WSL নেটওয়ার্কিং গাইড সেই মোড এবং যে সংস্করণগুলো এটি সমর্থন করে তা বর্ণনা করে। বৈশিষ্ট্যটি গুরুত্বপূর্ণ কারণ কর্পোরেট DNS নীতি সাধারণত Windows রিজলভারেই থাকে, আর যে ডিস্ট্রিবিউশন Windows-এর পথ উত্তরাধিকারসূত্রে পায় সে নীতিটিও সঙ্গে পায়। পাবলিক রিজলভারকে কোয়েরি করা ডিস্ট্রিবিউশনের কোনো ব্যক্তিগত নামে যাওয়ার পথ থাকে না, তার নিজের কনফিগারেশন যতই পরিপাটি দেখাক। এই প্রক্রিয়াটিই পুরো লক্ষণটি ব্যাখ্যা করে, আর ব্যাখ্যা করে কেন পাবলিক-রিজলভার সমাধানটি ব্যর্থ হয়।
কিছু সম্পাদনার আগে বিল্ড নম্বরটি পড়ুন। নতুন ইনস্টলেশন থেকে কপি করা সেটিং প্রমাণ নয় যে পুরনো একটি এটি বাস্তবায়ন করে। পরিবর্তনের পাশে বিল্ড নম্বরটি লিখে রাখুন, কারণ দুটি মেশিনের মধ্যে পার্থক্য প্রায় সবসময়ই নীতি নয়, সংস্করণ।
পুরনো ওভাররাইড নিজেরা যে সমস্যা সমাধান করেছিল তার চেয়ে বেশি বাঁচে
পুরনো রেসিপি জেনারেট করা রিজলভার ফাইল নিষ্ক্রিয় করত, নেমসার্ভার হার্ডকোড করত, বা ফাইলটিকে immutable অ্যাট্রিবিউট দিয়ে লক করত। যে সংযোগ সমস্যার কারণে এগুলো এসেছিল তা মিলিয়ে যাওয়ার অনেক পরেও এই পরিবর্তনগুলো জায়গায় থাকে, আর সাধারণত এগুলোই কারণ যে নতুন সেটিং কিছুই করছে না বলে মনে হয়। ডিস্ট্রিবিউশন পুনঃইনস্টলের পরেও এগুলো shell প্রোফাইলের আকারে টিকে থাকে, যা প্রতিবার লগইনে ফাইলটি পুনর্লিখন করে। শেষটি খুঁজে পাওয়া সবচেয়ে কঠিন, কারণ সবাই যে ফাইলটি পরীক্ষা করে সেখান থেকে এটি অদৃশ্য।
হাতে লেখা একটি রিজলভার ফাইল, তার ওপর একটি immutable অ্যাট্রিবিউট, এবং তা পুনর্লিখন করা একটি স্টার্টআপ স্ক্রিপ্ট খুঁজুন। সম্পাদনার আগে immutable ফ্ল্যাগ পরীক্ষা করুন, কারণ লক করা ফাইলে লেখা এমনভাবে ব্যর্থ হয় যা পারমিশন সমস্যার মতো পড়া যায়। এরপর shell প্রোফাইল পরীক্ষা করুন, কারণ সেখানকার স্ক্রিপ্ট আপনার ঠিক করার কয়েক সেকেন্ডের মধ্যেই পুরনো বিষয়বস্তু ফিরিয়ে আনে।
ওভাররাইড সরানোর পরিণাম থাকে, তাই কী সরালেন এবং কেন তা লিখে রাখুন। যে ডিস্ট্রিবিউশন সত্যিই অন্য উদ্দেশ্যে স্ট্যাটিক রিজলভার দরকার করে, জেনারেট করা ফাইল ফিরে এলে সেটি ভেঙে যাবে।
দুটি ফাইল, দুটি ভিন্ন ভূমিকা
দুটি কনফিগারেশন ফাইল ভিন্ন জায়গায় থাকে এবং ভিন্ন জিনিস নিয়ন্ত্রণ করে, আর এদের গুলিয়ে ফেললে সম্পাদনাগুলো ভুল স্তরে প্রয়োগ হয়। Windows-এর দিকের ফাইলটি ভার্চুয়াল মেশিনের বৈশিষ্ট্য নির্ধারণ করে, আর ডিস্ট্রিবিউশনের দিকের ফাইলটি নির্ধারণ করে সেই ডিস্ট্রিবিউশন কীভাবে নিজের রিজলভার কনফিগারেশন গড়ে। কোনোটিই অন্যটিকে ওভাররাইড করে না, তাই দুটিকেই একমত হতে হয়।
যে ইনস্টলেশন বৈশিষ্ট্যটি সমর্থন করে, তার জন্য Windows-এর দিকের ফ্র্যাগমেন্টটি ছোট। ওই দিকে পুরো পরিবর্তন এটিই:
[wsl2]
dnsTunneling=trueএই ফ্র্যাগমেন্টটি Windows ব্যবহারকারী প্রোফাইলে থাকে এবং একটি ডিস্ট্রিবিউশনের বদলে ভার্চুয়াল মেশিনে প্রযোজ্য। টানেলিংয়ের জন্য আরও দরকার যে ডিস্ট্রিবিউশন রিজলভার জেনারেশন নিষ্ক্রিয় না করুক, তাই ডিস্ট্রিবিউশনের দিকের ফাইলকে এই আচরণটি নিজের মতো থাকতে দিতে হবে। একটি অন্যটি ছাড়া বদলালে মোডটি নিঃশব্দে কিছুই করে না, আর এই সমাধানটিকে ভাঙা বলে রিপোর্ট করার সবচেয়ে সাধারণ উপায় এটিই। একই সেশনে দুটি ফাইলই পরীক্ষা করুন, কারণ সপ্তাহের ব্যবধানে করা দুটি সম্পাদনা এমন দুটি সম্পাদনা যা কেউ দায়ী করতে পারে না।
পুনরায় চালু করুন, তারপর দুই দিক থেকেই কোয়েরি করুন
এই সেটিংগুলো পরিবেশ শুরু হওয়ার সময় পড়া হয়, তাই চলমান ডিস্ট্রিবিউশনের ভিতরে নতুন shell সেগুলো পুনরায় লোড করবে না। shell পুনরায় চালু করার বদলে পরিবেশটি বন্ধ করুন, এবং আগে চলমান কাজ সংরক্ষণ করুন কারণ প্রতিটি ডিস্ট্রিবিউশন তার সঙ্গে বন্ধ হয়। শুধু এই বাদ দেওয়াটাই পরিবর্তনের কোনো প্রভাব না থাকার বেশিরভাগ রিপোর্ট ব্যাখ্যা করে।
তারপর উভয় দিকেই একই প্রশ্ন করুন। আউটপুটটি আরও দেখায় ডিস্ট্রিবিউশনটি শেষ পর্যন্ত কোন রিজলভার পেয়েছে:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'প্রথম কমান্ডটি পরিবেশ শেষ করে, দ্বিতীয়টি দেখায় ডিস্ট্রিবিউশন এখন কোন রিজলভার ব্যবহার করছে, আর শেষ দুটি প্রতিটি দিকে একই প্রশ্ন রাখে। সেটিংয়ের অবস্থা নয়, উত্তরগুলো তুলনা করুন। দুটি ফাইল ঠিক থাকা সত্ত্বেও পরিচ্ছন্ন পুনরায় চালুর পরেও যে কোয়েরি ব্যর্থ হয় তা কর্পোরেট রিজলভার নীতির দিকে ইশারা করে, আর সেই আলোচনার মালিক অন্য।