WSL 2-এ resolv.conf: VPN সংযুক্ত হলে DNS বন্ধ হয়ে যায়

ডিস্ট্রিবিউশনের ভিতরে ব্রাউজিং কাজ করে, আর টানেল ওঠার সঙ্গে সঙ্গে প্রথম অভ্যন্তরীণ হোস্টনেম ব্যর্থ হয়। প্রতিক্রিয়া হলো একটি পাবলিক রিজলভার যোগ করা, যা ইন্টারনেট ফিরিয়ে আনে এবং বাকি দিনের জন্য কর্পোরেট নামটি অপ্রাপ্য করে তোলে। WSL 2-এ /etc/resolv.conf কনফিগারেশন নয়, তৈরি করা আউটপুট, এবং এই প্রক্রিয়াটিই বোঝার যোগ্য। সমাধান আরও ভালো রিজলভার নয়, ফাইলের মালিকানা।

ফাইলটি তৈরি হয়, কনফিগার করা হয় না

WSL 2 স্টার্ট-আপে ওই মুহূর্তে যে Windows অ্যাডাপ্টার দেখতে পায় সেগুলো থেকে ফাইলটি লেখে, আর উপরে একটি মন্তব্য ছাপে যা তা বলে। পরে কোনো VPN ক্লায়েন্ট অ্যাডাপ্টার যোগ বা পুনর্লিখন করলে ডিস্ট্রিবিউশন অগত্যা কিছু পুনরায় তৈরি করে না, এবং ফাইলটি এমন একটি নেটওয়ার্কের বর্ণনা দিতে থাকে যা আর নেই।

দ্বিতীয় ব্যর্থতার ধরনটি আরও নীরব: WSL শুধু কিছু অ্যাডাপ্টার থেকে সার্ভার কপি করতে পারে। যদি ফিজিক্যাল অ্যাডাপ্টারের ইতিমধ্যে IPv6 রিজলভার থাকে, তবে VPN অ্যাডাপ্টার যে IPv4 সার্ভার দেয় সেগুলো যোগ না হয়ে বাদ পড়তে পারে, আর ফাইলটি সম্পূর্ণ দেখায় যদিও ঠিক যে সার্ভারটি অভ্যন্তরীণ নামের উত্তর দেয় সেটিই বাদ পড়ে।

Windows-এর দৃশ্যকে Linux-এর দৃশ্যের সঙ্গে তুলনা করুন

সম্পাদনার আগে দুই দিকই পড়ুন। ডিস্ট্রিবিউশনের ভিতরে দেখুন ফাইলটিতে কী আছে এবং এটি সাধারণ ফাইল না লিংক। Windows-এ প্রতিটি অ্যাডাপ্টারের রিজলভার তালিকাভুক্ত করুন, VPN যে অ্যাডাপ্টার তৈরি করেছে সেটি সহ:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

যখন VPN অ্যাডাপ্টার কর্পোরেট সার্ভার দেখায় আর Linux অন্য কিছু দেখায়, তখন অমিলটি পৌঁছানোর ক্ষমতায় নয়, তৈরির প্রক্রিয়ায়। অ্যাড্রেসের পাশাপাশি অ্যাডাপ্টার তালিকাও তুলনা করুন, কারণ অনুপস্থিত অ্যাডাপ্টার অনুপস্থিত সার্ভারের ব্যাখ্যা দেয়। এই পার্থক্যই ঠিক করে আপনি WSL সারছেন না ফায়ারওয়াল, আর দুটির মধ্যে কোনো মিল নেই।

তৈরি করা বন্ধ করুন এবং নিজের ফাইল লিখুন

একটি নথিভুক্ত সেটিং WSL-কে ফাইলটি পুনর্লিখন থেকে থামায়, আর তা আছে /etc/wsl.conf-এ। ওই ফাইলে একটি নেটওয়ার্ক বিভাগ যোগ করুন:

[network]
generateResolvConf = false

