المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

مسرد إيك

تبادل حزم IKEv2

استكشاف الأخطاء وإصلاحها

تمكين تصحيح أخطاء IKE

تلميحات لبدء عملية أستكشاف أخطاء IPsec وإصلاحها

العرض 1.  لم يتم إنشاء نفق IPsec

العرض 2.  نفق "IPsec" تم تخفيضه وأعيد بناءه لوحده

عمليات إعادة إرسال DPD

العرض 3. تم تعطيل نفق IPsec ويبقى في حالة الإنزال

عدم تطابق PFS

لا تتم إعادة تشغيل نفق vEdge IPSec/IKEv2 بعد تمزيقه بسبب حدث DELETE

معلومات ذات صلة

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء أكثر المشاكل شيوعا الخاصة بأنفاق أمان بروتوكول الإنترنت (IPsec) لأجهزة الطرف الثالث التي تم تكوين الإصدار 2 من تبادل مفتاح الإنترنت (IKEv2) لها وإصلاحها. يشار إليها بشكل شائع باسم أنفاق الخدمة/النقل على وثائق Cisco SD-WAN. يشرح هذا المستند أيضا كيفية تمكين تصحيح أخطاء IKE وقراءتها وربطها بتبادل الحزم لفهم نقطة الفشل على تفاوض IPsec.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- IKEv2

- تفاوض IPsec

- تقنية SD-WAN من Cisco

المكونات المستخدمة

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

مسرد إيك

- أمان بروتوكول الإنترنت (IPsec) هي مجموعة قياسية من البروتوكولات بين نقطتي اتصال عبر شبكة IP توفر مصادقة البيانات وسلامتها وسريتها.

- Internet Key Exchange الإصدار 2 (IKEv2) هو البروتوكول المستخدم لإعداد اقتران أمان (SA) في مجموعة بروتوكولات IPsec.

- اقتران الأمان (SA) هو إنشاء سمات أمان مشتركة بين كيانين على الشبكة لدعم الاتصال الآمن. يمكن أن تتضمن حالة الوصول (SA) سمات مثل خوارزمية التشفير والوضع ومفتاح تشفير حركة المرور والمعلمات لبيانات الشبكة التي سيتم تمريرها عبر الاتصال.

- يتم إستخدام معرفات المورد (VID) لتحديد أجهزة النظير باستخدام تنفيذ المورد نفسه لدعم الميزات الخاصة بالمورد.

- Nonce: قيم عشوائية تم إنشاؤها في Exchange لإضافة العشوائية ومنع هجمات إعادة التشغيل.

- معلومات تبادل المفاتيح (KE) لعملية تبادل المفاتيح الآمنة Diffie-Hellman (DH).

- يتم إستخدام Identity Initiator/Responder (IDi/IDr) لإرسال معلومات المصادقة إلى النظير. يتم إرسال هذه المعلومات تحت حماية السر المشترك المشترك المشترك.

- يمكن اشتقاق المفتاح المشترك IPSec باستخدام DH مرة أخرى لضمان سرية إعادة التوجيه الكاملة (PFS) أو مع تحديث السر المشترك المشتق من تبادل DH الأصلي.

- تبادل مفاتيح Diffie-Hellman (DH) هو طريقة لتبادل خوارزميات التشفير بأمان عبر قناة عامة.

- محددات حركة المرور (TS) هي هويات الوكيل أو حركة مرور البيانات المتبادلة على مفاوضات IPsec للمرور عبر النفق المشفر.

تبادل حزم IKEv2

تحتوي كل حزمة من حزم IKE على معلومات الحمولة لإنشاء النفق. يشرح مسرد IKE الاختصارات المعروضة على هذه الصورة كجزء من محتوى الحمولة لتبادل الحزم.

IKEv2-Exchange

ملاحظة: من المهم التحقق من تبادل الحزمة لمفاوضات IKE فشل نفق IPsec في التحليل السريع للتكوين المتضمن لمعالجة المشكلة بشكل فعال.

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

