Debian resolvconf রেকর্ড ক্রম: VPN রেকর্ড আগে রাখুন
VPN-এর নেমসার্ভার বারবার LAN-এর নিচে নেমে যায়, কারণ resolvconf রেকর্ডের নাম সাজায়। interface-order সম্পাদনা করুন, আবার তৈরি করুন এবং দুটি লুকআপ যাচাই করুন।
VPN-এর নেমসার্ভার বারবার LAN-এর নেমসার্ভারের নিচে নেমে যায়, আর /etc/resolv.conf সম্পাদনা করলে সেটি কয়েক মিনিটের জন্য ঠিক হয়। ওই ফাইলটি তৈরি হয়, তাই সমাধান কখনো টেকে না। Debian-এর resolvconf-এ ক্রমের ইনপুট হলো /etc/resolvconf/interface-order, এবং এটি DNS ঠিকানা নয়, রেকর্ডের নাম সাজায়। দুটি ফাইলের যেকোনোটিতে হাত দেওয়ার আগে নিশ্চিত করুন কোন resolver স্ট্যাক আসলে দায়িত্বে আছে।
নিশ্চিত করুন resolvconf-ই আউটপুটের মালিক
শুরু করুন এই প্রশ্নে যে বর্তমান ফাইলটি কে লিখেছে এবং আবার কে লিখবে। resolvconf প্যাকেজ নিজেকে ডাইনামিক resolver কনফিগারেশনের ফ্রেমওয়ার্ক হিসেবে বর্ণনা করে, আর systemd-resolved বা NetworkManager-পরিচালিত resolver চালানো একটি হোস্ট বাইরে থেকে একই রকম দেখাতে পারে, অথচ সম্পূর্ণ ভিন্ন নীতি ব্যবহার করতে পারে।
readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1
যদি রিজলভ হওয়া পথটি resolvconf-এর রানটাইম ডিরেক্টরিতে না পৌঁছায়, এখানেই থামুন: এই রানবুক অন্য স্ট্যাকের জন্য।
এই যাচাইয়ের পরেই resolvconf এখন যে রেকর্ডগুলো ধরে রেখেছে সেগুলো তালিকাভুক্ত করা যায়।
প্যাটার্ন লেখার আগে রেকর্ডগুলো পড়ুন
interface-order সরবরাহকারীর রেকর্ডের নামের সাথে মেলে, ঠিকানা বা কার্নেল ইন্টারফেসের নামের সাথে নয়। কী নিবন্ধিত আছে তা তালিকাভুক্ত করুন, যাতে আপনার প্যাটার্নগুলো বিদ্যমান এন্ট্রিগুলোকে নির্দেশ করে।
ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order
রেকর্ডের নামে সাধারণত একটি প্রত্যয় থাকে যা তার সরবরাহকারীকে চিহ্নিত করে, তাই একটি টানেল রেকর্ড ও একটি DHCP রেকর্ড একই ইন্টারফেস প্রিফিক্স ভাগ করে নিয়েও ভিন্নভাবে সাজতে পারে। ডিরেক্টরি তালিকা থেকে হুবহু নামগুলো কপি করুন। ইন্টারফেসের নাম থেকে নাম অনুমান করবেন না, কারণ ক্লায়েন্ট ইন্টিগ্রেশনই ঠিক করে সে কী নিবন্ধন করবে। আপনি বানানো নাম কখনো মিলবে না, আর রেকর্ডটি কোনো ত্রুটি বার্তা ছাড়াই সব-ধরা প্যাটার্নে পড়ে যাবে।
ক্রমটি প্রথম-মিল প্যাটার্ন হিসেবে লিখুন
ফাইলটি shell glob প্যাটার্নের তালিকা, প্রতি লাইনে একটি। একটি রেকর্ড যে প্রথম প্যাটার্নের সাথে মেলে তার অবস্থান নেয়, তাই নির্দিষ্ট প্যাটার্নের উপরে একটি বিস্তৃত প্যাটার্ন থাকলে নির্দিষ্ট লাইনটি অপ্রাপ্য হয়ে যায়।
# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*
নির্দিষ্ট টানেল প্যাটার্নটি সব-ধরা প্যাটার্নের উপরে এবং ফিজিক্যাল ইন্টারফেস প্যাটার্নের উপরে রাখুন।
ফাইলে আগে থেকে থাকা অন্য লাইনগুলো রাখুন। পুরো নীতি একটি উদাহরণ দিয়ে বদলে দেওয়া হলো সেই উপায় যেখানে অসম্পর্কিত সরবরাহকারীরা নিঃশব্দে সরে যায়; একটি লাইন বদলান, আবার তৈরি করুন এবং তুলনা করুন। প্যাটার্নে হোয়াইটস্পেস, স্ল্যাশ বা শুরুতে বিন্দু বা টিল্ডে থাকতে পারে না, আর খালি লাইন ও হ্যাশ মন্তব্য উপেক্ষা করা হয়।
আবার তৈরি করুন এবং ফলাফল যাচাই করুন
আপডেট স্ক্রিপ্টগুলো ফাইলটি পুনর্নির্মাণ করলে ক্রমটি কার্যকর হয়। তৈরি হওয়া আউটপুট সম্পাদনার বদলে সমর্থিত আপডেট পথটি চালান, তারপর resolver আসলে কী পেয়েছে তা পড়ুন।
resolvconf -u
cat /etc/resolv.conf
একটি নয়, দুটি লুকআপ যাচাই করুন: একটি প্রাইভেট নাম যা টানেলের মাধ্যমে রিজলভ হওয়া উচিত, এবং একটি পাবলিক কন্ট্রোল নাম। যদি ক্রম ঠিক দেখালেও প্রাইভেট নামটি এখনো ব্যর্থ হয়, তবে সমস্যাটি রেকর্ড অগ্রাধিকার নয়, নেমস্পেস রাউটিং, এবং কোনো পুনর্বিন্যাসই তা সারাবে না। প্রতিটি উত্তর শুধু সফলতার সাথে নয়, যে সার্ভারটি তা ফিরিয়েছে তার সাথে মিলিয়ে দেখুন। ভুল resolver-এর দেওয়া প্রাইভেট নামের উত্তরও ব্যর্থতা, এবং ব্যবহারকারীর কাছে তা DNS বিভ্রাটের মতো দেখায়।
পুরোনো রেকর্ডটিকে পদাবনতি না দিয়ে অবসরে পাঠান
সংযোগ বিচ্ছিন্ন হওয়ার পরেও বারবার ফিরে আসা একটি অচল VPN রেকর্ড ক্লায়েন্ট ইন্টিগ্রেশনের জীবনচক্রের ত্রুটি. এটি একেবারে নিচে সরিয়ে দিলে উপসর্গটি লুকিয়ে যায় এবং তালিকায় একটি মৃত resolver থেকে যায়।
যে কম্পোনেন্টটি এটি নিবন্ধন করে তার মাধ্যমে এটি অবসরে পাঠান, তারপর নিশ্চিত করুন রেকর্ড ডিরেক্টরিতে আর এটি নেই।
সরবরাহকারীর নাম, আপনি যে প্যাটার্নটি বদলেছেন এবং যে দুটি লুকআপ চালিয়েছেন তা লিখে রাখুন। পরের মানুষের গল্পের চেয়ে ওই নামগুলোই বেশি দরকার।