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

في 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

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

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 هو الخيار الأفضل.

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 

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