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 دلچسپ ٹریفک کو کوئیک موڈ تبادلے سے بندھے پراکسی شناختوں سے بیان کرتا تھا، جبکہ IKEv2 منتخب کنندگان پر IKE_AUTH کے دوران گفت و شنید کرتا ہے اور جواب دینے والا اُنہیں تنگ کر سکتا ہے۔ عدم مطابقت ایک قائم شدہ IKE SA بغیر child SA پیدا کرتی ہے، جسے کچھ کلائنٹ خوشی سے منسلک دکھاتے ہیں۔
پرانے کنکشن کو ایک حد سمجھیں
RFC 9395 نے IKEv1 کو متروک قرار دیا ہے، اس لیے پرانا ہائبرڈ کنکشن تاریخ والی مطابقت کی حد ہے، بنیاد نہیں۔ تبدیلی کے دوران دونوں پروفائل ساتھ ساتھ چلائیں، کیونکہ اہم امتحان یہ نہیں کہ نیا پروفائل اٹھتا ہے یا نہیں، بلکہ یہ کہ وہی صارف اسی ڈیوائس پر انہی وسائل تک پہنچتا ہے۔
سرٹیفکیٹ کی توثیق ہر وقت سخت رکھیں۔ جیسے ہی کلائنٹ اپنا سرٹیفکیٹ پیش کرنا چھوڑ دے، یہ لالچ ہوتا ہے کہ سرور کی جانچ نرم کر دی جائے تاکہ مصافحہ مکمل ہو، اور یہ واحد باقی ثبوت کو سبز آئیکن سے بدل دیتا ہے۔
پرانے پروفائل کو ریٹائر کرنے سے پہلے چار چیزیں لکھیں: EAP طریقہ، شناختی تار، اجازت کا ماخذ اور وہ تاریخ جب معاونت ختم ہوتی ہے۔