OpenVPN প্রোফাইল লোড হলেও ca.crt খুঁজে পায় না

সার্ভিসটি চালু হয়, প্রোফাইল কোনো অভিযোগ ছাড়াই পড়ে, তারপর এমন একটি লাইনে মারা যায় যা অসম্পর্কিত মনে হয়: এটি ca.crt খুলতে পারে না। সার্টিফিকেটে কিছুই বদলায়নি, এবং unit ফাইলের প্রোফাইল পাথ পরম। এই সমন্বয়টাই ইঙ্গিত। যে পাথ আপনি দিয়েছেন তা একটি ফাইল চিহ্নিত করে, আর সেই ফাইলের ভেতরের নামগুলো সম্পূর্ণ অন্য জায়গায় সমাধান হয়, তাই সম্পূর্ণ যোগ্য মনে হওয়া একটি লঞ্চও এমন ডিরেক্টরি থেকে তার কী পড়তে পারে যা কেউ চায়নি।

ব্যর্থতার কারণ অল্প কয়েকটি, এবং সেগুলো ক্রমে আলাদা করা দরকার: প্রসেসের সত্যিকারের ভিত্তি ডিরেক্টরি, সার্ভিসের লঞ্চ প্রসঙ্গ, এবং পাথ ঠিক হওয়ার পর ফাইলের চারপাশের অনুমতি বা স্যান্ডবক্স। প্রত্যেকটি ভিন্ন চিহ্ন রেখে যায় — unit-এ, প্রসেসে এবং ফাইলসিস্টেমে।

প্রোফাইল পাথ কোনো ভিত্তি ডিরেক্টরি নয়

/tmp-এ শুরু হওয়া এবং /etc/vpn/prod/tenant-a.ovpn হাতে পাওয়া একটি প্রসেস কল্পনা করুন। সেই প্রোফাইলের ভেতরে ca ca.crt লাইনটি একটি আপেক্ষিক পাথ নির্দেশ করে। প্রোফাইলটি খুঁজে পাওয়া আর্গুমেন্টের কিছুই সেই নাম পুনর্লিখন করে না, তাই প্রসেসটি /tmp/ca.crt খোঁজে এবং অনুপস্থিত ফাইল জানায়।

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

ম্যানুয়াল কী আলাদা করে: --config এবং --cd

OpenVPN 2.6 ম্যানুয়াল দুটি ভিন্ন অপশন বর্ণনা করে। একটি কনফিগারেশন ফাইল লোড করে। অন্যটি কনফিগারেশন, কী, স্ক্রিপ্ট ও অন্যান্য ফাইল পড়ার আগে প্রসেসের ডিরেক্টরি বদলায়, এবং বর্তমানকে উল্লেখ না করা একটি পরম ডিরেক্টরি দাবি করে।

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

সার্ভিস অন্য জায়গায় শুরু হয়

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

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

সন্ধানের পর: অনুমতি, chroot ও স্যান্ডবক্সিং

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

তিনটি সাধারণ রূপ অভিন্ন ত্রুটি তৈরি করে। ফাইলটি কেবল root-এর জন্য পাঠযোগ্য, অথচ সার্ভিসটি তা খোলার আগেই বিশেষাধিকার ছেড়ে দেয়। unit-টি এমন একটি সুরক্ষামূলক ফাইলসিস্টেম দৃশ্য সেট করে যাতে প্রোফাইল ডিরেক্টরি নেই। ডেমনটি chroot নিয়ে চলে, তাই হোস্টে যে পাথ আছে তা সেই দৃশ্যের ভেতরে নেই।

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

নিজের লঞ্চ দিয়ে সমাধান প্রমাণ করুন

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

প্রোফাইল যদি একটি কনফিগারেশন ম্যানেজার দিয়ে মোতায়েন হয়, তবে ভিত্তি ডিরেক্টরি বা পরম ফাইল নামও সেখানে রাখুন। এক হোস্টে হাতে করা সমাধান এই সমস্যার সেই সংস্করণ যা পরের পুনর্নির্মাণের পরে ফিরে আসে।