SIGKILL-এর পরে OpenVPN DNS রয়ে যায়: আগে মালিক পরীক্ষা করুন

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

তিনটি শর্ত মেরামত নির্ধারণ করে: যে সংকেত প্রক্রিয়াটি শেষ করেছে, যে রিজলভার উপাদান সেটিংস পেয়েছে, এবং টানেল লিঙ্কটি এখনো আছে কি না। এই ক্রমে উত্তর দিন, আর সমাধান সাধারণত কোনো গ্লোবাল ফাইল স্পর্শ না করেই আসে।

কী ধরনের প্রস্থান হয়েছে তা ঠিক করুন

Community সংস্করণের OpenVPN-এ SIGINT এবং SIGTERM দুটোই শালীন প্রস্থানের অনুরোধ। SIGKILL ধরা যায় না: এটি ব্লক বা হ্যান্ডেল করা সম্ভব নয়, তাই কোনো শাটডাউন রুটিন চলার সুযোগ পায় না। সামনের টার্মিনালে সাধারণ Ctrl+C SIGINT তৈরি করে, আর অপেক্ষা ছেড়ে দেওয়া সুপারভাইজার সাধারণত SIGKILL-এ উত্তীর্ণ হয়। পার্থক্যটি গুরুত্বপূর্ণ কারণ কেবল দ্বিতীয় ক্ষেত্রেই নিশ্চিত হয় যে হুকগুলো এড়িয়ে যাওয়া হয়েছে।

screen বা tmux-এর ভিতরে চালালে Ctrl+C কোন সংকেত পাঠায় তা বদলায় না। টার্মিনাল সাধারণত কী করে তা নয়, প্রক্রিয়াটি আসলে কী পেয়েছে তা পরীক্ষা করুন।

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

রিজলভারের মালিক কে তা ঠিক করুন

systemd-resolved, resolvconf-ধাঁচের স্ক্রিপ্ট আর সরাসরি ফাইল পুনর্লিখন—এই তিনটি আলাদা মালিক। প্রথমটি প্রতি-লিঙ্ক সেটিংস মেমরিতে রাখে এবং ইন্টারফেস হারিয়ে গেলে সেগুলো ফেলে দেয়। দ্বিতীয়টি এমন রেকর্ড রাখে যা কিছু মুছে না ফেলা পর্যন্ত থাকে। তৃতীয়টি একটি ফাইল লেখে এবং পুনরুদ্ধারের দায়িত্ব যে লিখেছিল তার উপর ছেড়ে দেয়।

মেরামতের কমান্ড বেছে নেওয়ার আগে মালিক চিহ্নিত করুন। একই উপসর্গের তিনটি আলাদা সঠিক উত্তর আছে, কোনটি ব্যবহৃত হচ্ছে তার উপর নির্ভর করে।

NetworkManager-নিয়ন্ত্রিত VPN ইতিমধ্যেই রিজলভার পরিবর্তনের মালিক হতে পারে। এর উপর আরেকটি সহায়ক যোগ করলে একই লিঙ্কের জন্য দুই মালিক প্রতিযোগিতা করে, আর হেরে যাওয়া পক্ষের অবস্থা পরের পুনঃসংযোগে আবার দেখা দেয়। যদি কোনো ব্যবস্থাপক দায়িত্বে থাকে, সেটিংসটি স্ক্রিপ্টে নয়, ব্যবস্থাপকে ঠিক করুন।

down হুক কী করতে পারে আর কী পারে না

down স্ক্রিপ্টটি TUN/TAP ডিভাইস বন্ধ হওয়ার পর একবার চলে। যোগ করলে down-pre ওই ক্রম উল্টে দেয় এবং ডিভাইসটি এখনো থাকা অবস্থায় স্ক্রিপ্টটি চালায়, যা জীবন্ত লিঙ্ক প্রয়োজন এমন সহায়কদের দরকার।

কোনো নির্দেশই SIGKILL-এর পরে হুক চালু করে না। সুবিধাও down-pre দিয়ে ফিরে আসে না: যদি ডেমনটি user বা group-এ নামে বা chroot-এ ঢোকে, তবে হুকটি যে প্রবেশাধিকার রেখে যায় তা নিয়েই চলে। আমন্ত্রিত হুক তবুও রিজলভার হালনাগাদ করতে ব্যর্থ হতে পারে। OpenVPN রেফারেন্স সংকেত ও কলব্যাক জীবনচক্র কভার করে।

প্রক্রিয়ার প্রস্থান স্ট্যাটাসের পাশে হুকের নিজের ত্রুটি দেখুন। অনুপস্থিত ক্লিনআপ আর ব্যর্থ ক্লিনআপ রিজলভারে একই রকম দেখায়, লগে ভিন্ন।

আসলে যা রয়ে গেছে সেই অবস্থা পরীক্ষা করুন

systemd-resolved ব্যবহার করা সিস্টেমে, resolvectl status দেখায় কোন লিঙ্কটি এখনো VPN DNS সার্ভার বা রাউটিং ডোমেইন বহন করছে। সেই লিঙ্কটি হয়তো চলে যাওয়া কোনো সংযোগের, বা এখনো চালু অন্য কোনো টানেলের।

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

অন্য লিঙ্ক চুরি না করে পুনরুদ্ধার করুন

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

সম্পাদনার আগে নিশ্চিত করুন যে /etc/resolv.conf একটি পরিচালিত সিমলিঙ্ক, তারপর ক্লায়েন্টটি আরেকবার স্বাভাবিকভাবে থামিয়ে আবার DNS দেখুন। যদি দ্বিতীয়বার থামানোয় পরিষ্কার হয়ে যায়, তবে আগের সমস্যাটি কনফিগারেশন নয়, জোরপূর্বক প্রস্থান ছিল।