مسألة
يظهر نفق VTI (واجهة النفق الظاهرية) الذي تم تكوينه لتأمين الوصول على موجه CAT8500 IPsec SA كما هو محدد عند التحقق من show crypto ipSA، ولكن IKEv2 SA يظل في حالة التفاوض عند عرضه مع show crypto ikev2 sa. يكون بروتوكول خط واجهة النفق معطلا، ويعرض جانب الوصول الآمن الاتصال على أنه غير متصل، مما يمنع النفق من الإنشاء بشكل صحيح.
البيئة
- مجموعة المنتج: الطراز CAT8500
- إصدار البرامج: 17٫15٫4 درجة مئوية
- التقنية: أنفاق شبكة الوصول الآمن (IPsec، من موقع إلى موقع)
- نوع النفق: VTI (واجهة النفق الظاهرية)
- إصدار IKE: IKEv2
قرار
وفقا لمعلمات IPsec المدعومة -
القيم الموصى بها هي 19،20 لمجموعة DH.
مقترح crypto ikev2 csse-G256
تشفير aes-gcm-256
prf sha256
مجموعة 19 21. <<<<<<<<<<<<<<<<<<<<< وهذا يحتاج إلى تغيير إلى 19،20
لوحة المفاتيح -
crypto ikev2 keyring csse_useast
peer csse_virginia1
address x.x.x.x <<<<<<<<<<<< Secure Access DC
<remove> محلي مفتاح مشترك مسبقا
مفتاح مشترك مسبقا بعيد <remove>
!
ملف التعريف - محلي معرف تطابق مفقود والذي سيكون TunnelID من واجهة مستخدم CSA عند إنشاء مجموعة نفق شبكة.
crypto ikev2 profile csse_virginia1
مطابقة الهوية عن بعد عنوان x.x.x.255.255.255.255
مصادقة المشاركة المسبقة عن بعد
مشاركة مسبقة محلية للمصادقة
csse_useast المحلي ل KeyRing
!
ما إن يغير أنت ال DH مجموعة، ال يضيف مطابقة محلي هوية إصدار ثابت.
السبب
يكون السبب الأساسي لهذه المشكلة عادة مفقود أو تكوين هوية محلية غير صحيح في ملف تعريف IKEv2. يتطلب الوصول الآمن معلمات هوية محددة لإنشاء تفاوض IKEv2 بشكل صحيح. بالإضافة إلى ذلك، يمكن باستخدام مجموعات Diffie-Hellman غير المدعومة (مجموعات أخرى بخلاف 19 و 20) منع تفاوض IKEv2 بنجاح مع الوصول الآمن.
المحتوى ذي الصلة
التعليقات