দুটি লিনাক্স সার্ভিসের মধ্যে /etc/resolv.conf নিয়ে প্রতিযোগিতা বন্ধ করুন

DNS বারবার আগের অবস্থায় ফিরে যায়, VPN পুনঃসংযোগ আপনার ঠিক করা কাজ বাতিল করে, আর দলের কেউ একসময় ফাইলটি লক করার পরামর্শ দেয়। এই ধারাবাহিকতা একটি লক্ষণ, কোনো সমাধান নয়: দুটি উপাদানই মনে করে তারা /etc/resolv.conf ফাইলের মালিক, আর শেষে যে লেখে সে-ই জেতে। ফাইল লক করা মালিকানার দ্বন্দ্বের সমাধান করে না, শুধু লুকিয়ে রাখে আর সেই সাথে আপনি যে উপাদানটি চেয়েছিলেন সেটিই নষ্ট করে। নিচের চারটি পরীক্ষা ক্রমানুসারে করুন এবং সমাধান করুন যে স্তরের মালিকানা এটি, ফাইলের স্তরে নয়।

পরীক্ষা 1: এটি কি সিমলিংক, আর কোথায়

ফাইলটি দিয়েই শুরু করুন, কারণ আপনি যে পথটি সম্পাদনা করছেন সেটি হয়তো ফাইলই নয়। রেজলভারের রানটাইম ডিরেক্টরিতে যাওয়া একটি সিমলিংক, ক্লায়েন্ট স্ক্রিপ্ট যে সাধারণ ফাইল পুনরায় লেখে তার চেয়ে সম্পূর্ণ ভিন্নভাবে আচরণ করে:

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

systemd-resolved-এর stub পথে যাওয়া লিংকের অর্থ হলো ফাইলের বিষয়বস্তু তৈরি হয়, আর হাতে সম্পাদনা পরের ঘটনায় মুছে যাবে। nameserver লাইনযুক্ত সাধারণ ফাইল সাধারণত সংযোগের সময় চলা যে কোনো ক্লায়েন্ট বা DHCP হুক লেখে। দুটোই বৈধ; আসল কথা হলো কিছু বদলানোর আগে জেনে নেওয়া আপনার কাছে কোনটি আছে।

পরীক্ষা 2: কোন ডেমন চলছে

কী ইনস্টল আছে তা নয়, কী সত্যিই সক্রিয় তা খুঁজে বের করুন। আধুনিক ডিস্ট্রিবিউশনে একাধিক রেজলভার থাকতে পারে, আর লুপব্যাক ইন্টারফেসে পোর্ট 53 ধরে রাখা একটি-ই উত্তর দেয়:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

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

NetworkManager-এর নিজস্ব কনফিগারেশন ঠিক করে সে কোন ব্যাকএন্ড ব্যবহার করবে। প্রধান কনফিগারেশন ফাইলে এর dns= সেটিং তার অভ্যন্তরীণ রেজলভার, dnsmasq, systemd-resolved ও none-এর মধ্যে বাছাই করে, আর ডিস্ট্রিবিউশন হয়তো আপনার হয়ে বেছে নিয়েছে। এই হোস্টে “DNS ঠিক করা” মানে কী তা ঠিক করার আগে ওই সেটিং পড়ুন।

পরীক্ষা 3: VPN ক্লায়েন্টকে কী লেখার অনুমতি আছে

সংঘাত সাধারণত এখানেই থাকে। যে VPN ক্লায়েন্ট সরাসরি রেজলভার ফাইল পুনরায় লেখে সে এমন যেকোনো সার্ভিসের সঙ্গে লড়বে যেটিও এটি রক্ষণাবেক্ষণ করে, আর হারে সে-ই যে আগে চলে। সাম্প্রতিক OpenVPN রিলিজ ফাইল পুনরায় লেখার বদলে DNS সেটিংস systemd-resolved-কে দিতে পারে, যা-ই আপনি চান এমন সহযোগিতামূলক আচরণ; পুরনো স্ক্রিপ্ট আর হাতে লেখা হুক প্রায়ই একটি পুরনো সহায়ক টুল ডাকে বা সহজভাবে ফাইলের উপর লেখে।

