গেটওয়ে সার্টিফিকেট ঠিক আছে: IKEv2 PEAP লগইন তবুও ব্যর্থ হয় কেন

আপনার VPN গেটওয়ের সার্টিফিকেট বৈধ, চেইনটি যাচাই হয়, তবুও IKEv2 ক্লায়েন্ট সার্টিফিকেটের বৈধতার মেয়াদ নিয়ে বার্তা দিয়ে লগইন প্রত্যাখ্যান করে। প্রথম প্রবৃত্তি হলো গেটওয়ে সার্টিফিকেট আবার ইস্যু করা বা EAP পদ্ধতি বদলানো, এবং দুটোই সাধারণত ভুল। লগইনের চেষ্টা দুটি আলাদা সার্ভার পরিচয় বহন করে: IKE যে গেটওয়ে সার্টিফিকেট ব্যবহার করে, এবং PEAP যে-ই সমাপ্ত করুক তার উপস্থাপিত সার্টিফিকেট। এদের একটি ঠিক আছে, আর অন্যটিই ক্লায়েন্ট থেমে যাওয়ার কারণ।

দুটি পরিচয়, একটি লগইন চেষ্টা

VPN প্রোফাইলের সার্টিফিকেটটি IKE বিনিময়ের অন্তর্গত: এটি প্রমাণ করে যে কনফিগার করা IKE নীতির অধীনে গেটওয়েটিই প্রোফাইলে উল্লিখিত পক্ষ। এখানে যে সার্টিফিকেটটি ব্যর্থ হয় তা অন্য এক কথোপকথনের, অর্থাৎ PEAP যে TLS সেশনটি খোলে তা ব্যবহারকারীকে প্রমাণীকরণকারী পক্ষের সঙ্গে, যা প্রায়ই গেটওয়ে নিজে নয় বরং NPS-এর মতো RADIUS সার্ভার। তৃতীয় একটি যাচাই, ব্যবহারকারীর শংসাপত্র, সেই সেশনের ভেতরেই ঘটে। বৈধ পাসওয়ার্ড মেয়াদোত্তীর্ণ সার্ভার সার্টিফিকেট মেরামত করতে পারে না, আর বৈধ গেটওয়ে সার্টিফিকেট PEAP প্রান্তের জন্য জামিন হতে পারে না।

এই স্তরবিন্যাস ব্যাখ্যা করে কেন এমন জায়গায় সার্টিফিকেট ত্রুটি দেখা যায় যেখানে কেউ কেবল গেটওয়ের সার্টিফিকেটই কনফিগার করেছিল। এটি আরও ব্যাখ্যা করে কেন ওই সার্টিফিকেট পুনরায় ইস্যু করলে কিছুই বদলায় না।

লগের লাইনটি ধাপের সঙ্গে মিলিয়ে পড়ুন

যে বার্তায় কারণ ও তারিখগুলো বলা আছে তা খুঁজুন। বিষয়-ত্রুটির পাশে বৈধতার মেয়াদ নিয়ে অভিযোগ মানে সার্ভার তার কাছে দেওয়া সার্টিফিকেট প্রত্যাখ্যান করেছে, ব্যবহারকারী লগইন প্রত্যাখ্যান করেনি। তারপর ধাপটি খুঁজুন: strongSwan-এর charon লগ EAP বিনিময় শুরুর আগে IKE_SA .* established দেখায়, তাই ওই লাইনের পরে সার্টিফিকেট ত্রুটি EAP পরিচয়ের, আর তার আগের ত্রুটি গেটওয়ের দিকে ইঙ্গিত করে। Windows ক্লায়েন্টের সংযোগ প্যানেলের ধাপ-লেখাও একই কথা বলে।

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

কোন প্রান্ত PEAP সমাপ্ত করে তা খুঁজুন

গেটওয়ে-প্লাস-RADIUS নকশায় গেটওয়ে EAP আগে পাঠায় এবং তা সমাপ্ত করে না। strongSwan-এর eap-radius প্লাগইন বিনিময়টি RADIUS সার্ভারের হাতে দেয়, যার মালিকানায় PEAP TLS সেশন ও তার সার্টিফিকেট থাকে। দুটি লগ মিলিয়ে একটি ব্যর্থ চেষ্টা মেলান এবং নিশ্চিত করুন কোন প্রক্রিয়া ওই সেশনের জন্য সার্টিফিকেট বেছে নিয়েছিল।

NPS-এর ক্ষেত্রে সার্টিফিকেটটিকে স্থানীয় কম্পিউটার স্টোরে থাকতে হবে, সার্ভার প্রমাণীকরণের উদ্দেশ্য বহন করতে হবে, ক্লায়েন্টরা যে নাম আশা করে তার সঙ্গে মিলতে হবে, এবং সার্ভিস অ্যাকাউন্টের পাঠযোগ্য হতে হবে। NPS-এর জন্য Microsoft-এর সার্টিফিকেট প্রয়োজনীয়তা এই শর্তগুলো তালিকাভুক্ত করে। অন্য EAP সার্ভারগুলোর নিজস্ব নির্বাচন-নিয়ম আছে, তাই NPS-এর খুঁটিনাটি FreeRADIUS স্থাপনায় বা উল্টোটাও কপি করবেন না। যে নিয়মটি দুই ক্ষেত্রেই টিকে থাকে সেটি হলো, PEAP সমাপ্তকারী প্রান্তই সেই সার্টিফিকেটের মালিক যা আপনি বদলাতে যাচ্ছেন।

যেখানে EAP সমাপ্ত হয় সেখানেই সার্টিফিকেট বদলান

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

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

ডিরেক্টরির সবচেয়ে নতুন ফাইলটিই ব্যবহৃত হচ্ছে এমন ধরে নেবেন না। সঠিক নাম আর ভুল অনুমতিসহ একটি কপি কিছুই বদলায় না। ফাইলের টাইমস্ট্যাম্প নয়, উপস্থাপিত পরিচয় দিয়েই পরিবর্তনটি বিচার করুন।

কী করা যাবে না

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

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