يلزم ربط تكوين vEdge مقابل تكوين Cisco IOS® XE. كما أنه من المفيد مطابقة مفاهيم IPsec ومحتوى الحمولة لعمليات تبادل حزم IKEv2 كما هو موضح في الصورة.

ملاحظة: يقوم كل جزء من التكوين بتعديل أحد جوانب تبادل تفاوض IKE. من المهم ربط الأوامر بتفاوض بروتوكول IPsec.

استكشاف الأخطاء وإصلاحها

تمكين تصحيح أخطاء IKE

يتيح تصحيح أخطاء InEdges IKED معلومات مستوى تصحيح الأخطاء إما IKEv1 أو IKEv2.

debug iked misc high

debug iked event high

من الممكن عرض معلومات تصحيح الأخطاء الحالية ضمن vshell وتشغيل الأمر tail -f <debug path>.

vshell

tail -f /var/log/message

في CLI يمكن أيضا أن يعرض السجلات الحالية/معلومات تصحيح الأخطاء للمسار المحدد.

monitor start /var/log/messages

تلميحات لبدء عملية أستكشاف أخطاء IPsec وإصلاحها

من الممكن فصل ثلاثة سيناريوهات IPsec مختلفة. وهي نقطة مرجعية جيدة لتحديد العوارض ان يكون هنالك نهج افضل لتعرف كيف تبدأ.

1. لم يتم إنشاء نفق IPsec.

2. نفق IPsec انخفض وعاد ليؤسس لوحده. (ملتصق)

3. تم تعطيل نفق IPsec ويبقى في حالة انخفاض.

بالنسبة لنفق IPsec لا يؤسس الأعراض، يلزم تصحيح الأخطاء في الوقت الفعلي للتحقق من السلوك الحالي على تفاوض IKE.

بالنسبة لنفق IPsec الذي أنهار وإعادة تأسيسه على أعراضه الخاصة، والمعروف بشكل عام باسم Tunnel Flved وتحليل السبب الجذري (RCA) مطلوب. لا بد من معرفة الطابع الزمني عند هبوط النفق أو تخصيص وقت مقدر للنظر في تصحيح الأخطاء.

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

تعرف على النقاط قبل بدء أستكشاف الأخطاء وإصلاحها:

1. نفق IPsec (الرقم) مع المشاكل والتكوين.

2. الطابع الزمني الذي تم فيه تنزيل النفق (إذا كان ذلك ممكنا).

3. عنوان IP لنظير IPsec (وجهة النفق).

يتم حفظ جميع السجلات والتصحيح على ملفات /var/log/messages، وبالنسبة للسجلات الحالية، يتم حفظها في ملف الرسائل ولكن لهذا العرض المحدد يمكن تحديد الرفرفة بعد ساعات/أيام من المشكلة، ومن المحتمل أن تكون أخطاء التصحيح ذات الصلة على الرسائل 1،2،3..إلخ. من المهم معرفة الطابع الزمني للنظر إلى ملف الرسالة الصحيح وتحليل تصحيح الأخطاء (charon) لمفاوضات IKE الخاصة بالنفق المرتبط ب IPsec.

لا تطبع معظم تصحيح الأخطاء رقم نفق IPsec. الطريقة الأكثر شيوعا لتعريف التفاوض والحزم هي عنوان IP للنظير البعيد وعنوان IP حيث يتم توفير النفق على الحافة. تمت طباعة بعض الأمثلة على تصحيح أخطاء IKE:

Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'

Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

تظهر تصحيح أخطاء تفاوض IKE Init رقم نفق IPsec، ومع ذلك، فإن المعلومات التالية لتبادل الحزم تستخدم عناوين IP الخاصة بنفق IPsec فقط.

Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'

Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]

Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)

Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)

Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]

Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00

Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives

تكوين نفق IPsec:

interface ipsec2

ip address 192.168.1.9/30

tunnel-source      10.132.3.92

tunnel-destination 10.10.10.1

dead-peer-detection interval 30

ike

version      2

rekey        86400

cipher-suite aes256-cbc-sha1

group        14

authentication-type