তারপর Windows থেকে wsl --shutdown দিয়ে ডিস্ট্রিবিউশন বন্ধ করুন এবং আবার চালু করুন। যদি পথটি সাধারণ ফাইল না হয়ে সিমলিংক হয়, নিজের বিষয়বস্তু লেখার আগে লিংকটি সরান, কারণ লিংকের মধ্য দিয়ে লেখা পরের স্টার্টে তৈরি করা টার্গেট পুনরায় বানাতে পারে। সেই মুহূর্ত থেকে ফাইলটি আপনার এবং কিছুই তা পুনর্লিখন করে না।

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

সার্চ ডোমেইন ছাড়া, অযোগ্য হোস্টনেম পাবলিক রুট দিয়ে সম্পূর্ণ হয় এবং ‘এমন কোনো ডোমেইন নেই’ হিসেবে ফেরে। timeout মৃত প্রথম সার্ভারকে প্রতিটি লুকআপ আটকে দেওয়া থেকে বিরত রাখে, attempts একটি লুকআপ কতবার চেষ্টা খরচ করবে তা সীমিত করে, আর rotate পুনঃচেষ্টাগুলো সবসময় ওপর থেকে শুরু না করে ছড়িয়ে দেয়। বিনিময় হলো ফাইলটি আর এমন VPN অনুসরণ করে না যার রিজলভার অ্যাড্রেস সেশন বদলে যায়।

যে রিজলভার সরে যায় তা সামলান, তারপর যাচাই করুন

কিছু ক্লায়েন্ট সেশন-নির্দিষ্ট রিজলভার দেয়, তাই স্থির ফাইল পরের সংযোগে ভেঙে যায়। দুইটি পদ্ধতি যুক্তিসঙ্গত। অ্যাড্রেস বদলালে ছোট স্ক্রিপ্ট থেকে ফাইলটি লিখুন, অথবা তৈরি করা চালু রেখে নিশ্চিত করুন WSL যে অ্যাডাপ্টার থেকে কপি করে সেটি কর্পোরেট সার্ভার বহন করে। দ্বিতীয়টির কোনো হুক লাগে না এবং তৈরি করা যখন VPN অ্যাডাপ্টার এড়িয়ে যায় তখন ব্যর্থ হয়; দুটিরই আগে IPv6 দ্বন্দ্ব সমাধান করা প্রয়োজন।

Windows তার নিজস্ব নাম-নীতি প্রয়োগ করে, যেমন সাফিক্স সার্চ তালিকা বা নির্দিষ্ট ডোমেইনের জন্য রিজলিউশন নীতি, আর অ্যাডাপ্টার অ্যাড্রেস কপি করলে সেই নিয়মগুলো পুনরুৎপন্ন হয় না। যদি একটি নাম Windows-এ রিজলভ হয় কিন্তু একই সার্ভার দিয়ে ডিস্ট্রিবিউশনে না হয়, টানেলকে দোষ দেওয়ার আগে সাফিক্স পরিচালনা তুলনা করুন।

প্যাকেট নয়, নাম দিয়ে পরীক্ষা করুন: getent hosts sensor-access0.corp.example রিজলভার স্ট্যাকের মধ্য দিয়ে যায়, আর একটি ping ক্যাশ করা বা আক্ষরিক অ্যাড্রেসের বিরুদ্ধে সফল হতে পারে। তারপর সংযোগ বিচ্ছিন্ন ও পুনঃসংযোগের পর পুনরাবৃত্তি করুন, কারণ যে সেটিং একবার কাজ করে এবং রিজিউমে আবার তৈরি হয় তা কখনও সারানো হয়নি। আগের বিষয়বস্তু সংরক্ষণ করুন এবং ওই মেশিনে কোন কম্পোনেন্ট পথটির মালিক তা টুকে রাখুন, যাতে পরের পরিবর্তন প্রমাণ দিয়ে শুরু হয়।