resolvconf ডেটাবেস থেকে পুরোনো VPN রেকর্ড সরানো

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

নিশ্চিত করুন যে resolvconf-ই অবস্থার মালিক

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

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

লিঙ্কটি অন্য দিকে ইঙ্গিত করলে বা প্যাকেজ অনুপস্থিত থাকলে এখানেই থামুন। যে সামঞ্জস্য-মোড়ক নামটি ধার করেছে এবং অন্য রিজলভার ম্যানেজার সরবরাহ করে, সে এই ডেটাবেসের মালিক নয়।

ডেটাবেস ইনপুট রাখে, উত্তর নয়

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

sudo resolvconf --list
sudo resolvconf -i

প্রথম কমান্ড সরবরাহ করা রেকর্ডগুলো প্রক্রিয়া না করেই ছাপে, আর দ্বিতীয়টি এখন DNS কনফিগারেশন দেয় এমন ইন্টারফেসগুলোর তালিকা দেয়। কী-গুলো সাধারণত ইন্টারফেসের নাম ও সরবরাহকারী প্রোগ্রাম থেকে তৈরি হয়। resolvconf ম্যানুয়াল সেই ডেটাবেসের বর্ণনা দেয় যেটি ওই কী-গুলো সম্বোধন করে।

কী-টি নতুন করে তৈরি না করে আউটপুট থেকে কপি করুন। শুধু একটি পুরোনো স্ক্রিপ্ট ওই নাম ব্যবহার করেছে বলে এন্ট্রিটির নাম tun0 নয়।

প্রমাণ করুন যে রেকর্ডের কোনো মালিক নেই

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

প্রসেসের নাম দুর্বল প্রমাণ। OpenConnect vpnc-script ডাকে, তাই vpnc প্রসেসের জন্য চেক করা বর্তমানে কোন রেকর্ড আছে তা কিছুই বলে না। নতুন সংযোগ পুরোনো একটি রেখে যাওয়া ইন্টারফেসের নামও আবার ব্যবহার করতে পারে, যা কী-টিকে বাস্তবের চেয়ে পুরোনো দেখায়। রেকর্ডের ভেতরের সার্ভার ঠিকানার সঙ্গে এখনও চালু থাকা টানেলগুলোর ঠিকানা মিলিয়ে দেখুন, আর মিলে গেলে থামুন।

মালিক ম্যানেজারের মাধ্যমে স্বাভাবিক সংযোগ বিচ্ছিন্ন করাই প্রথম প্রতিকার। এটি ওই সংযোগ যা ইনস্টল করেছিল তা প্রত্যাহার করে এবং অন্য সরবরাহকারীদের অক্ষত রাখে।

সরানো ও পুনর্লিখন যাচাই করুন

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

resolvconf -u কেবল ওই আপডেট স্ক্রিপ্টগুলো চালায়। এটি কখনও পুরোনো রেকর্ড চিহ্নিত বা মোছে না, আর পুরোনো ইনপুট থেকে পুনর্নির্মাণ একই অবাঞ্ছিত ফাইল তৈরি করে।

নিহত ডিসকানেক্ট হুক রেকর্ডটি রেখে যায়

একবারের পরিষ্কার আগের অবস্থা ফিরিয়ে আনে, আর পরের বাধাপ্রাপ্ত শাটডাউন রেকর্ডটি আবার বসিয়ে দেয়। ভাঙার পথটি হাঁটুন: ক্লায়েন্টের ডিসকানেক্ট হুক, হুকটি যে হেল্পার ডাকে, এবং দুটির যেকোনোটি নিহত হলে কী হয়। বাধাপ্রাপ্ত শাটডাউনই সাধারণ উৎস, কারণ হুকটি একেবারেই চলে না। হুকের এক্সিট স্ট্যাটাস একবার লগ করুন, তাহলে বুঝবেন এটি চুপচাপ ব্যর্থ হচ্ছে কি না।

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

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