WireGuard-এর অবস্থা আকারে একই রকম: ইন্টারফেস কনফিগারেশন নিজে DNS পরিচালনা করে না, চারপাশের টুলিং করে—একটি রেজলভার হেল্পার বা resolved ইন্টিগ্রেশনের মাধ্যমে। এমন দুটি হেল্পার ইনস্টল থাকলে দুটোই সংযোগের সময় নিজেদের দুনিয়ার দৃষ্টিভঙ্গি প্রয়োগ করতে চাইবে।

অনুমান না করে ক্লায়েন্টের up ও down হুক পড়ুন। /etc/openvpn/up.sh বা সমতুল্য ডিরেক্টরিতে কয়েক লাইন shell এমন আচরণ ব্যাখ্যা করে যা নাহলে এলোমেলো দেখায়, আর সেখানেই ক্লায়েন্টকে প্রতিযোগিতা না করে সহযোগিতা করতে বাধ্য করা যায়।

পরীক্ষা 4: মালিকের কাছে ঠিক করুন, ফাইলের কাছে নয়

মালিককে জানার পর সেই মালিকের সমর্থিত ইন্টারফেস দিয়ে DNS কনফিগার করুন। systemd-resolved-এর ক্ষেত্রে এর অর্থ স্থির ফাইলের বদলে প্রতি-লিংক সেটিংস ও রাউটিং ডোমেইন; NetworkManager-এর ক্ষেত্রে সংযোগ প্রোফাইলের DNS সেটিংস ও নির্বাচিত ব্যাকএন্ড; resolvconf ইন্টিগ্রেশন ব্যবহার করা ডিস্ট্রিবিউশনের ক্ষেত্রে ওই হেল্পারের মাধ্যমে লেখা।

ফাইলটিকে অপরিবর্তনীয় করবেন না। অপরিবর্তনীয় অ্যাট্রিবিউট বৈধ DHCP নবায়ন ও VPN আপডেটও বন্ধ করে দেয় সেইগুলোর সঙ্গে যেগুলোর বিরুদ্ধে আপনি লড়ছিলেন, আর সিস্টেমকে এমন অবস্থায় রেখে দেয় যেখানে পরের প্যাকেজ আপগ্রেড বা পুনঃসংযোগ এমন ব্যর্থতা ঘটায় যা কনফিগারেশন দেখে কেউ ব্যাখ্যা করতে পারে না। এটি মালিকানার দ্বন্দ্ব লুকায়, যা-ই আপনি সমাধান করতে চেয়েছিলেন।

যেখানে দুটি উপাদানকে সত্যিই সহাবস্থান করতে হবে, তাদের আলাদা কাজ দিন। নেটওয়ার্ক ম্যানেজার ইন্টারফেস-স্তরের কনফিগারেশনের মালিক হোক, VPN ক্লায়েন্ট একই ইন্টিগ্রেশনের মাধ্যমে প্রতি-লিংক DNS ও ডোমেইন যোগ করুক, আর সরাসরি ফাইল লেখা তৃতীয় স্ক্রিপ্টটি সরিয়ে ফেলুন। systemd-resolved-এর ডকুমেন্টেশন বলে দেয় এটি কোন মোড সমর্থন করে আর প্রতিটি /etc/resolv.conf-এ কী প্রকাশ করে। যতটা নীতি আপনাকে ধরে রাখতে হবে তার সঙ্গে মানানসই মোড বেছে নিন। স্প্লিট DNS গুরুত্বপূর্ণ হলে প্রতি-লিংক ডোমেইনসহ stub বিন্যাস তা রক্ষা করে, আর upstream সার্ভার ফাইলে কপি করা মোড তা নীরবে চ্যাপ্টা করে দেয়।

পুনঃসংযোগের পরে যাচাই করুন, সম্পাদনার পরে নয়

আপনার পরিবর্তনের ঠিক পরে সঠিক দেখানো ফাইল কিছুই প্রমাণ করে না, কারণ পরের ঘটনা তখনো ঘটেনি। যে ধারাবাহিকতা আগে এটি ভাঙত সেটি চালান: টানেল নামিয়ে আবার তুলুন, DHCP লিজ নবায়ন করুন বা ইন্টারফেস টগল করুন, তারপর একই মান আবার পড়ুন।

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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