pre-shared-key

pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN

!

!

!

ipsec

rekey                   3600

replay-window           512

cipher-suite            aes256-gcm

perfect-forward-secrecy group-14

!

العرض 1.  لم يتم إنشاء نفق IPsec

وبما أن المشكلة يمكن أن تكون التطبيق الأول للنفق، فإنها لم تكن في وضع التشغيل وأن تصحيح أخطاء IKE هو الخيار الأفضل.

العرض 2.  نفق "IPsec" تم تخفيضه وأعيد بناءه لوحده

وكما ذكر سابقا، يجري عادة تناول هذا العرض لمعرفة السبب الجذري لانهيار النفق. ومع معرفة تحليل السبب الجذري، في بعض الأحيان، يمنع مسؤول الشبكة حدوث المزيد من المشاكل.

تعرف على النقاط قبل بدء أستكشاف الأخطاء وإصلاحها:

1. نفق IPsec (الرقم) مع المشاكل والتكوين.

2. الطابع الزمني الذي نزل فيه النفق.

3. عنوان IPsec للنظير (وجهة النفق)

عمليات إعادة إرسال DPD

في هذا المثال، نزل النفق في 18 يونيو في 00:31:17.

Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN

Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

ملاحظة: السجلات الموجودة في أسفل نفق IPsec ليست جزءا من سجلات FTMD. لذلك لا يطبع شارون ولا IKE.

ملاحظة: لا تتم عادة طباعة السجلات ذات الصلة معا، ويكون هناك المزيد من المعلومات فيما بينها غير مرتبطة بنفس العملية.

الخطوة 1. بعد تحديد الطابع الزمني وترابط الوقت والسجلات، ابدأ مراجعة السجلات من الأسفل إلى الأعلى.

Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits

Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request

Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]

Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

يتم وصف آخر عملية تبادل حزم DPD ناجحة على أنها الطلب رقم 542.

Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]

Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]

الخطوة 2. تمتع بتجميع جميع المعلومات معا بالترتيب الصحيح:

Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]

Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes)

Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]

Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request

Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]

Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)

Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits

Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN

Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

على سبيل المثال الموضح، يتم تقليل قيمة النفق بسبب عدم تلقي vEdge01 لحزم DPD من 10.10.10.1. من المتوقع تعيين نظير IPsec على "مفقود" بعد إعادة إرسال 3 وحدات بيانات DPD، كما سيتم إغلاق النفق. هناك يتعدد سبب لهذا السلوك، عادة، ويرتبط ب ISP حيث الربط خسرت أو سقطت في المسار. إذا حدثت المشكلة مرة واحدة، فلا توجد طريقة لتعقب حركة المرور المفقودة، ومع ذلك، إذا إستمرت المشكلة، يمكن تعقب الحزمة باستخدام التقاط على vEdge، والأقران البعيد ل IPSec، و ISP.

العرض 3. تم تعطيل نفق IPsec ويبقى في حالة الإنزال

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

تعرف على النقاط قبل بدء أستكشاف الأخطاء وإصلاحها:

1. نفق IPsec (الرقم) مع المشاكل والتكوين.

2. الطابع الزمني الذي نزل فيه النفق.

3. عنوان IPsec للنظير (وجهة النفق)

عدم تطابق PFS

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

interface ipsec1

description             VWAN_VPN

ip address 192.168.0.101/30

tunnel-source-interface ge0/0

tunnel-destination      10.10.10.1

ike

version      2

rekey        28800

cipher-suite aes256-cbc-sha1

group        2

authentication-type

pre-shared-key

pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="

!

!

!

ipsec

rekey                   3600

replay-window           512

cipher-suite            aes256-cbc-sha1

perfect-forward-secrecy group-16

!

mtu                     1400

no shutdown

تم تمكين تصحيح الأخطاء وتم عرض التفاوض.

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes)

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ]

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ]

daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)

daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes)

daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ]

daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ]

daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)

daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes)

daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ]

daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found

daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA

ملاحظة: يتم تبادل حزم CREATE_CHILD_SA لكل rekey أو sa جديد. لمزيد من المراجع، انتقل إلى فهم تبادل حزم IKEv2

