IKEv2 সার্টিফিকেট ও SAN: পরিচয় যাচাই কেন ব্যর্থ হয়

আপনার সার্টিফিকেট বিশ্বস্ত CA পর্যন্ত চেইন করে, তারিখগুলো ঠিক আছে, তবুও পিয়ার পরিচয় ত্রুটি নিয়ে ফেজ 1 সম্পূর্ণ করতে অস্বীকার করে। পৌঁছানো যায় এবং বৈধ স্বাক্ষর—এই দুটোই IKEv2 ক্লায়েন্ট যা যাচাই করে তার অর্ধেক। বাকি অর্ধেক হলো এটি যে পরিচয় প্রত্যাশা করে তা সার্টিফিকেটের সঠিক ক্ষেত্রে আছে কি না, এবং সেই প্রত্যাশা প্রোফাইল নির্ধারণ করে, সার্টিফিকেটের ফাইলের নাম নয়।

লক্ষণ সবসময় একই রকম

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

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

শুধু মান নয়, শনাক্তকারীর ধরন মেলান

dNSName SAN আর iPAddress SAN ভিন্ন ক্ষেত্র, ভিন্ন মেলানোর নিয়ম, তাই 203.0.113.10 কে DNS স্ট্রিং হিসেবে বহনকারী সার্টিফিকেট IP পরিচয় প্রত্যাশী ক্লায়েন্টকে সন্তুষ্ট করে না। আধুনিক যাচাইকারীরা সাধারণ নাম বেশিরভাগ ক্ষেত্রে উপেক্ষা করে, তাই সার্টিফিকেটের বিবরণে থাকা বন্ধুত্বপূর্ণ লেবেল কী মিলবে সে বিষয়ে কিছু প্রমাণ করে না। সমস্যা সমাধানের সময় হোস্টনেম ঠিকানা দিয়ে প্রতিস্থাপিত হলে, যাচাই না করা পর্যন্ত ধরে নিন প্রত্যাশিত পরিচয়ও তার সঙ্গে সরে গেছে। প্রোফাইলের স্ট্রিং ও SAN-এর স্ট্রিং অক্ষরে অক্ষরে তুলনা করুন, কারণ শেষে একটি বিন্দু বা একটি অতিরিক্ত স্পেসই যথেষ্ট।

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

প্রতিটি ক্লায়েন্ট প্রত্যাশাটি কোথায় রাখে খুঁজুন

strongSwan-এ সার্টিফিকেটের সঙ্গে তুলনা করা মান আসে পিয়ার পরিচয় সেটিং থেকে: ক্লাসিক কনফিগারেশনে rightid, বা swanctl-এ রিমোট সংযোগ সেকশনের id। Apple IKEv2 আন্তঃকার্যক্ষমতা সম্পর্কিত ডকুমেন্টেশন এখানে কাজে লাগে কারণ এটি প্রোফাইল-চালিত ক্লায়েন্ট যে পরিচয় রীতিনীতি ব্যবহার করে তা স্পষ্ট করে, এবং সেই রীতিনীতিই নেটওয়ার্কে এলোমেলো দেখানো এক শ্রেণির অমিল ব্যাখ্যা করে।

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

সচেতনভাবে প্রোফাইল বা সার্টিফিকেট ঠিক করুন

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

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

প্রতিটি ক্লায়েন্ট প্ল্যাটফর্মের জন্য প্রত্যাশিত পরিচয় নথিভুক্ত করুন, কারণ এক ক্লায়েন্ট স্বয়ংক্রিয়ভাবে যে মান বের করে, অন্য ক্লায়েন্টে তা স্পষ্টভাবে লেখার দরকার হতে পারে।

নবায়ন অনুরোধে চারটি তথ্য দিন

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