IKEv1 مع XAuth وOTP: ما الذي يطلبه كل حقل

لا يطلب IKEv1 مع PSK وXAuth وOTP كلمة مرور واحدة معقّدة. بل يرصّ طبقات: مفتاحاً مشتركاً بين الطرفين، وتبادلاً خاصاً بالمستخدم، وعاملاً ثانياً يقرر الخادم الخلفي كيفية طلبه. ولكل طبقة مالكها ورسالة فشلها الخاصة. والخلط بينها يدفع الناس إلى إعادة كتابة رمز لمرة واحدة في حقل يخزّن سراً جماعياً.

طابق كل حقل مع الطبقة التي تطلبه قبل تثبيت عميل آخر أو إعادة تعيين بيانات اعتماد.

ثلاثة أسرار، ثلاثة مالكين

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

اكتب ثلاثة أعمدة: المالك، ومدة الصلاحية، ورسالة الفشل التي ينتجها كل منها. ذلك الجدول هو أداة التشخيص، وليست أسماء الحقول في العميل.

PSK: الطرف، لا الشخص

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

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

XAuth: تبادل المستخدم القديم

يضيف XAuth تبادلاً لمصادقة المستخدم فوق مصادقة الطرف في IKEv1، والبوابة تقرر أي خادم خلفي يتحقق منه. وبحسب ذلك الخادم، قد يقبل التبادل كلمة مرور دليل أو بيانات اعتماد RADIUS أو ردّ رمز. وكلمة XAuth تسمّي وسيلة نقل التبادل، لا نوع بيانات الاعتماد.

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

OTP: ما يطلبه الخادم الخلفي

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

استخدم الصيغة الموثّقة مع عميل يستطيع إكمال التبادل الذي تقدّمه البوابة.

أين تحدّ حدود العميل

توثّق Fortinet أن FortiClient 7.4.4 وما بعده لم يعد يدعم IKEv1 في شبكات IPsec VPN، وهذا حدّ منتج وإصدار وليس إزالة شاملة، كما يسجّل ملاحظة توافق FortiClient ذلك. والعملاء الآخرون ليسوا قابلين للتبديل أيضاً: فـ OpenConnect وopenfortivpn يتحدثان بروتوكولات بوابة محددة، لا ملفات تعريف IKEv1 اعتباطية. تحقق من إصدار IKE ووضع PSK ودعم XAuth ونموذج التفاعل في العميل المثبّت كلاً على حدة. والعميل الذي يتصل بطريقة مختلفة لم يثبت المتطلب الأصلي.

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

التشخيص دون تعطيل العامل

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

احفظ أسرار التسجيل والمفتاح المشترك في تخزين محمي وفق عملية المؤسسة. والرمز لمرة واحدة في ملف دائم هو عامل كفّ عن كونه عاملاً.