resolv.conf সম্পাদনা করলে VPN বিচ্ছিন্ন হওয়ার পর DNS ঠিক হয় না

আপনি VPN বিচ্ছিন্ন করেন, ping 1.1.1.1 এখনও উত্তর দেয়, কিন্তু প্রতিটি নাম লুকআপ ঝুলে থাকে যতক্ষণ না পৃষ্ঠাটি শেষে হাল ছেড়ে দেয়। তারপর cat /etc/resolv.conf এমন একটি নেমসার্ভার দেখায় যা কেবল টানেলের ভিতরেই ছিল, সাধারণত তালিকার প্রথমে। ওই লাইনটি মুছে ফেললে প্রায় দশ মিনিটের জন্য সমস্যা ঠিক হয়েছে মনে হয়, যতক্ষণ না সাসপেন্ড, Wi-Fi রোমিং বা রিস্টার্ট সেটি ফিরিয়ে আনে। আপনি যে ফাইলটি সম্পাদনা করেছেন সেটি সেটিং নয়; এটি লিংক স্টেটের একটি রেন্ডারিং, যার মালিক অন্য একটি কম্পোনেন্ট।

কেন একটি পুরনো এন্ট্রি প্রতিটি লুকআপে সেকেন্ড খরচ করে

glibc রিজলভার নেমসার্ভার তালিকাটি ক্রমে হাঁটে এবং পরেরটি চেষ্টা করার আগে একটি টাইমআউট শেষ হওয়া পর্যন্ত অপেক্ষা করে, এবং resolv.conf(5) ওই তালিকাটি তিনটি এন্ট্রিতে সীমাবদ্ধ করে। টানেল চলে যাওয়ার পর 10.8.0.1-এর মতো টানেল-পাশের রিজলভার তালিকার শীর্ষে রাখুন, তাহলে প্রতিটি লুকআপ উত্তরদানকারী সার্ভারে যাওয়ার আগে টাইমআউটের দাম দেয়। এজন্যই উপসর্গটি DNS ত্রুটির বদলে মৃত সংযোগের মতো দেখায়: ব্রাউজার ব্লক করে, সময় শেষ হয় এবং মাঝে মাঝে একটি ক্যাশ করা ঠিকানা দেয় যা পরে পুরনো হয়ে যায়।

এটি আরও ব্যাখ্যা করে কেন অভিযোগটি আসে «ইন্টারনেট ভেঙে গেছে» হিসেবে। একটি IP ঠিকানায় ping প্রমাণ করে লিংক ঠিক আছে, যা ত্রুটিটিকে অ্যাপ্লিকেশনের মতো দেখায়। রিজলভার তালিকা হলো প্রথম জিনিস যা পড়তে হয় এবং শেষ জিনিস যা সম্পাদনা করতে হয়।

মিথ: resolv.conf একটি সেটিংস ফাইল

পরিবর্তন করার আগে জিজ্ঞাসা করুন পথটি আসলে কী:

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

systemd-resolved হোস্টে এটি 127.0.0.53-এ নির্দেশকারী একটি স্টাব ফাইলের সিমলিংক, এবং আসল সার্ভারগুলো প্রতি-লিংক স্টেটে থাকে যা resolvectl প্রিন্ট করে। NetworkManager হোস্টে এটি এমন একটি ফাইল হতে পারে যা NetworkManager সক্রিয় সংযোগ থেকে লেখে। কিছু ভেন্ডর ক্লায়েন্টে এটি একটি সাধারণ ফাইল যা সংযোগের সময় জায়গায় পুনর্লিখিত হয় এবং, যদি আপনি অসৌভাগ্যবান হন, বিচ্ছিন্ন হওয়ার সময় কখনো পুনরুদ্ধার হয় না। এগুলো তিনটি ভিন্ন মালিক, এবং প্রথম দুটো হাতে সম্পাদনা করা হয় কিছুই করে না, নয়তো পরের নেটওয়ার্ক ইভেন্ট পর্যন্ত টেকে।

resolvectl status হলো সেই ভিউ যা সত্য বলে: প্রতি-লিংক DNS সার্ভার, রাউটিং ডোমেইন এবং টানেল লিংক এখনও আছে কি না। resolvectl query example.com আরও এগিয়ে যায় এবং দেখায় কোন ইন্টারফেস উত্তর দিয়েছে। ফাইল স্পর্শ করার আগে দুটোই ব্যবহার করুন, এবং মনে রাখুন নিজস্ব সিকিউর DNS থাকা ব্রাউজার এসব কিছু উপেক্ষা করে।

কিছু সম্পাদনা করার আগে মালিক খুঁজুন

সাধারণত তিনটি কম্পোনেন্ট একই সেটিংয়ের জন্য প্রতিযোগিতা করে: systemd-resolved, NetworkManager এবং VPN ক্লায়েন্ট যা ইনস্টল করেছে। প্রথমে জীবন্তটি চিহ্নিত করুন:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

