কেন resolv.conf আপনার VPN DNS দেখায় কিন্তু লুকআপ তা উপেক্ষা করে

লগে কিছুই ভুল দেখাচ্ছে না: ইন্টারফেস চালু, রিজলভার VPN-এর DNS সার্ভার রিপোর্ট করছে, আর ডিস্কের ফাইলটি তা তালিকাভুক্ত করছে। তবুও একটি অভ্যন্তরীণ হোস্টনেম এখনো স্থানীয় রাউটারের মাধ্যমে সমাধান হচ্ছে। এই তিনটি বিবৃতি পরস্পরবিরোধী নয়, কারণ ফাইল, প্রতি-লিঙ্ক অবস্থা আর লুকআপ পথ তিনটি ভিন্ন বস্তু যারা কেবল একই নাম ভাগ করে। নিচে বর্ণিত হয়েছে systemd-resolved হোস্টে একটি কোয়েরি আসলে যে পথ নেয়।

resolv.conf নামের তিনটি বস্তু

resolved হোস্টে /etc/resolv.conf সাধারণত /run/systemd/resolve/stub-resolv.conf-এর প্রতি একটি সিমলিঙ্ক। ওই লক্ষ্যে থাকে স্থানীয় stub লিসেনারের ঠিকানা, 127.0.0.53, সাথে resolved-এর গণনা করা সার্চ ডোমেইনগুলো। এটি অবস্থার একটি দৃশ্য, অবস্থা নিজে নয়।

অবস্থা থাকে resolved-এর প্রতি-লিঙ্ক কনফিগারেশনে, তাই resolvectl status ফাইলের সাথে অসঙ্গত হতে পারে এবং তবুও সঠিক থাকতে পারে। প্রতিটি লিঙ্ক নিজের সার্ভার ও নিজের রাউটিং ডোমেইন বহন করে, আর কোয়েরি এলে stub সেই প্রতি-লিঙ্ক তথ্য দেখে। systemd-resolved ম্যানুয়াল তৈরি হওয়া ফাইল ও প্রতি-লিঙ্ক মডেল বর্ণনা করে; দৃশ্য ও অবস্থার মধ্যকার বিভাজনই মনে রাখার মতো অংশ। সিমলিঙ্কের লক্ষ্য বদলালে ঐতিহ্যবাহী ক্লায়েন্ট যা পড়ে তা বদলায়, রিজলভার যা জানে তা নয়।

তৃতীয় বস্তু, /run/systemd/resolve/resolv.conf, প্রতিটি লিঙ্ককে এক সার্ভার তালিকায় সমতল করে। ওই ফাইলের দিকে লক্ষ্য করা প্রোগ্রাম কোয়েরি সরাসরি তালিকাভুক্ত সার্ভারগুলোতে পাঠায় এবং stub এড়িয়ে যায়, তাই প্রতি-লিঙ্ক নীতি তার ওপর আর প্রযোজ্য হয় না। ফলে একই মেশিনের দুটি প্রোগ্রাম একই নামে ভিন্ন উত্তর দিতে পারে, আর কোনোটিই নষ্ট নয়।

NSS-এর মধ্য দিয়ে একটি লুকআপ অনুসরণ করুন

glibc নামের উত্তর কে দেবে তা ঠিক করতে /etc/nsswitch.conf পড়ে। যে hosts লাইনে resolve আছে তা প্রশ্নটি nss-resolve-এ পাঠায়, যা D-Bus-এর মাধ্যমে resolved-কে জিজ্ঞাসা করে প্রতি-লিঙ্ক উত্তর পায়। শুধু files dns থাকা লাইন কোয়েরিটি /etc/resolv.conf যে ঠিকানা ধরে আছে সেখানে পাঠায়।

এই একটি লাইনই ব্রাউজার আর dig-এর মধ্যে বেশিরভাগ মতবিরোধ ব্যাখ্যা করে। dig সরাসরি resolv.conf পড়ে এবং NSS স্পর্শ করে না, তাই এটি অ্যাপ্লিকেশনের ব্যবহৃত পথ নয়, বরং stub বা আপস্ট্রিম সার্ভার পরীক্ষা করে। getent hosts internal.example NSS-এর মধ্য দিয়ে যায়, আর এর উত্তর dig-এর উত্তরের সাথে তুলনা করাই প্রথম কাজের মাপ।

যে অ্যাপ্লিকেশন নিজের রিজলভার বহন করে, বা নির্দিষ্ট এন্ডপয়েন্টে HTTPS-এর ওপর DNS বলে, তারা দুই পথই এড়িয়ে যায়। resolv.conf বা resolved অবস্থার কিছুই তাদের বাধা দেয় না।

ফাইলের মালিক কে এবং তা কোথায় নির্দেশ করে দেখুন

