كيف تنتقل المصادقة الهجينة في IKEv1 إلى مصادقة المستخدمين في IKEv2
كان الوضع الهجين يفصل إثبات البوابة عن إثبات المستخدم. الانتقال إلى IKEv2 يحافظ على هذا الفصل لكنه يغيّر التبادل وطريقة EAP وفحوص الشهادة.
كل ملف تعريف VPN قديم يطلب شهادة خادم ثم اسم مستخدم يحمل حدثي مصادقة داخل تبادل واحد، وهذا الشكل يعيش أطول من البروتوكول الذي أدخله. بُني الوضع الهجين في IKEv1 لهذا بالضبط: تُثبت البوابة نفسها بمفتاح عام، ويثبت المستخدم نفسه لاحقا عبر XAuth. ويعبّر IKEv2 عن الفكرة ذاتها بخطوتين بآلية مختلفة، وفي تلك الفروق تفشل عمليات الانتقال. لا يحوّل أي رقم إصدار أحدهما إلى الآخر، ونسخ أسماء الخيارات القديمة إلى ملف تعريف جديد ينتج عميلا يتفاوض ثم لا يصادق على شيء.
ما فعله الوضع الهجين داخل IKEv1
في ملف تعريف هجين يوقّع الطرف المستجيب تبادل المرحلة الأولى بشهادته، بينما لا يقدّم الطرف البادئ أي شهادة عن قصد. لذا يكون إثبات الهوية غير متماثل، وهذا ما سمح للبوابة بالاحتفاظ ببنيتها الحالية للمفاتيح العامة وللمستخدمين بكلمات مرور الدليل. وعندما تنتهي المرحلة الأولى يعمل XAuth كطلب ورد يحملان سمتي اسم المستخدم وكلمة المرور داخل قناة ISAKMP المشفرة الآن.
لاحظوا أين تستقر الثقة. تجيب الشهادة عن البوابة التي وصل إليها العميل; ويجيب XAuth عن المستخدم الذي يريد الوصول. لا يستبدل أحدهما الآخر، والعميل المضبوط على قبول أي شهادة خادم يكون قد ألقى الرد الأول بصمت. ويُستخدم وسم هجين أيضا للوضع العدواني بمفتاح مشترك مسبقا مع XAuth، وهو ترتيب مختلف بالتجربة نفسها للمستخدم، فاقرأوا الملف لا الاسم. ويعود كلا البديلين إلى مسوّدات لم تصبح معايير قط، ولهذا يمكن لمصنّعين أن ينفّذا الوضع الهجين ولا يتوافرا مع أي منهما.
كيف يصل IKEv2 إلى الإثباتين نفسيهما
يقسّم IKEv2 العمل بين IKE_SA_INIT و IKE_AUTH. يتفق التبادل الأول على المقترحات والمفاتيح بلا أي هويات، ويحمل الثاني IDi و IDr وحمولات AUTH. وفي ظل EAP تخرج أول حمولة AUTH من البادئ فارغة، ويصادق المستجيب أولا بشهادته وتوقيعه، ثم يدور حديث EAP داخل رسائل IKE_AUTH.
الآلية التي تجعل هذا آمنا هي مادة المفتاح. تُصدّر طريقة EAP الناجحة مفتاح جلسة، وتُحسب حمولة AUTH الأخيرة للبادئ منه، فيترابط إثبات المستخدم ومفاتيح النفق. ولا نظير لذلك في XAuth: فسماته تصل بعد المرحلة الأولى ولا تضيف شيئا إلى المفاتيح. وهذه الفجوة تحديدا صُمم إطار IKEv2 لسدها، ولهذا يتحقق تسجيل دخول IKEv2 العامل من شهادة الخادم قبل أن يطلب أي شيء.
هذا الترتيب أداة تشخيص مفيدة أيضا. عندما يشتكي عميل من بيانات الاعتماد قبل أن يريكم شهادة، فهو لا يجري تبادل EAP في IKEv2 على الإطلاق.
أبقوا ثلاث هويات منفصلة
يسوء الانتقال عندما تنهار ثلاث هويات في حقل واحد. هناك هوية البوابة التي يتحقق منها العميل، وعادة اسم DNS في subject الشهادة أو في SAN. وهناك هوية المستخدم المقدَّمة في EAP، وقد تكون تسجيل دخول نطاق أو عنوانا أو سلسلة هوية EAP صريحة. وهناك مصدر التخويل الذي يربط ذلك المستخدم بالشبكات والمسارات.
صيغة swanctl في strongSwan تجعل الفصل مرئيا: يضبط الاتصال 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، وسلسلة الهوية، ومصدر التخويل، وتاريخ انتهاء الدعم.