OpenVPN কীভাবে সার্টিফিকেট ও কী সমাধান করে: ইনলাইন PEM নাকি ফাইল পাথ

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

দুটি সংরক্ষণ রূপ, একটি নির্দেশিকা

cert, key এবং ca নির্দেশিকাগুলোর প্রতিটি একটি পাথ বা একটি ইনলাইন ব্লক গ্রহণ করে। যখন মানটি পাথ, OpenVPN সেই ফাইলটি খোলে এবং ডিস্ক থেকে অবজেক্টটি পড়ে। যখন কনফিগারেশনে cert ট্যাগ দিয়ে আবদ্ধ একটি ব্লক থাকে, তখন একই নির্দেশিকা বরং সেই ট্যাগগুলোর মধ্যবর্তী বিষয়বস্তু ব্যবহার করে, এবং আলাদা কোনো ফাইল জড়িত থাকে না।

দুটি রূপই শেষে একই ধরনের অবজেক্ট তৈরি করে, তাই একটি কার্যকর ডিপ্লয়মেন্ট অন্য কোনো পরিবর্তন ছাড়াই এদের মধ্যে যেতে পারে। যে প্রোফাইল নিজের ভেতরে ক্লায়েন্ট সার্টিফিকেট ও প্রাইভেট কী বহন করে তা স্বনির্ভর, এবং তা অন্য মেশিনে কপি করা সার্টিফিকেট ডিরেক্টরি না কপিয়েও কাজ করে।

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

একটি ইনলাইন ব্লক কীভাবে অবজেক্টে পরিণত হয়

ইনলাইন বিষয়বস্তু কনফিগারেশন থেকে বের করা হয় এবং টেক্সট হিসেবে PEM পার্সারের কাছে দেওয়া হয়। সেই পার্সার স্বাভাবিক সীমানা প্রত্যাশা করে: একটি BEGIN লাইন, base64 পেলোড এবং মিলে যাওয়া একটি END লাইন। যদি ব্লকটি ব্যর্থ কপিতে কেটে যায়, ডাউনলোড পেজ কর্তৃক HTML-এ মোড়ানো হয়, বা ড্যাশগুলো স্বাভাবিক করে দেওয়া কোনো এডিটরে খোলা হয়, তবে পার্সার উপস্থিত দেখতে এমন বিষয়বস্তুতেই ব্যর্থ হয়।

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

লোড করা প্রোফাইল আসলে কোন রূপ ব্যবহার করছে তা যাচাই করুন, আপনার এডিটর দৈবক্রমে কোন ফাইল খুলেছে তা নয়:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

একটি পাথ রেফারেন্স কীভাবে সমাধান হয়

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

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

আলাদাভাবে সংরক্ষিত সার্টিফিকেটের জন্য, তার ওপরে কিছু ডিবাগ করার আগে একটি অফলাইন পার্স অবজেক্টটি নিশ্চিত করে:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

পার্সার ত্রুটি কী বলতে পারে এবং কী বলতে পারে না

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

পার্স সফল হওয়ার পর, পরবর্তী ব্যর্থতা পরের কোনো পর্যায়ের। ট্রাস্ট প্রত্যাখ্যান, উদ্দেশ্য মিলছে না বা কী মিলছে না, তা জানায় পিয়ার বা TLS স্তর, লোডার নয়। একই ফাইল বারবার বদলালে সেই ত্রুটি সরবে না।

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