EAP أم شهادات العميل؟ حسم مصادقة IKEv2

يمكن لبوابتك أن تثبت هويتها بشهادة بينما تثبت هويتك عبر EAP، وهذا المزيج شائع لا متناقض. يجيب الآليتان عن سؤالين مختلفين: هل هذه النقطة الطرفية هي التي أتوقعها، وهل هذا المستخدم أو هذا الجهاز مسموح له. ورؤية EAP في ملف تعريف لا تعطّل التحقق من الخادم. وقراءة ملف التعريف كإعداد واحد هي ما يدفع الناس إلى إعادة تعيين الاعتماد الخطأ.

حدِّد أي مطالبة فشلت قبل أن تمس أيًا من الكائنين. مرحلة الفشل تخبرك، إذا قرأتها بالترتيب.

اعتمدان ومطالبتان

شهادة الخادم تربط اسمًا بمفتاح، ويتحقق العميل من هذا الربط مقابل مخزن ثقته. وشهادة العميل تربط هوية بمفتاح، وتتحقق البوابة من أن الشهادة المقدَّمة تتسلسل إلى شيء تثق به. ويحمل EAP تبادل مصادقة يعتمد محتواه على الطريقة المختارة. هذه ثلاثة هياكل لها أعمار مختلفة ومالكون مختلفون وأنماط فشل مختلفة.

عبارة المرور التي تفتح مفتاحًا خاصًا ليست كلمة مرور حساب، حتى عندما يظهر المطلبان خلال ثوانٍ من بعضهما. أحدهما محلي في مخزن مفاتيح الجهاز، والآخر يتحقق منه خادم مصادقة خلف البوابة.

EAP وعاء لا طريقة

EAP إطار عمل: تتفاوض البوابة والعميل على طريقة، والطريقة تحدد ما إذا كانت كلمة مرور أو رمزًا أو تبادلًا داخليًا منفقيًا أو شهادة هي المعنية، كما توضح وثائق strongSwan الخاصة بـ IKEv2 ذلك. لهذا لا يشبه EAP-TLS إطلاقًا EAP-MSCHAPv2 من جهة العميل، مع أن كليهما يظهر باسم EAP في القائمة. وملف التعريف الذي يذكر EAP فقط لم يخبرك بما سيُطلب من المستخدم.

اقرأ الطريقة والخادم الخلفي معًا. الخادم الخلفي يحدد صيغة الحساب وسلوك القفل وما تغيّره إعادة تعيين كلمة المرور فعليًا، ولا شيء من ذلك ظاهر في ملف تعريف العميل.

النشر المختلط أمر طبيعي

شهادة الخادم مع EAP للمستخدم هي الشكل الذي تنشره معظم بوابات الوصول عن بُعد، لأنها تمنح العميل نقطة طرفية قابلة للتحقق وتمنح المشغّل هوية لكل مستخدم في مخزن حسابات مركزي. وتوجد أيضًا عمليات نشر بشهادات العميل، عادةً حيث تكون هوية الجهاز أهم من كلمة المرور. كلاهما مشروع، والخطأ هو افتراض أن ما رأيته الأسبوع الماضي هو ما أمامك.

اطلب من المشغّل الطريقة الموثقة وصيغة الحساب بدلًا من استنتاجها من أسماء الحقول في العميل.

الحسم من مرحلة الفشل

رتّب الملاحظات. خطأ ثقة قبل أي مطالبة مستخدم هو مشكلة شهادة خادم ولن تصلحها أي كلمة مرور. المطالبة التي يتبعها رفض هي مشكلة مصادقة مستخدم، مع اعتبار طريقة EAP والخادم الخلفي مشتبهًا بهما. أما المصادقة الناجحة التي يتبعها فشل في child-SA فليست أيًا منهما.

ثمة تمييزان آخران مهمان. العميل الذي يرفض شهادة الخادم يبلّغ عادةً عن عدم تطابق اسم أو جهة إصدار غير معروفة، وهي مسألة مخزن ثقة. والبوابة التي ترفض المستخدم تسجّل غالبًا طريقة EAP وفئة سبب، وهي مسألة حساب أو سياسة.

تشغيل النموذجين

بالنسبة للشهادات يتمثل العمل في الإصدار والتجديد والإبطال وإزالة الأجهزة المفقودة، ويحدث وفق جدول تتحكم به. وبالنسبة لـ EAP يتمثل العمل في دورة حياة الحساب ودعم الطرق على كل منصة عميل وأي عامل ثانٍ يطلبه الخادم الخلفي. ولا أحد النموذجين أرخص نظريًا؛ فكلاهما يحمّل فريقين مختلفين. دوّن أي النموذجين يستخدمه نشرك فعلًا، لأن سكربتات الدعم تختلف أكثر من التكوين.

أبقِهما منفصلين في ملاحظاتك. انتهاء صلاحية شهادة ينتج فشلًا في تاريخ معين، وقفل الحساب ينتج فشلًا بعد تغيير كلمة المرور، وعدم تطابق الطريقة ينتج فشلًا على منصة واحدة فقط.

بعد قبول الهوية

المصادقة بوابة واحدة. أما اقتران الأمان الفرعي ومحدِّدات حركة المرور وDNS وأذونات التطبيق نفسها فهي بوابات لاحقة، وكل منها يفشل بشروطه. والهوية المقبولة التي لا تصل إلى شيء ليست مشكلة مصادقة.

سجّل الطريقة والحساب أو الشهادة المستخدمة والمرحلة التي فشلت. تلك الملاحظة تحوّل الحادثة التالية إلى بحث سريع بدلًا من تجربة.