OpenSSL 3-এর পরে OpenVPN কী প্রম্পট: প্রোভাইডার যাচাই করুন

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

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

কী এনক্রিপ্ট করা কি না তা যাচাই করুন

ফাইলের প্রথম লাইনটি পড়ুন, তারপর লাইব্রেরিকে সেটি পার্স করতে দিন, কারণ ফাইলের নাম কিছুই প্রমাণ করে না। যে PEM ব্লকে ENCRYPTED PRIVATE KEY লেবেল আছে তা এনক্রিপ্টেড PKCS#8, আর পুরোনো RSA PRIVATE KEY ব্লক যাতে Proc-Type: 4,ENCRYPTED থাকে তা প্রচলিত রূপ; দুটিই পাসফ্রেজ আশা করে। এনক্রিপ্ট না করা PRIVATE KEY ব্লককে আদৌ পাসফ্রেজ চাওয়া উচিত নয়। যে অ্যাকাউন্ট ফাইলটির মালিক সেই অ্যাকাউন্ট দিয়ে পার্সটি চালান, কারণ অনুমতির সমস্যা ভিন্ন এবং অনেক কম আকর্ষণীয় ত্রুটি দেয়।

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

এই বিল্ড এটি ডিক্রিপ্ট করতে পারে কি না তা যাচাই করুন

OpenSSL 3 তার অ্যালগরিদম সমর্থনকে প্রোভাইডারে ভাগ করেছে, আর কিছু পুরোনো সাইফার এখন ডিফল্ট প্রোভাইডারের বদলে legacy প্রোভাইডারে থাকে। সেই সাইফারগুলোর একটিতে এনক্রিপ্ট করা কী বৈধই থাকে, তবু legacy প্রোভাইডার ছাড়া লোড করা লাইব্রেরি সেটি ডিক্রিপ্ট করতে পারে না। কিছু ক্লায়েন্টে এটি বারবার আসা প্রম্পট হিসেবে দেখা যায়, অন্যগুলোতে পাসফ্রেজের ঠিক পরেই কঠিন ব্যর্থতা হিসেবে।

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

সবচেয়ে সংকীর্ণ সমাধানটি যাচাই করুন

সিস্টেমব্যাপী পরিবর্তনের বদলে ক্লায়েন্টে সীমিত পরিবর্তনকে প্রাধান্য দিন। কিছু 2.6 বিল্ড এমন প্রোফাইল অপশন গ্রহণ করে যা ওই ডেমন প্রসেসের জন্য দুটি প্রোভাইডারই লোড করে, তাই নির্ভর করার আগে আপনার সঠিক সংস্করণের ম্যানুয়ালে নির্দেশনাটি মিলিয়ে নিন; বরং সিস্টেমের openssl.cnf সম্পাদনা করলে হোস্টের প্রতিটি OpenSSL প্রোগ্রামে প্রভাব পড়ে। সংকীর্ণ সেটিংটি কী পুনরায় এনকোড হওয়ার পর ফিরিয়ে নেওয়াও অনেক সহজ।

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

সেবার পরিপ্রেক্ষিত যাচাই করুন, তারপর পুনরায় এনকোড করুন

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

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

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

প্রম্পট অন্তত তিনটি কারণসহ একটি লক্ষণ, আর তাদের মধ্যে কেবল একটি হলো অনুপস্থিত পাসফ্রেজ।