IKEv1-এর হাইব্রিড প্রমাণীকরণ IKEv2-এর ব্যবহারকারী প্রমাণীকরণে কীভাবে রূপান্তরিত হয়
হাইব্রিড মোড গেটওয়ের প্রমাণ ব্যবহারকারীর প্রমাণ থেকে আলাদা রাখত। IKEv2-তে যাওয়ায় এই পৃথকীকরণ থাকে, তবে বিনিময়, EAP পদ্ধতি ও সার্টিফিকেটের যাচাই বদলে যায়।
প্রথমে সার্ভার সার্টিফিকেট এবং পরে ব্যবহারকারীর নাম চায় এমন প্রতিটি পুরোনো VPN প্রোফাইল একই বিনিময়ে প্রমাণীকরণের দুটি ঘটনা বহন করে, এবং এই আকৃতি তাকে যে প্রোটোকল এনেছিল তার চেয়ে বেশি টিকে থাকে। IKEv1-এর হাইব্রিড মোড ঠিক এই জন্যই তৈরি হয়েছিল: গেটওয়ে নিজেকে পাবলিক কী দিয়ে প্রমাণ করে আর ব্যবহারকারী পরে XAuth-এর মাধ্যমে নিজেকে প্রমাণ করে। IKEv2 একই দুই ধাপের ভাবনা অন্য যন্ত্রকৌশলে প্রকাশ করে, এবং এই পার্থক্যগুলোতেই মাইগ্রেশন ব্যর্থ হয়। কোনো সংস্করণ সংখ্যা একটিকে অন্যটিতে বদলায় না, এবং পুরোনো অপশনের নাম নতুন প্রোফাইলে কপি করলে এমন ক্লায়েন্ট পাওয়া যায় যা দরকষাকষি করে আর তারপর কিছুই প্রমাণীকরণ করে না।
হাইব্রিড মোড IKEv1-এর ভিতরে কী করত
হাইব্রিড প্রোফাইলে উত্তরদাতা পক্ষ প্রথম ধাপের বিনিময় নিজের সার্টিফিকেট দিয়ে স্বাক্ষর করে, অন্যদিকে আরম্ভকারী ইচ্ছাকৃতভাবে কোনো সার্টিফিকেট দেখায় না। তাই পরিচয়ের প্রমাণ অসমমিত, এবং এটাই গেটওয়েকে তার বিদ্যমান PKI রাখতে এবং ব্যবহারকারীদের নিজেদের ডিরেক্টরি পাসওয়ার্ড রাখতে দিয়েছিল। প্রথম ধাপ শেষ হলে XAuth অনুরোধ ও উত্তর হিসেবে চলে যা এখন এনক্রিপ্ট করা ISAKMP চ্যানেলের ভিতরে ব্যবহারকারীর নাম ও পাসওয়ার্ডের বৈশিষ্ট্য বহন করে।
খেয়াল করুন বিশ্বাস কোথায় পৌঁছায়। সার্টিফিকেট জানায় ক্লায়েন্ট কোন গেটওয়ে পর্যন্ত পৌঁছেছে; XAuth জানায় কোন ব্যবহারকারী প্রবেশ চায়। কোনোটি অন্যটির জায়গা নেয় না, এবং যেকোনো সার্ভার সার্টিফিকেট গ্রহণ করতে সেট করা ক্লায়েন্ট চুপচাপ প্রথম উত্তর ফেলে দিয়েছে। হাইব্রিড লেবেলটি আগে থেকে শেয়ার করা কী সহ আক্রমণাত্মক মোড ও XAuth-এর জন্যও ব্যবহৃত হয়, যা একই ব্যবহারকারী অভিজ্ঞতার ভিন্ন ব্যবস্থা, তাই নাম নয় প্রোফাইল পড়ুন। দুই রূপই এমন খসড়া থেকে আসে যা কখনো মানক হয়নি, আর তাই দুই নির্মাতা হাইব্রিড মোড প্রয়োগ করতে পারেন এবং কারও সঙ্গে আন্তঃপরিচালনা করতে পারেন না।
IKEv2 কীভাবে সেই দুটি প্রমাণেই পৌঁছায়
IKEv2 কাজটিকে IKE_SA_INIT ও IKE_AUTH-এর মধ্যে ভাগ করে। প্রথম বিনিময় কোনো পরিচয় ছাড়াই প্রস্তাব ও কী-তে সম্মত হয়; দ্বিতীয়টি IDi, IDr ও AUTH পেলোড বহন করে। EAP-এর অধীনে আরম্ভকারীর প্রথম AUTH পেলোড খালি যায়, উত্তরদাতা প্রথমে নিজের সার্টিফিকেট ও স্বাক্ষর দিয়ে প্রমাণিত হয়, তারপর EAP আলাপ IKE_AUTH বার্তার ভিতরে চলে।
এটিকে নিরাপদ করে যে যন্ত্রকৌশল তা হলো কী উপাদান। সফল EAP পদ্ধতি একটি সেশন কী রপ্তানি করে, এবং আরম্ভকারীর শেষ AUTH পেলোড তা থেকে গণনা হয়, তাই ব্যবহারকারীর প্রমাণ ও টানেলের কী পরস্পর বাঁধা থাকে। XAuth-এর এমন সমতুল্য নেই: তার বৈশিষ্ট্য প্রথম ধাপের পরে আসে এবং কী-তে কিছু যোগ করে না। এই ফাঁকটাই IKEv2 কাঠামো ভরাট করতে তৈরি হয়েছিল, আর তাই কাজ করা IKEv2 লগইন কিছু চাওয়ার আগে সার্ভার সার্টিফিকেট যাচাই করে।
এই ক্রম একটি উপকারী রোগনির্ণয়ও। ক্লায়েন্ট আপনাকে সার্টিফিকেট দেখানোর আগেই যদি প্রমাণপত্রের অভিযোগ করে, তবে সে IKEv2 EAP বিনিময় করছেই না।
তিনটি পরিচয় আলাদা রাখুন
মাইগ্রেশন খারাপ হয় যখন তিনটি পরিচয় একই ক্ষেত্রে মিলে যায়। গেটওয়ের পরিচয় আছে যা ক্লায়েন্ট যাচাই করে, সাধারণত সার্টিফিকেটের subject বা SAN-এ DNS নাম। EAP-তে উপস্থাপিত ব্যবহারকারীর পরিচয় আছে, হতে পারে ডোমেইন লগইন, ঠিকানা বা স্পষ্ট EAP পরিচয় স্ট্রিং। আর আছে সেই অনুমোদন উৎস যা ওই ব্যবহারকারীকে নেটওয়ার্ক ও পথে ম্যাপ করে।
strongSwan-এর swanctl সিনট্যাক্স পৃথকীকরণ দৃশ্যমান করে: সংযোগ গেটওয়ের জন্য remote { auth = pubkey } এবং ব্যবহারকারীর জন্য local { auth = eap-mschapv2 } সেট করে, আর EAP পরিচয় আলাদা বহন করা হয়।
যখন নতুন প্রোফাইলে ব্যবহারকারীর পরিচয় পুরোনো XAuth বৈশিষ্ট্য থেকে আলাদা, যেমন ছোট নামের বদলে UPN, প্রমাণীকরণ সার্ভার অজানা ব্যবহারকারী দেখে এবং ব্যর্থতা ভুল পাসওয়ার্ডের মতো লাগে। প্রমাণপত্র যাচাই করার আগে পরিচয় স্ট্রিং যাচাই করুন।
অপশনগুলোর মানচিত্র করুন তারপর ফাঁদের প্রত্যাশা করুন
মানচিত্র ছোট এবং প্রতিটি সারিতে একটি ফাঁদ আছে যা কেবল প্রমাণীকরণের সময় দেখা যায়।
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ওই সারিগুলোর কোনোটিই কেবল নাম বদল নয়। কনফিগারেশন পেলোড ঠিকানা ও রিজলভার টাইপ করা বৈশিষ্ট্য তালিকার মাধ্যমে পৌঁছে দেয়, অন্যদিকে XAuth-এর বৈশিষ্ট্য ক্ষেত্র তার নিজস্ব আবিষ্কার ছিল; তাদের বিনিময়যোগ্য মনে করাই সেই পথ যাতে প্রোফাইল এমন সেটিং চায় যা গেটওয়ে কখনো পাঠাবে না।
ট্রাফিক নির্বাচকরা নিজেদের সতর্কবার্তার যোগ্য। IKEv1 আকর্ষণীয় ট্রাফিক quick mode বিনিময়ের সঙ্গে বাঁধা প্রক্সি আইডি দিয়ে প্রকাশ করত, অন্যদিকে IKEv2 IKE_AUTH চলাকালে নির্বাচকদের নিয়ে দরকষাকষি করে এবং উত্তরদাতা তাদের সংকীর্ণ করতে পারে। অমিল হলে child SA ছাড়া প্রতিষ্ঠিত IKE SA তৈরি হয়, যা কিছু ক্লায়েন্ট আনন্দে সংযুক্ত দেখায়।
পুরোনো সংযোগকে সীমা হিসেবে দেখুন
RFC 9395 IKEv1-কে অপ্রচলিত ঘোষণা করে, তাই পুরোনো হাইব্রিড সংযোগ তারিখযুক্ত সামঞ্জস্যের সীমা, ভিত্তি নয়। পরিবর্তনের সময় দুটি প্রোফাইল পাশাপাশি চালান, কারণ গুরুত্বপূর্ণ পরীক্ষা এই নয় যে নতুন প্রোফাইল ওঠে কি না, বরং এই যে একই ব্যবহারকারী একই ডিভাইসে একই সম্পদে পৌঁছায় কি না।
সার্টিফিকেট যাচাই শুরু থেকে শেষ পর্যন্ত কঠোর রাখুন। ক্লায়েন্ট নিজের সার্টিফিকেট দেখানো বন্ধ করলেই হ্যান্ডশেক শেষ হওয়া পর্যন্ত সার্ভার যাচাই শিথিল করার প্রলোভন আসে, আর তা বাকি একমাত্র প্রমাণকে সবুজ চিহ্ন দিয়ে বদলে দেয়।
পুরোনো প্রোফাইল অবসরে পাঠানোর আগে চারটি কথা লিখুন: EAP পদ্ধতি, পরিচয় স্ট্রিং, অনুমোদন উৎস এবং যে তারিখে সহায়তা শেষ হয়।