تظهر تصحيحات IKE نفس السلوك ويتم تكرارها باستمرار، لذلك من الممكن أخذ جزء من المعلومات وتحليلها:

CREATE_CHILD_SA يعني rekey، مع الغرض من SPIS الجديد أن يكون خلقت وتبادلت بين نقاط نهاية IPsec.

- يستقبل vEdge حزمة طلب CREATE_CHILD_SA من 10.10.10.1.

- يعالج Vedge الطلب ويتحقق من الاقتراحات (SA) المرسلة من النظير 10.10.10.1

- يقوم vEdge بمقارنة الاقتراح الذي تم إرساله بواسطة النظير مقابل مقترحاته التي تم تكوينها.

- يفشل CREATE_CHILD_SA المبادل مع "لم يتم العثور على اقتراحات مقبولة".

عند هذه النقطة، السؤال هو: لماذا هناك عدم تطابق في التكوين إذا كان النفق يعمل سابقا ولم يتم إجراء أي تغييرات؟

التحليل بعمق، يوجد حقل إضافي في الاقتراحات التي تم تكوينها والتي لا يرسلها النظير.

الاقتراحات المكونة: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

العروض التي تم تلقيها:

esp:AES_GCM_16_256/NO_EXT_SEQ،

ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ،

ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ،

ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ،

ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ،

ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

MODP_4096 هي مجموعة DH 16، والتي قامت الحواف بتكوينها لملفات PFS (السرية التامة لإعادة التوجيه) على المرحلة 2 (قسم IPsec).

PFS هو التكوين غير المتطابق الوحيد الذي يمكن إنشاء النفق فيه بنجاح أو لا وفقا لمن هو البادئ أو المستجيب في تفاوض IKE. ومع ذلك، عندما يبدأ المفتاح لا يكون قادرا على الاستمرار وهذا العرض يمكن تقديمه أو الربط به.

لا تتم إعادة تشغيل نفق vEdge IPSec/IKEv2 بعد تمزيقه بسبب حدث DELETE

راجع معرف تصحيح الأخطاء من Cisco CSCvx86427 للحصول على مزيد من المعلومات حول هذا السلوك.

بينما تستمر المشكلة، تعد تصحيح أخطاء IKE أفضل الخيارات. ومع ذلك، بالنسبة لهذا الخطأ الخاص إذا تم تمكين تصحيح الأخطاء، لا يتم عرض أي معلومات لا إلى الوحدة الطرفية ولا ملف الرسالة.

لتضييق هذه المشكلة والتحقق من إذا كان vEdge يصدم معرف تصحيح الأخطاء من Cisco CSCvx86427، يلزم العثور على اللحظة التي يتم فيها إسقاط النفق.

تعرف على النقاط قبل بدء أستكشاف الأخطاء وإصلاحها:

1. نفق IPsec (الرقم) مع المشاكل والتكوين.

2. الطابع الزمني الذي نزل فيه النفق.

3. عنوان IPsec للنظير (وجهة النفق)

بعد تحديد الطابع الزمني، وترابط الوقت والسجلات، راجع السجلات قبل وقت انخفاض النفق مباشرة.

Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217]

Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]

Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]

Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted

Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted

Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ]

Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes)

Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77

Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN

Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down

ملاحظة: هناك حزم حذف متعددة على تفاوض IPsec، والحذف ل CHILD_SA هو حذف متوقع لعملية REKEY، وتشاهد هذه المشكلة عند تلقي حزمة حذف IKE_SA نقية دون أي تفاوض IPsec معين. يؤدي هذا الحذف إلى إزالة كافة نفق IPsec/IKE.

معلومات ذات صلة

- تصحيح أخطاء مستوى البروتوكول وتبادل حزم KEv2

- تبادل مفتاح الإنترنت (IKE) - RFC 2409

- IKEv2 - RFC 7296

- شبكة LAN من موقع إلى شبكة LAN IPSec بين vEdge و Cisco IOS

- الدعم التقني والمستندات - Cisco Systems