যদি resolved সক্রিয় থাকে এবং সিমলিংক তার স্টাবে নির্দেশ করে, তাহলে গ্লোবাল ফাইলটি জেনারেট করা আউটপুট এবং আপনার সম্পাদনা কেবল রূপগত। যদি NetworkManager সংযোগের মালিক হয়, সার্ভারগুলো সংযোগ প্রোফাইলের অন্তর্গত, তাই সমাধান ফাইল সম্পাদনা নয়, nmcli প্রপার্টি পরিবর্তন। যদি ভেন্ডর ডেমন চলছে, তাহলে কেবল তার নিজস্ব পুনরুদ্ধার পথই পরের সংযোগে টিকে থাকে।

ক্লায়েন্ট যে লিংক স্টেট রেখে গেছে তা পরিষ্কার করুন

নিহত ক্লায়েন্ট তার ক্লিনআপ হুক চালাতে পারে না। SIGKILL একেবারেই ধরা যায় না, অথচ SIGINT ও SIGTERM ধরা যায়, তাই জোরপূর্বক হত্যার পর «শুধু থেমে যাওয়া» টানেল প্রায়ই ইন্টারফেস নিবন্ধন ও রিজলভার এন্ট্রি দুটোই জায়গায় রেখে যায়। নির্দিষ্ট PID খুঁজে সেই একটিতেই সিগন্যাল পাঠান:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

পুরো ম্যাচ তালিকা পড়ার আগে pkill -f vpn বা killall vpn-এর দিকে হাত বাড়াবেন না। -f পুরো কমান্ড লাইনের সঙ্গে মেলে, তাই এটি একটি র্যাপার স্ক্রিপ্ট, একটি এডিটর সেশন বা এমন একটি অসম্পর্কিত প্রসেস শেষ করতে পারে যার পাথে ওই স্ট্রিং আছে। ভুল প্রসেস কাজের মাঝে শেষ করাই হলো সেই উপায় যেখানে রিজলভার সমস্যা হারানো ফাইলে পরিণত হয়।

resolvectl revert ওই লিংকের রানটাইম DNS কনফিগারেশন রিসেট করে, যা রিজলভার রিস্টার্ট করার চেয়ে সংকীর্ণ এবং গ্লোবাল ফাইল সম্পাদনার চেয়ে অনেক বেশি সংকীর্ণ। যদি টানেল লিংক সম্পূর্ণ চলে যায়, systemctl restart NetworkManager সংযোগের অবস্থা পুনর্গঠন করে এবং উৎসের থ্রেডগুলো বারবার এই ধাপেই ফিরে আসে। Restart=always থাকা সার্ভিস ম্যানেজার সম্পর্কে সতর্ক থাকুন, কারণ এটি নিহত ক্লায়েন্টকে এবং তার DNS সেটিংসকে সোজা ফিরিয়ে আনতে পারে।

অন্য দিক: পুশ করা DNS যা কখনো পৌঁছায়নি

পুরনো এন্ট্রির প্রতিবিম্ব হলো এমন টানেল যাতে আদৌ কোনো ব্যবহারযোগ্য রিজলভার নেই। প্রোফাইলে DNS অপশন একটি অনুরোধ; সংযোগ পরিচালনা করা কম্পোনেন্টকে তা রিজলভারে হস্তান্তর করতে হয়। যদি লগ দেখায় সার্ভার গৃহীত হয়েছে কিন্তু টানেল লিংকে কোনো DNS সেটিং নেই, তাহলে অনুপস্থিত হলো ইন্টিগ্রেশন, সার্ভার নয়।

হস্তান্তরটি হাতে করে পরীক্ষা করুন, যা «সার্ভার ভুল» এবং «কেউ এটি প্রয়োগ করেনি»-র মধ্যে পার্থক্য করে:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

ক্যাচ-অল রাউটিং ডোমেইন প্রতিটি নাম ওই লিংকে পাঠায়, যা একটি ফুল-টানেল ক্লায়েন্ট চায় এবং যা স্প্লিট DNS ব্যবহার করা উচিত নয়। এই সেটিংস পরের সংযোগে হারিয়ে যায়। NetworkManager-এ এগুলো স্থায়ী করতে স্বয়ংক্রিয় DNS নিষ্ক্রিয় করুন, সংযোগে সার্ভার সেট করুন এবং ডোমেইন যোগ করুন:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

ওয়ার্কঅ্যারাউন্ড যা পরের বিভ্রাট হয়ে ওঠে

সংযোগের আগে resolv.conf কপি করা এবং পরে পুনরুদ্ধার করা runbook-এ একটি বৈধ লাইন, এবং এটি সমাধান নয়, ওয়ার্কঅ্যারাউন্ড। এটি ঠিক তখনই ব্যর্থ হয় যখন গুরুত্বপূর্ণ, কারণ ক্র্যাশ বা জোরপূর্বক রিবুট পুনরুদ্ধার বাদ দেয়। এটি ওয়ার্কঅ্যারাউন্ড হিসেবে লিখে রাখুন যাতে পরের ব্যক্তি এর উপর ভিত্তি না গড়ে।

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

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