কিছু বদলানোর আগে লিঙ্ক শৃঙ্খল পড়ুন, কারণ মালিকানাই ঠিক করে কোন ফাইল প্রামাণ্য। নিচের প্রতিটি কমান্ড কেবল অবস্থা পড়ে।

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

প্রথম লাইনটি লিঙ্ক ও তার লক্ষ্য একসাথে ছাপায়, আর VPN স্ক্রিপ্টের মালিকানাধীন সাধারণ ফাইল মানে রিজলভার ওই লেখাকে কখনো ইনপুট হিসেবে নেয় না। স্টেটাস আউটপুট প্রতি-লিঙ্ক সার্ভার এবং প্রতিটি কোয়েরি কোথায় যাবে তা ঠিক করা রাউটিং ডোমেইন তালিকাভুক্ত করে। nsswitch লাইন বলে stub আদৌ দেখা হয় কি না, তাই ফাইলে stub ঠিকানা থাকলেও সেখানে resolve না থাকলে কোয়েরি স্থানীয় লিসেনারে পৌঁছায় অথচ বিভাজন কিছুই পরিচালনা করে না। ওই শেষ তালিকাটিও গুরুত্বপূর্ণ, কারণ stub-resolv.conf ছাড়া হোস্ট এখানে বর্ণিত ব্যবস্থাটি চালায় না।

শৃঙ্খল যদি অন্য প্যাকেজের পরিচালিত ফাইলে শেষ হয়, তবে VPN ক্লায়েন্ট আর সেই প্যাকেজই মিলিয়ে নেওয়ার দুই মালিক। লিঙ্ক প্রতিস্থাপন করলে এক মালিকের কাজ নষ্ট হয় আর অন্যজনের কাজ জায়গায় থাকে।

লিঙ্কের মালিকের কাছে মেরামত করুন

একটি VPN সংযোগের উচিত নিজের লিঙ্কে নিজের সার্ভার ও ডোমেইন নিবন্ধন করা, তারপর সংযোগ বিচ্ছিন্ন হলে সেগুলো প্রত্যাহার করা। NetworkManager-এর resolved ইন্টিগ্রেশন আর ক্লায়েন্টের নিজস্ব হেল্পার দুটোই এভাবেই কাজ করে; যে স্ক্রিপ্ট কেবল resolv.conf পুনর্লিখন করে তা করে না।

আগেই আছে এমন লিঙ্কে রানটাইম সেটিংসই পদ্ধতিটি দেখায়। resolvectl dns tun0 10.40.0.53 একটি সার্ভার যুক্ত করে, আর resolvectl domain tun0 '~corp.example' একটি রাউটিং ডোমেইন যুক্ত করে। টিল্ডা (~) হলো ভারবাহী অক্ষর: এটি ওই সাফিক্সের কোয়েরি এই লিঙ্কে সীমিত রাখে আর বাকি সবকিছু অক্ষত রাখে, অথচ ছাড়া একই মান সার্চ ডোমেইন হয়ে যায় আর বিভাজন বাষ্প হয়ে যায়। ওই ঠিকানাগুলো ল্যাব উদাহরণ, স্থায়ী কনফিগারেশন নয়। resolvectl query host.corp.example দিয়ে নিশ্চিত করুন এবং কোন লিঙ্ক উত্তর দিল তা পড়ুন।

নিবন্ধিত সার্ভারের তবুও একটি রুট দরকার। কোয়েরি সঠিক লিঙ্কে পৌঁছে সময় শেষ হলে দোষটি রিজলভার মালিকানায় নয়, টানেলের মধ্য দিয়ে পৌঁছানোর সামর্থ্যে।

কর্মক্ষম অবস্থা কেমন দেখায়

সুস্থ ফলাফল তিনটি দৃশ্যেই সামঞ্জস্যপূর্ণ: প্রতি-লিঙ্ক সার্ভারগুলো VPN যা দিয়েছে তার সাথে মেলে, রাউটিং ডোমেইনগুলো কেবল অভ্যন্তরীণ সাফিক্স ঢাকে, আর গুরুত্বপূর্ণ অ্যাপ্লিকেশন একটি অভ্যন্তরীণ নাম সমাধান করে যখন একটি পাবলিক নাম এখনো স্থানীয় পথ অনুসরণ করে। একটি সফল কোয়েরি ওই ঐক্যের চেয়ে কম প্রমাণ করে।

তারপর সংযোগ বিচ্ছিন্ন করে দুটি কোয়েরিই পুনরাবৃত্তি করুন। যে ক্লায়েন্ট টিয়ারডাউনের পরেও তার ডোমেইন নিবন্ধিত রেখে দেয় সে এমন মেশিন তৈরি করে যা ঘণ্টা পরে অভ্যন্তরীণ লুকআপে ব্যর্থ হয়, কোনো টানেল খোলা না রেখে এবং স্পষ্ট কারণ ছাড়াই।