IKEv2 সার্ভার ঠিকানা বনাম পরিচয়: ক্লায়েন্ট আসলে কি পরীক্ষা করে

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

সেগুলিকে এই ক্রমে পরীক্ষা করুন এবং প্রথম অমিলে থামুন, কারণ পরবর্তী চেকগুলি অনুমান করে যে আগেরগুলি পাস হয়েছে৷।

প্রথমত, কোন মানটি ঠিকানা

সংযোগ ঠিকানা যা ক্লায়েন্ট ডায়াল করে: একটি আইপি, একটি DNS নাম যা একটিতে সমাধান করে, বা একটি লোড-ভারসাম্যযুক্ত ফ্রন্ট এন্ড। এটি পরিবহন তথ্য এবং এর বেশি কিছু নয়। পরিচয়টি IKEv2 আইডি পেলোডে রাইড করে এবং তারপরে পিয়ার সার্টিফিকেটের সাথে মিলে যায়। ঠিকানা বাক্সে একটি DNS নাম প্রত্যাশিত পরিচয় হয়ে ওঠে না, এবং একটি কাঁচা আইপি পরিচয় হয়ে ওঠে না শুধুমাত্র কারণ এটির সাথে সংযুক্ত সকেট।

strongSwan পদে, ঠিকানা হল right বা left, এবং প্রত্যাশিত পরিচয় হল rightid বা leftid, এবং এটিই IKEv2 কনফিগারেশন ডকুমেন্টেশন বর্ণনা করে। আপনি যদি ঠিকানাটি সম্পাদনা করে থাকেন তবে আপনি জোড়ার অর্ধেক কনফিগার করেছেন।

দ্বিতীয়ত, সার্টিফিকেট কি প্রমাণ করতে পারে

পরিচয়ের একটি ধরন রয়েছে এবং শংসাপত্রে একটি মিলিত নাম বহন করতে হবে। একটি DNS পরিচয়টি বিষয়ের বিকল্প নাম এক্সটেনশনে একটি dNSName এন্ট্রি দ্বারা সন্তুষ্ট হয়; একটি আইপি পরিচয়ের জন্য একটি iPAddress এন্ট্রি প্রয়োজন। vpn.example.com এর জন্য জারি করা একটি শংসাপত্র আক্ষরিক ঠিকানা 203.0.113.10 সম্পর্কে কিছুই প্রমাণ করে না, এবং সেই ঠিকানার জন্য জারি করা একটি নাম সম্পর্কে কিছুই প্রমাণ করে না। একই কী এবং CA পুনরায় ব্যবহার করা হলেও একটি ভিন্ন নামের জন্য পুনরায় ইস্যু করা একটি ড্রপ-ইন প্রতিস্থাপন নয়।

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

তৃতীয়, প্রতিটি ক্লায়েন্ট কিভাবে প্রত্যাশার কথা বলে

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

strongSwan-এ প্রত্যাশাটি স্পষ্ট: সার্ভারটি আসলে যে পরিচয়টি উপস্থাপন করে তার সাথে rightid সেট করুন, যা ডান থেকে ভিন্ন হতে পারে। এটিকে %any তে সেট করা হলে পিয়ার যা কিছু অফার করে তা গ্রহণ করে এবং ঠিক যে চেকটি আপনি রাখার চেষ্টা করছেন তা সরিয়ে দেয়।

চতুর্থ, পিয়ার আইডেন্টিটি থেকে আলাদা ইউজার লগইন

EAP প্রমাণীকরণ এবং সার্ভার পরিচয় বিভিন্ন প্রশ্নের উত্তর দেয়। একটি EAP পরিচয় যেমন [email protected] বলে যে ব্যবহারকারী কে, ক্লায়েন্ট সিদ্ধান্ত নেওয়ার পরে যে সার্ভারটি সঠিক। সেই পাসওয়ার্ডটি ঘোরানো একটি সহকর্মী পরিচয়ের অমিলকে ঠিক করতে পারে না, কারণ সংযোগটি কখনই ব্যবহারকারী-লগইন পর্যায়ে পৌঁছায় না।

একটি স্যানিটাইজড রিপোর্টে উভয়ের নাম দেওয়া উচিত: ক্লায়েন্টের প্রত্যাশিত পরিচয়, সার্ভার যে পরিচয় উপস্থাপন করেছে এবং শংসাপত্রের SAN এন্ট্রি।

পঞ্চম, একটি যাচাইকৃত চ্যানেলের মাধ্যমে এটি পরিবর্তন করুন

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

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