شهادة البوابة سليمة: لماذا يفشل تسجيل الدخول IKEv2 PEAP رغم ذلك

شهادة بوابة VPN لديك سارية، وسلسلة الثقة تتحقق، ومع ذلك يرفض عميل IKEv2 تسجيل الدخول برسالة عن فترة صلاحية شهادة. الغريزة الأولى أن تعيد إصدار شهادة البوابة أو تغيّر طريقة EAP، وكلاهما خطأ في الغالب. تحمل محاولة تسجيل الدخول هويتين منفصلتين للخادم: شهادة البوابة التي يستخدمها IKE، والشهادة التي يقدّمها أي طرف ينهي PEAP. إحداهما سليمة، والأخرى هي سبب توقّف العميل.

هويتان، ومحاولة دخول واحدة

الشهادة الموجودة في ملف تعريف VPN تنتمي إلى تبادل IKE: فهي تثبت أن البوابة هي الطرف الذي يسمّيه ملف التعريف، ضمن سياسة IKE المهيّأة. الشهادة التي تفشل هنا تنتمي إلى محادثة أخرى، أي جلسة TLS التي يفتحها PEAP مع أي طرف يصادق المستخدم، وهو غالبًا خادم RADIUS مثل NPS وليس البوابة نفسها. هناك تحقّق ثالث، هو بيانات اعتماد المستخدم، يحدث داخل تلك الجلسة. كلمة مرور صحيحة لا تصلح شهادة خادم منتهية، وشهادة بوابة صحيحة لا يمكنها أن تشهد لطرف PEAP.

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

اقرأ سطر السجل مقابل المرحلة

ابحث عن الرسالة التي تذكر السبب والتواريخ. شكوى بشأن فترة الصلاحية تقترن بخطأ في الموضوع تعني أن الخادم رفض الشهادة التي قُدّمت له، لا أن المستخدم رفض تسجيل الدخول. ثم حدّد المرحلة: يُظهر سجل charon في strongSwan العبارة IKE_SA .* established قبل أن يبدأ تبادل EAP، لذا فإن خطأ شهادة بعد ذلك السطر ينتمي إلى هوية EAP، بينما يشير خطأ قبله إلى البوابة. نص المرحلة في لوحة اتصال عميل Windows يقول الشيء نفسه.

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

حدّد الطرف الذي ينهي PEAP

في تصميم بوابة مع RADIUS، تمرّر البوابة EAP ولا تنهيه. تسلّم إضافة eap-radius في strongSwan التبادل إلى خادم RADIUS، وهو مالك جلسة TLS الخاصة بـ PEAP وشهادتها. اربط محاولة فاشلة واحدة عبر السجلين وحدّد أي عملية اختارت شهادة لتلك الجلسة فعلًا.

في NPS يجب أن تكون الشهادة في مخزن الكمبيوتر المحلي، وأن تحمل غرض مصادقة الخادم، وأن تطابق الاسم الذي يتوقعه العملاء، وأن تكون قابلة للقراءة من حساب الخدمة. تسرد متطلبات شهادات Microsoft لـ NPS تلك الشروط. لخوادم EAP الأخرى قواعد اختيار خاصة بها، فلا تنقل تفاصيل NPS إلى نشر FreeRADIUS ولا العكس. القاعدة التي تصمد في الحالتين هي أن الطرف الذي ينهي PEAP يملك الشهادة التي أنت على وشك تغييرها.

استبدل الشهادة حيث يُنهي EAP

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

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

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

ما يجب ألّا تفعله

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

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