সঠিক VPN পাসওয়ার্ড অনুপস্থিত সার্টিফিকেটের বিকল্প নয়

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

পাসওয়ার্ড একটি গোপন তথ্য জানার প্রমাণ দেয়; সার্টিফিকেট একটি কী ধারণের প্রমাণ দেয়, এবং একটি অন্যটির বিকল্প নয়।

পাসওয়ার্ড কখনোই সমস্যা ছিল না

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

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

ক্লায়েন্ট স্টোরে কী থাকতে হবে

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

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

দুটি পণ্য, একই অনুপস্থিত শংসাপত্র

OpenVPN সার্ভার ডিফল্টভাবে একটি ক্লায়েন্ট সার্টিফিকেট চায়। ক্লায়েন্টে auth-user-pass যোগ করলে ব্যবহারকারীর নাম ও পাসওয়ার্ড পাঠায়, এবং TLS হ্যান্ডশেক তবুও সার্টিফিকেট চায়, তাই শুধু পাসওয়ার্ড verify-client-cert require-এর অধীনে সংযোগ সম্পূর্ণ করতে পারে না। সার্ভারকে কিছু না চাইতে সেট করা যায়, যা পাসওয়ার্ডকে একমাত্র ক্লায়েন্ট শংসাপত্র করে তোলে এবং এটি শক্তির প্রকৃত হ্রাস। auth-user-pass-verify-এর পেছনের একটি shell স্ক্রিপ্ট শংসাপত্র যাচাই করতে পারে, এবং এতে স্ক্রিপ্ট চালানো সক্রিয় থাকা দরকার, যা এটিকে যথাযথ প্রমাণীকরণ ব্যাকএন্ডের চেয়ে ঝুঁকিপূর্ণ নকশা করে তোলে।

কেবল পাসওয়ার্ডনির্ভর প্রোফাইলও পুশ করা অপশনের উপর নির্ভর করে, যা আবার টান প্রক্রিয়া সক্রিয় থাকার উপর নির্ভর করে।

চেক বন্ধ করে অনুপস্থিত সার্টিফিকেট ঠিক করবেন না

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

কোন স্টোরে সার্টিফিকেটটি ছিল, কোন ব্যবহারকারী ক্লায়েন্ট চালিয়েছিলেন এবং প্রাইভেট কী উপস্থিত ছিল কি না তা লিখে রাখুন। এই তিনটি প্রায় প্রতিটি ঘটনা ব্যাখ্যা করে।

পাসওয়ার্ড ঠিকই ছিল। পদ্ধতির আসলে যে শংসাপত্র দরকার ছিল তা অন্য জায়গায় ছিল।