OpenVPN পরিষেবা হয়ে যাওয়ার পর client-config-dir উপেক্ষিত

তোমার টানেল উঠে আসে এবং ক্লায়েন্ট সংযোগ করে, কিন্তু নির্দিষ্ট ঠিকানাটি এবং ঐ একজন ব্যবহারকারীর জন্য তুমি যে পুশ করা রুটগুলো নির্ধারণ করেছিলে সেগুলো অনুপস্থিত। লগে “file not found” লেখা নেই, আর ঠিক এটাই মানুষকে সার্টিফিকেট আবার তৈরি করতে পাঠায়। এসব ক্ষেত্রে বেশিরভাগ সময় ডেমনটি তোমার পরীক্ষা করা শেলের চেয়ে ভিন্ন ডিরেক্টরি থেকে চলে, এবং client-config-dir কখনোই তুমি ধরে নেওয়া ভাবে সমাধান হয়নি। সমাধান হলো পথের সংশোধন, শংসাপত্র রিসেট নয়।

কনফিগ স্পর্শ করার আগে ইউনিটটি পড়ো

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

খালি WorkingDirectory মানে ইউনিটটি /-এ শুরু হয়, তাই একটি আপেক্ষিক client-config-dir ccd খোঁজা হয় /ccd-এ। ওই ডিরেক্টরি প্রায় কখনোই থাকে না, আর ডেমন এর অনুপস্থিতিকে মারাত্মক বলে না।

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

আপেক্ষিক পথ কীসের সাপেক্ষে সমাধান হয়

কীওয়ার্ডটি অপশনটি ব্যবহারের মুহূর্তে প্রক্রিয়ার কার্যকারী ডিরেক্টরির সাপেক্ষে সমাধান হয়। এর মানে “আমি যে কনফিগ ফাইল --config দিয়ে পাস করেছি তার পাশে” নয়। OpenVPN আনন্দের সাথে একটি পরম পথ থেকে কনফিগ পড়বে এবং আপেক্ষিক মানগুলো তবুও অন্য জায়গায় সমাধান করবে, আর এখানেই ফাঁদটি। OpenVPN 2.6 ম্যানুয়াল নিয়মটি --client-config-dir এবং আবার --cd-এর অধীনে বলে।

cd কীওয়ার্ডটি অন্য ফাইল পড়ার আগেই সেই প্রসঙ্গ বদলায়, তাই যে ইউনিট cd /etc/openvpn/server সেট করে তারপর client-config-dir ccd, সেটি /etc/openvpn/server/ccd-এ সমাধান হয়। যদি তুমি cd যোগ করো, নির্দেশাবলির ক্রম দেখো এবং মনে রাখো এটি একই ফাইলের অন্য প্রতিটি আপেক্ষিক রেফারেন্সকে প্রভাবিত করে।

ডেমনটির অ্যাকাউন্ট হিসেবে পথটি হাঁটো

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

namei প্রতিটি উপাদানের অনুমতি ক্রমে দেখায়, যা এক এক করে ডিরেক্টরি যাচাইয়ের চেয়ে দ্রুত:

namei -l /etc/openvpn/server/ccd/client1

তারপর নিজের বদলে সার্ভিস অ্যাকাউন্ট হিসেবে পড়াটি পরীক্ষা করো:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

যদি ইউনিটটি chroot ব্যবহার করে, ডিরেক্টরিটি জেলের ভেতরে থাকতে হবে, আর কনফিগারেশনের পথটি chroot প্রয়োগের পরে ব্যাখ্যা করা হয়। জেলের বাইরে হোস্টে থাকা ফাইল ভেতর থেকে অদৃশ্য।

অনুমান না করে লুকআপ নিশ্চিত করো

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

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

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

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

সংশোধন করো, রিস্টার্ট করো, যাচাই করো

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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