IKEv2 বিনিময় কাজ করে, তারপর প্রমাণীকরণ ব্যর্থ হয়: কোথায়

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

যাচাই 1: বার্তা নয়, ধাপটি পড়ুন

প্রত্যাখ্যান তিন জায়গা থেকে আসতে পারে: ক্লায়েন্ট সার্ভারের পরিচয় প্রত্যাখ্যান করে, গেটওয়ে ক্লায়েন্টের প্রমাণ প্রত্যাখ্যান করে, এবং একটি বাইরের প্রমাণীকরণ সেবা অ্যাকাউন্টটি প্রত্যাখ্যান করে।

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

যাচাই 2: কোন পরিচয় যাচাই করা হয়েছে

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

strongSwan-এর পরিভাষায় এটি হলো rightid ক্লায়েন্টে, আর অপর প্রান্তে গেটওয়ের নিজের পরিচয়, এবং অমিল হলে EAP নিয়ে আলোচনার আগেই ব্যর্থ হয়।

গেটওয়ে আলাদাভাবে ক্লায়েন্টের সার্টিফিকেট, তার কী-প্রমাণ বা তার অ্যাকাউন্ট প্রমাণীকরণ প্রত্যাখ্যান করতে পারে, আর এই তিনটি একে অপরের বিকল্প নয়। ব্যবহারকারীর পাসওয়ার্ড রিসেট করলে ডিভাইসের সার্টিফিকেট নবায়ন হয় না, আর ডিভাইসের সার্টিফিকেট পুনরায় ইনস্টল করলে ভুল সার্ভার পরিচয় ঠিক হয় না। সার্টিফিকেট ব্যর্থতায় আগে ঘড়ি দেখুন, তারপর বিশ্বাসের শৃঙ্খল, তারপর প্রত্যাশিত শনাক্তকারী; যে ক্লায়েন্টের ঘড়ি কয়েক মিনিট পিছিয়ে, সে বৈধতার যাচাইয়ে ব্যর্থ হয় যা বিশ্বাসের ব্যর্থতার মতো দেখায়। swanctl --list-certs দুই প্রান্তে দেখায় প্রতিটি পক্ষের কাছে আসলে কী আছে।

যাচাই 3: যদি EAP জড়িত থাকে

ক্লায়েন্ট ও সার্ভারকে একটি সমর্থিত পদ্ধতিতে একমত হতে হবে, আর ব্যাকএন্ডকে দেওয়া পরিচয়টি গ্রহণ করতে হবে।

ব্যবহারকারীর নামে ডোমেইন প্রত্যয় বা নির্দিষ্ট অ্যাকাউন্ট বিন্যাস লাগতে পারে যা স্থাপনাটি দাবি করে, আর বিন্যাসটি নথিভুক্ত, অনুমানযোগ্য নয়। অপারেটরের নথিভুক্ত ক্ষেত্রগুলি দেওয়া নানা রকম চেষ্টা করার চেয়ে দ্রুত, এবং এটি দ্বিতীয় সমস্যা এড়ায়: বারবার চেষ্টা অ্যাকাউন্ট লকআউট ঘটাতে পারে, যা পরে মূল ধাপটিকে নতুন ব্যর্থতার আড়ালে ঢেকে দেয়। পদ্ধতিটি যদি ডিরেক্টরির বিরুদ্ধে EAP-MSCHAPv2 হয়, তবে ব্যর্থতা VPN-এর নয়, ডিরেক্টরির হতে পারে।

পরিচয়ের যাচাই বন্ধ করে পরিচয়ের সমস্যা পরীক্ষা করবেন না। এটি নির্ণয়যোগ্য ব্যর্থতাকে অ-নির্ণয়যোগ্য করে তোলে এবং সংযোগকে আগের চেয়ে দুর্বল রেখে যায়।

যাচাই 4: সফল লগইনের পরে কী ঘটে

IKE_AUTH সম্পন্ন হলে CHILD_SA আলোচনা ঠিক করে কোন ট্রাফিক সিলেক্টর বসানো হবে, আর এখানেই একটি সংযোগ সফল হয়ে তবুও কিছু না পাঠাতে পারে।

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

যাচাই 5: সহায়তা দলকে কী দিতে হবে

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

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