OpenVPN active (exited) দেখাচ্ছে? আপনি যে ইনস্ট্যান্সটি চালু করেছিলেন সেটি খুঁজুন

আপনি টানেলটি দেখেন, systemctl status openvpn চালান, আর Main PID ছাড়া ও খালি প্রসেস তালিকা নিয়ে active (exited) পান। স্বাভাবিক পাঠ হলো সার্ভিসটি চালু হয়ে মরে গেছে, তাই আপনি unit খুলে /bin/true খুঁজে পান এবং সিদ্ধান্তে আসেন যে প্যাকেজটি ভাঙা। Debian প্যাকেজিংয়ে ওই অবস্থাটি ডিজাইন অনুযায়ী কাজ করা wrapper, আর টানেলটি বাস করে সে যে instance ইউনিটগুলো চালু করে তার একটিতে। সামগ্রিক ইউনিট কখনও বলবে না কোন ইনস্ট্যান্স এটি তৈরি করেছে।

এই ইউনিটে active (exited) আসলে কী বোঝায়

প্যাকেজ করা ইউনিটটি এক-দফা কাজ: এর ExecStart হলো /bin/true, আর RemainAfterExit=yes-ই একটি শেষ হওয়া ইউনিটকে active (exited) হিসেবে দেখায়। ওই নির্দেশটি সরিয়ে দিলে একই সফল /bin/true কাজ inactive (dead)-এ শেষ হবে, যা ঠিক সেই অবস্থা যেটি মানুষ আশা করে আর উল্টো দিকে ভুল পড়ে। কমান্ডটি কেবল জায়গা রাখার উপাদান, আর ইউনিটটি অন্য ইউনিটগুলোর করা কাজের প্রতিবেদন দেয়। এই বিন্যাসে কিছুই ভাঙা নয়, আর /bin/true বদলালে টানেল নয়, প্যাকেজিং চুক্তি বদলায়।

wrapper প্রতিনিধিত্ব করে। প্যাকেজ কনফিগারেশন বা তার systemd জেনারেটর যে instance ইউনিট সরবরাহ করে, সেগুলোই এটি চালু করে, তাই খালি প্রসেস তালিকা টানেল সম্পর্কে কিছুই প্রমাণ করে না। কোনো ইনস্ট্যান্স নির্বাচিত না থাকলেও wrapper সফল হয় এবং কিছুই চালু করে না। অবস্থাটি বলে wrapper চলেছিল কি না, টানেল আছে কি না তা নয়।

বন্ধনীর শব্দটি নয়, status আউটপুটের তিনটি লাইন পড়ুন। Loaded বলে systemd যে unit ফাইল পড়েছে, Active শেষ সফল চালনার সময়চিহ্ন বহন করে, আর Main PID-এর অনুপস্থিতি শেষ হওয়া এক-দফা কাজের সঙ্গে মেলে। এই তিনটি লাইনই এই wrapper-কে চালু হওয়ার এক সেকেন্ড পরে ভেঙে পড়া সার্ভিস থেকে আলাদা করার উপায়।

status আবার পড়ার আগে ইউনিটগুলোর তালিকা করুন

কী চলছে তা জিজ্ঞাসা করার আগে systemd-কে জিজ্ঞাসা করুন কী আছে। কোনো ইনস্ট্যান্স তৈরি না হলেও একটি টেমপ্লেট ইনস্টল থাকতে পারে, আর কেবল তৈরি হওয়া ইউনিটই টানেল বহন করে। লোড হওয়া সেট দিয়ে শুরু করুন:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

দুটি তালিকা একসাথে পড়ুন, কারণ দ্বিতীয়টিতে টেমপ্লেট আর প্রথমটিতে ইনস্ট্যান্স দুই ভিন্ন উত্তর। থাকা টেমপ্লেট আর চলা ইনস্ট্যান্স একই সত্য নয়, আর কেবল দ্বিতীয়টিই টানেল বোঝায়। প্যাকেজ বিন্যাস ডিস্ট্রিবিউশন ও OpenVPN সংস্করণভেদে আলাদা হয়। পুরোনো openvpn@ টেমপ্লেট, আলাদা client ও server জোড়া, আর ডিস্ট্রিবিউশন wrapper—সবই নিজ নিজ প্যাকেজিংয়ে বৈধ হতে পারে।

