ইউনিট -.mount মাস্ক করা: OpenVPN ক্লায়েন্ট চালু হবে না

আপনার সার্ভিস OpenVPN কখনও চলার আগেই ব্যর্থ হয়, আর ত্রুটিটি এমন একটি মাউন্ট ইউনিটের কথা বলে যা আপনি কখনও কনফিগার করেননি। এটিই সংকেত: systemd পুরো লেনদেন প্রত্যাখ্যান করছে কারণ রুট মাউন্ট ইউনিট মাস্ক করা, আর আপনার VPN প্রোফাইল এখনও পড়া হয়নি। সাধারণ কারণ রানটাইম ইউনিট ডিরেক্টরিতে পড়ে থাকা ফাইল, নষ্ট fstab নয় এবং অনুপস্থিত সার্টিফিকেট নয়। আগে ফাইলটির পিছু নিন, কারণ এটিকে বাদ দেওয়াই সবচেয়ে সস্তা ব্যাখ্যা।

ত্রুটি রুট মাউন্টের নাম বলে, আপনার প্রোফাইলের নয়

systemd নিজেই কার্নেলের মাউন্ট তথ্য থেকে রুট মাউন্ট ইউনিট তৈরি করে এবং ইউনিটটিকে -.mount বলে, কারণ ড্যাশ রুট পথ বোঝায়। এই ইউনিট সাধারণত কেবল মেমরিতে থাকে এবং এর পিছনে কোনো ফাইল থাকে না। ত্রুটি যখন বলে এটি মাস্ক করা, তখন কেউ একটি ইউনিট ফাইল সেখানে রেখেছে যেখান থেকে systemd এটি লোড করবে এবং সেই ফাইলটি /dev/null-এর দিকে নির্দেশ করেছে। মাস্ক করা একটি বাস্তব অবস্থা, বার্তায় টাইপের ভুল নয়।

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

OpenVPN ডিবাগ করার আগে রানটাইম ডিরেক্টরি দেখুন

রানটাইম ইউনিট ডিরেক্টরিতে ঠিক ওই নামের একটি ফাইল খুঁজুন, তারপর systemd-কে জিজ্ঞাসা করুন সে ইউনিটটিকে কী মনে করে। দুটি উত্তরই দ্রুত, এবং একসাথে পড়ে থাকা ফাইলকে আসল মাউন্ট সমস্যা থেকে আলাদা করে।

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

সাধারণ মেশিনে এমন ফাইল থাকে না, আর মাস্ক করা তালিকায় রুট মাউন্ট থাকে না। যদি প্রথম কমান্ড /dev/null-এ একটি সিম্বলিক লিঙ্ক ছাপে, তবে নির্ণয় নিশ্চিত। একই ডিরেক্টরিতে একই সরঞ্জাম দিয়ে তৈরি tmp.mount মাস্কও থাকতে পারে, আর তা অন্য নামে একই ধরনের ব্যর্থতা তৈরি করে। পুরো ডিরেক্টরি দেখুন, কেবল ত্রুটির নাম নয়।

ls -la /run/systemd/system/*.mount

যদি ডিরেক্টরি পরিষ্কার হয় আর ইউনিট এখনও মাস্ক করা থাকে, তবে মাস্কটি অনুসন্ধান পথের অন্য জায়গায়, এবং systemctl cat -.mount দেখাবে কোন ফাইল লোড হচ্ছে।

ফাইলটি মুছুন, আবার লোড করুন এবং আবার শুরু করুন

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

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

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

journalctl -u [email protected] -b --no-pager

যেহেতু /run একটি অস্থায়ী ফাইল সিস্টেম, রিবুটও ফাইলটি মুছে দেয়। এটি রিবুটকে একটি উপকারী পরীক্ষা করে তোলে: যদি সার্ভিস রিবুটের পর চলে এবং পরের স্থাপনার পর আবার ব্যর্থ হয়, তবে ফাইলটি ইমেজে বেক করা হচ্ছে।

এটি ইমেজ থেকে ফিরে আসা ঠেকান

কনটেইনার বা ভার্চুয়াল মেশিনের টেমপ্লেট যা নির্মাণের সময় মাউন্ট ইউনিট মাস্ক করে, সেই মাস্ক প্রতিটি ক্লোনে বহন করবে। এরপর যার ফাইল সিস্টেম দরকার তা ভেঙে যায়, আর বার্তাটি যেখান থেকে এসেছে সেই ইমেজের বদলে মাউন্টকে দোষ দেয়। একটি চলমান ইনস্ট্যান্সের ভিতরে মেরামত করলে পরের ইনস্ট্যান্স তৈরি হওয়া পর্যন্ত সমস্যা লুকিয়ে থাকে।

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

যে লক্ষণ মনে রাখা উচিত তা হলো ত্রুটি এবং আপনি যা কনফিগার করছিলেন তার মধ্যে অমিল। যখন systemd মাউন্ট নিয়ে অভিযোগ করে আর আপনি VPN ক্লায়েন্ট চালু করছেন, তখন আগে বার্তায় ইউনিটের নাম পড়ুন, তারপর সার্ভিসের নাম।