আপনি যে টিউটোরিয়াল পেয়েছেন তার নয়, আপনার মেশিনের সঙ্গে মিলিয়ে নিন। অন্যের আউটপুটে ইনস্ট্যান্সের নাম office হতে পারে, আপনার home বা work। যা স্থানান্তরিত হয় তা পদ্ধতি, স্ট্রিং নয়।

ইনস্ট্যান্সের নাম ধরে যে ফাইলটি এটি পড়ে সেখানে যান

upstream client টেমপ্লেটে ইউনিটের কার্যডিরেক্টরি /etc/openvpn/client এবং এর কমান্ড সেখান থেকেই %i.conf নেয়, তাই openvpn-client@office পড়ে /etc/openvpn/client/office.conf। উদাহরণে ভরসা না করে ইনস্টল করা ইউনিটে এই ম্যাপিং নিশ্চিত করুন, কারণ আপনার টেমপ্লেট পুরোনো হতে পারে বা ডিস্ট্রিবিউশনের পুনর্লিখন হতে পারে:

systemctl cat [email protected]

ওই আউটপুটের নিচে দেখানো drop-in গুলো পড়ুন, কারণ .d/-এর অধীনে থাকা ফাইল ExecStart, কার্যডিরেক্টরি বা কনফিগ পথ বদলাতে পারে। আপনি office.ovpn নামে যে প্রোফাইল ডাউনলোড করেছেন, সেটি ইনস্ট্যান্স যে ফাইল খোলে নয়। এই ফাঁকই সাধারণত এমন পথের নাম ওঠার কারণ যা আপনি কখনও সম্পাদনা করেননি।

প্রোফাইলের ভেতরের আপেক্ষিক পথই পরের ফাঁদ। মূল ফাইল সরিয়ে ca, cert ও key রেফারেন্স আপেক্ষিক রাখলে একটি অনুপস্থিত-ফাইল ত্রুটি বদলে যায় অন্য একটি অনুপস্থিত-ফাইল ত্রুটিতে। দ্বিতীয়টি এমন ফাইল দেখায় যা আছে বলে আপনি নিশ্চিত ছিলেন, তাই ফাইলের নামের চেয়ে প্রোফাইল ডিরেক্টরি বেশি গুরুত্বপূর্ণ।

এটি চালু করুন, তারপর ওই ইনস্ট্যান্সের জার্নাল পড়ুন

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

চালু করা ও সক্রিয় করা আলাদা সিদ্ধান্ত: start এখনই ইউনিট চালায়, enable পরের বুটের ব্যবস্থা করে, আর enable --now দুটোই এক ধাপে করে। daemon-reload ইউনিটের সংজ্ঞা আবার পড়ে এবং চলমান প্রসেস পুনরায় চালু করে না বা সম্পাদিত প্রোফাইল প্রয়োগ করে না। প্রোফাইল বদলানোর পর ইনস্ট্যান্স পুনরায় চালু করুন, কারণ সেটিই ফাইলটি আবার পড়ে।

একই টানেলে দ্বিতীয় ম্যানেজার বসাবেন না

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

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

মূল প্রশ্নের উত্তর দিন ইনস্ট্যান্সের নাম, এটি যে ফাইল পড়েছিল এবং যে জার্নাল লাইন ব্যর্থ হয়েছিল তা দিয়ে। systemd সংহতকরণ নিয়ে OpenVPN-এর নোট টেমপ্লেট বিন্যাস ও সেই ফাইল ম্যাপিং বর্ণনা করে যার মধ্য দিয়ে ইনস্ট্যান্সের নাম সমাধান হয়।