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

المقدمة

نويت هذا وثيقة أن يقدم مهيكل يتحرى منهجية و أداة مفيد أن يساعد عينت وعزلت مجموعة يشفر نقل VPN (GETVPN) مشكلة وأن يزود حل ممكن.

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

المتطلبات

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

• Getvpn
  دليل تكوين GETVPN الرسمي
  الدليل الرسمي لتصميم GETVPN وتنفيذه
  
  
• إستخدام خادم Syslog

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

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

منهجية أستكشاف أخطاء GetVPN وإصلاحها

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

• تبادل مفتاح الإنترنت (IKE) - يستخدم بين عضو المجموعة (GM) وخادم المفاتيح (KS)، وبين مجموعات المفاتيح والنسخ (KS) للبروتوكول التعاوني (COOP) لمصادقة مستوى التحكم وحمايته.
• مجال المجموعة للتفسير (GDOI) - البروتوكول المستخدم ل KS من أجل توزيع مفاتيح المجموعة وتوفير الخدمة الأساسية مثل rekey إلى جميع GMs.
• COOP - بروتوكول مستخدم ل KSs in order to اتصلت مع بعضهم بعضا ووفرت تكرار.
• حفظ الرأس - IPsec في وضع النفق الذي يحافظ على رأس حزمة البيانات الأصلية لتوصيل حركة المرور من نهاية إلى نهاية.
• مكافحة إعادة التشغيل المستندة إلى الوقت (TBAR) - آلية كشف إعادة التشغيل المستخدمة في بيئة مفتاح مجموعة.

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

طوبولوجيا مرجعية

يتم إستخدام مخطط GETVPN والعنونة هذا في باقي مستند أستكشاف الأخطاء وإصلاحها هذا.

التكوينات المرجعية

• KS1
  
  

  crypto gdoi group G1
   identity number 3333
   server local
    rekey authenmypubkeyrsa get
    rekey transport unicast
    sa ipsec 1
     profile gdoi-p
     match address ipv4ENCPOL
    address ipv4 10.1.11.2
    redundancy
     local priority 10
     peer address ipv4 10.1.12.2

• GM1
  
  

  crypto gdoi group G1
   identity number 3333
   server address ipv4 10.1.11.2
   server address ipv4 10.1.12.2
  !
  crypto map gm_map 10 gdoi
   set group G1
  !
  interface Serial1/0
   crypto map gm_map

ملاحظة: لا يتم تضمين مواصفات KS2 و GM2 هنا للإيجاز.

مصطلحات

• KS - الخادم الرئيسي
• GM - عضو المجموعة
• البروتوكول التعاوني
• TBAR - مقاومة إعادة التشغيل المستندة إلى الوقت
• KEK - مفتاح التشفير
• TEK - مفتاح تشفير حركة مرور البيانات

إعداد مرافق التسجيل وأفضل الممارسات الأخرى

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

• تحقق من مقدار الموجه للذاكرة الحرة، وقم بتكوين تصحيح الأخطاء المخزن مؤقتا للتسجيل إلى قيمة كبيرة (10 ميجابت أو أكثر إن أمكن).
  
  
• تعطيل التسجيل إلى خوادم وحدة التحكم والمراقبة و syslog.
  
  
• قم باسترداد محتوى المخزن المؤقت للتسجيل باستخدام الأمر show log على فواصل زمنية منتظمة، كل 20 دقيقة إلى ساعة، لمنع فقدان السجل بسبب إعادة إستخدام المخزن المؤقت.
  
  
• أيا كان ما يحدث، فأدخل الأمر show tech من GMs و KSs المتأثرة، وفحص إخراج الأمر show ip route في الوضع العام وكل توجيه وإعادة توجيه ظاهري (VRF) متورط، إذا كان هناك حاجة إلى أي منهما.
  
  
• أستخدم بروتوكول وقت الشبكة (NTP) لمزامنة الساعة بين جميع الأجهزة التي تم تصحيح أخطائها. تمكين الطوابع الزمنية بالمللي ثانية (msec) لكل من رسائل تصحيح الأخطاء والسجل:
  

  service timestamps debug datetime msec
  service timestamps log datetime msec

• تأكد من أن مخرجات أمر العرض مختومة بختم الوقت.
  

  Router#terminal exec prompt timestamp

• عندما تقوم بتجميع مخرجات الأمر show لأحداث مستوى التحكم أو عدادات مستوى البيانات، قم دائما بتجميع تكرارات متعددة من نفس الإخراج.

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

مستوى التحكم يعني جميع أحداث البروتوكول التي أدت إلى إنشاء اقتران الأمان (SA) والسياسة على GM حتى تصبح جاهزة لتشفير حركة مرور مستوى البيانات وفك تشفيرها. بعض نقاط التفتيش الرئيسية في مستوى التحكم في GETVPN هي:

أفضل ممارسات تصحيح أخطاء مستوى التحكم

أفضل ممارسات أستكشاف الأخطاء وإصلاحها هذه ليست خاصة ب GETtvpn؛ بل تنطبق على أي تصحيح أخطاء لمستوى التحكم تقريبا. من المهم للغاية اتباع أفضل الممارسات هذه لضمان أكثر عمليات أستكشاف الأخطاء وإصلاحها فعالية:

• قم بإيقاف تشغيل تسجيل وحدة التحكم واستخدام المخزن المؤقت للتسجيل أو syslog لجمع تصحيح الأخطاء.
• أستخدم NTP لمزامنة ساعات الموجه على جميع الأجهزة التي تم تصحيحها.
• تمكين ختم وقت msec لتصحيح الأخطاء ورسائل السجل:
  

  service timestamp debug datetime msec
  service timestamp log datetime msec

• تأكد من أن مخرجات أمر العرض مختومة بختم زمني بحيث يمكن ربطها بمخرج تصحيح الأخطاء:
  

   terminal exec prompt timestamp

• أستخدم تصحيح الأخطاء الشرطي في بيئة المقياس إن أمكن.

أدوات أستكشاف أخطاء مستوى التحكم وإصلاحها في GetVPN

أوامر عرض GetVPN

كقاعدة عامة، هذه هي مخرجات الأمر التي يجب عليك جمعها تقريبا لكل مشاكل GETVPN.

كس

show crypto gdoi
show crypto gdoi ks coop
show crypto gdoi ks members
show crypto gdoi ks rekey
show crypto gdoi ks policy

جي إم

show crypto eli
show crypto gdoi rekey sa
show crypto gdoi
show crypto gdoi gm
show crypto gdoi gm rekey

رسائل GetVPN Syslog

يوفر GETtvpn مجموعة واسعة من رسائل syslog لأحداث البروتوكول الهامة وحالات الخطأ. يجب أن يكون syslog دائما أول مكان يظهر فيه عند إجراء أستكشاف أخطاء GETVPN وإصلاحها.

رسائل syslog المشتركة ل KS

رسائل Syslog	الشرح
coop_config_mismatch	التكوين بين خادم المفاتيح الأساسية الأساسية وخادم المفاتيح الثانوية غير متطابق.
COOP_KS_ELECTION	دخل خادم المفتاح المحلي عملية الاختيار في مجموعة.
coop_ks_reach	تم إستعادة إمكانية الوصول بين خوادم المفاتيح التعاونية التي تم تكوينها.
coop_ks_trans_to_pri	تم تحويل خادم المفتاح المحلي إلى دور أساسي من كونه ملقم ثانوي في مجموعة.
Coop_KS_Unauth	حاول خادم بعيد معتمد الاتصال بخادم المفاتيح المحلي في مجموعة، وهو ما يمكن اعتباره حدثا معاديا.
coop_ks_unreach	تم فقد إمكانية الوصول بين خوادم المفاتيح التعاونية التي تم تكوينها، مما يمكن اعتباره حدثا عدائيا.
KS_GM_REVOKED	أثناء بروتوكول إعادة المفاتيح، حاول عضو غير مصرح له الانضمام إلى مجموعة، وهو ما يمكن اعتباره حدثا عدائيا.
KS_SEND_MCAST_REKEY	إرسال مفتاح البث المتعدد.
KS_SEND_UNICAST_REKEY	إرسال مفتاح إعادة البث الأحادي.
KS_غير مصرح به	وخلال بروتوكول التسجيل في الهيئة، حاول عضو غير مأذون له الانضمام إلى مجموعة، الأمر الذي يمكن اعتباره حدثا عدائيا.
UNAUTHORIZED_IPADDR	تم إسقاط طلب التسجيل لأن الجهاز الطالب غير مخول للانضمام إلى المجموعة.

   

رسائل syslog الشائعة ل GM

رسائل Syslog	الشرح
GM_CLEAR_Register	تم تنفيذ الأمر clear crypto gdoi بواسطة عضو المجموعة المحلية.
gm_cm_attach	تم إرفاق خريطة تشفير لعضو المجموعة المحلية.
GM_CM_DETACH	تم فصل خريطة تشفير لعضو المجموعة المحلي.&
gm_re_register	ربما انتهت صلاحية IPsec SA الذي تم إنشاؤه لمجموعة واحدة أو تم مسحه. الحاجة إلى إعادة التسجيل إلى الخادم الرئيسي.
GM_RECV_REKEY	تم تلقي Rekey.
GM_REGS_COMPL	اكتمل التسجيل.
GM_REKEY_TRANS_2_MULTI	انتقل عضو المجموعة من إستخدام آلية إعادة مفتاح البث الأحادي إلى إستخدام آلية البث المتعدد.
GM_REKEY_TRANS_2_UNI	انتقل عضو المجموعة من إستخدام آلية إعادة مفتاح البث المتعدد إلى إستخدام آلية البث الأحادي.
pseudo_time_large	تلقى عضو المجموعة وقتا زائفا بقيمة مختلفة إلى حد كبير عن وقته الزائف.
Replay_Failed	فشل أحد أعضاء المجموعة أو خادم المفاتيح في إجراء التحقق من عدم إعادة التشغيل.

ملاحظة: الرسائل التي يتم إبرازها باللون الأحمر هي الرسائل الأكثر شيوعا أو أهمية التي يتم رؤيتها في بيئة GETVPN.

التشفير العام وتصحيح أخطاء GDOI

يتم تقسيم عمليات تصحيح أخطاء GetVPN:

1. أولا بواسطة الجهاز الذي تقوم باستكشاف الأخطاء وإصلاحها عليه.

   F340.06.15-2900-18#debug cry gdoi ?
     all-features  All features in GDOI
     condition     GDOI Conditional Debugging
     gm            Group Member
     ks            Key Server

2. ثانيا حسب نوع المشكلة إلى عم تستكشف فيها الأخطاء وإصلاحها.

   GM1#debug cry gdoi gm ?
     all-features    All Group Member features
     infrastructure  GM Infrastructure
     registration    GM messages related to registration
     rekey           GM messagese related to Re-Key
     replay          Anti Replay

3. ثالثا حسب مستوى تصحيح الأخطاء المطلوب تمكينه. في الإصدار 15.1(3)T والإصدارات الأحدث، تم توحيد جميع عمليات تصحيح أخطاء ميزات GDOI للحصول على مستويات تصحيح الأخطاء هذه. تم تصميم هذا للمساعدة في أستكشاف أخطاء بيئات GETVPN واسعة النطاق وإصلاحها بما يكفي من تحبب تصحيح الأخطاء. عندما تقوم بتصحيح مشاكل GETVPN، من المهم إستخدام مستوى تصحيح الأخطاء المناسب. كقاعدة عامة، ابدأ بأدنى مستوى تصحيح أخطاء، وهو مستوى الخطأ، وقم بزيادة دقة تصحيح الأخطاء عند الحاجة.

   GM1#debug cry gdoi gm all-features ?
     all-levels  All levels
     detail      Detail level
     error       Error level
     event       Event level
     packet      Packet level
     terse       Terse level

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

تصحيح الأخطاء الشرطي ل GDOI

في الإصدار 15.1(3)T من Cisco IOS^® والإصدارات الأحدث، تمت إضافة تصحيح الأخطاء المشروط ل GDOI للمساعدة في أستكشاف أخطاء GETVPN وإصلاحها في بيئة واسعة النطاق. لذلك يمكن الآن تشغيل جميع "اقتران أمان الإنترنت" وبروتوكول إدارة المفاتيح (ISAKMP) وتصحيح أخطاء GDOI باستخدام عامل تصفية شرطي استنادا إلى المجموعة أو عنوان IP النظير. لمعظم مشاكل GETtvpn، من الجيد تمكين كل من تصحيح أخطاء ISAKMP و GDOI باستخدام المرشح الشرطي المناسب، نظرا لأن تصحيح أخطاء GDOI يعرض فقط العمليات الخاصة ب GDOI. لاستخدام تصحيح الأخطاء المشروط ISAKMP و GDOI، أكمل هاتين الخطوتين البسيطتين:

1. ضبط المرشح الشرطي.
2. قم بتمكين ISAKMP و GDOI المعنيين كالمعتاد.

على سبيل المثال:

KS1# debug crypto gdoi condition peer add ipv4 10.1.20.2
% GDOI Debug Condition added.

KS1#
KS1# show crypto gdoi debug-condition 
GDOI Conditional Filters:
Peer Address 10.1.20.2
Unmatched NOT set

KS1#debug crypto gdoi ks registration all-levels 
GDOI Key Server Registration Debug level: (Packet, Detail, Event, Terse, Error)

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

آثار حدث GDOI

وأضيف ذلك في الإصدار 15.1(3)T. يوفر تتبع الأحداث تتبع خفيف الوزن ودائما لأحداث و أخطاء GDOI المهمة. هناك أيضا تتبع مسار الخروج مع تمكين traceback لظروف الاستثناء. يمكن أن توفر آثار الأحداث معلومات حول محفوظات أحداث GETVPN أكثر من مخططات النظام التقليدية.

يتم تمكين آثار أحداث GDOI بشكل افتراضي ويمكن إستردادها من المخزن المؤقت للتتبع باستخدام الأمر show monitor even-trace. 

GM1#show monitor event-trace gdoi ?
  all           Show all the traces in current buffer
  back          Show trace from this far back in the past
  clock         Show trace from a specific clock time/date
  coop          GDOI COOP Event Traces
  exit          GDOI Exit Traces
  from-boot     Show trace from this many seconds after booting
  infra         GDOI INFRA Event Traces
  latest        Show latest trace events since last display
  merged        Show entries in all event traces sorted by time
  registration  GDOI Registration event Traces
  rekey         GDOI Rekey event Traces

GM1#show monitor event-trace gdoi rekey all
*Nov  6 15:55:16.117: GDOI_REKEY_EVENT: ACK_SENT: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 15:55:16.117: GDOI_REKEY_EVENT: REKEY_RCVD: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 16:11:01.125: GDOI_REKEY_EVENT: ACK_SENT: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1
*Nov  6 16:11:01.125: GDOI_REKEY_EVENT: REKEY_RCVD: From 10.1.12.2 to 10.1.13.2 
                      with seq no 1 for the group G1

يوفر تتبع مسار الخروج معلومات تفصيلية حول مسار الخروج، أي حالات الاستثناء والخطأ، مع تمكين خيار traceback بشكل افتراضي. بعد ذلك يمكن إستخدام traceback in order to فك ترميز تسلسل الرمز الدقيق الذي أدى إلى حالة مسار الخروج. أستخدم خيار التفاصيل لاسترداد traceback من المخزن المؤقت للتتبع:

GM1#show monitor event-trace gdoi exit all detail
*Nov  6 15:15:25.611: NULL_VALUE_FOUND:Invalid GROUP Name
-Traceback= 0xCA51318z  0xCA1F4DBz  0xC9B2707z  0xCA1ED4Ez  0x97EB018z
0x97EA960z  0x97E8D62z  0x97F3706z  0x97F3361z  0xA02684Ez  
*Nov  6 15:15:25.611: MAP_NOT_APPLIED_IN_ANY_INTERFACE: 
-Traceback= 0xCA51318z  0xCA46718z  0xCA1EF79z  0x97EB018z  0x97EA960z
0x97E8D62z  0x97F3706z  0x97F3361z  0xA02684Ez  0xA01FD52z  
*Nov  6 15:15:25.650: NULL_VALUE_FOUND:NULL Parameters passed idb or ipaddress 
                      when idb ipaddress is changed
-Traceback= 0xCA51318z  0xCA22430z  0xA09A8DCz  0xA09D8F6z  0xA0F280Fz
0xBA1D1F4z  0xBA1CACCz  0xBA1C881z  0xBA1C5BBz  0xA0F494Az

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

GM1#show monitor event-trace gdoi rekey parameters 
Trace has 512 entries
Stacktrace is disabled by default

GM1#
GM1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
GM1(config)#monitor event-trace gdoi rekey size ?
  <1-1000000>  Number of entries in trace

نقاط التفتيش على مستوى التحكم في GetVPN والمشاكل الشائعة

فيما يلي بعض من مشاكل مستوى التحكم الشائعة ل GetVPN. لإعادة التكرار، يتم تعريف مستوى التحكم على أنه جميع مكونات ميزة GETVPN المطلوبة لتمكين تشفير مستوى البيانات وفك تشفيرها على GMs. وعلى مستوى عال، يتطلب ذلك تسجيل GM بنجاح، وسياسة أمان، وتنزيل/تثبيت SA، وما يليه من إعادة إدخال KEK/TEK.

إعداد COOP وإنشاء السياسة

للتحقق من قيام KS بإنشاء نهج الأمان بنجاح و KEK/TEK المقترن والتحقق من ذلك، أدخل:

KS1#show crypto gdoi ks policy 
Key Server Policy:
For group G1 (handle: 2147483650) server 10.1.11.2 (handle: 2147483650):

For group G1 (handle: 2147483650) server 10.1.12.2 (handle: 2147483651):

  # of teks : 1  Seq num : 10
  KEK POLICY (transport type : Unicast)
    spi : 0x18864836BA888BCD1126671EEAFEB4C7
    management alg     : disabled    encrypt alg       : 3DES      
    crypto iv length   : 8           key size          : 24      
    orig life(sec): 1200        remaining life(sec): 528       
    sig hash algorithm : enabled     sig key length    : 162     
    sig size           : 128       
    sig key name       : key1

  TEK POLICY (encaps : ENCAPS_TUNNEL)
    spi                : 0x91E3985A
    access-list        : ENCPOL
    transform          : esp-null esp-sha-hmac 
    alg key size       : 0             sig key size          : 20        
    orig life(sec)     : 900           remaining life(sec)   : 796       
    tek life(sec)      : 2203          elapsed time(sec)     : 1407      
    override life (sec): 0             antireplay window size: 4         
          
  Replay Value 442843.29 secs

توجد مشكلة واحدة مشتركة مع إعداد نهج KS هي عندما تكون هناك سياسات مختلفة تم تكوينها بين KSs الأساسية والثانوية. قد يؤدي ذلك إلى سلوك KS غير متوقع وسيتم الإبلاغ عن هذا الخطأ:

%GDOI-3-COOP_CONFIG_MISMATCH: WARNNING: replay method configuration between
Primary KS and Secondary KS are mismatched

لا توجد حاليا مزامنة تكوين تلقائية بين KSs الأساسية والثانوية، لذلك يجب تصحيحها يدويا.

لأن COOP هو تكوين حرج (ودائما تقريبا إلزامي) ل GETVPN، فمن الأساسي التأكد من عمل COOP بشكل صحيح وأن أدوار COOP KS صحيحة:

KS1#show crypto gdoi ks coop 
Crypto Gdoi Group Name :G1 
        Group handle: 2147483650, Local Key Server handle: 2147483650

        Local Address: 10.1.11.2 
        Local Priority: 200      
        Local KS Role: Primary   , Local KS Status: Alive     
        Local KS version: 1.0.4 
        Primary Timers: 
                Primary Refresh Policy Time: 20 
                Remaining Time: 10
                Antireplay Sequence Number: 40

        Peer Sessions:
        Session 1:
                Server handle: 2147483651
                Peer Address: 10.1.12.2
                Peer Version: 1.0.4 
                Peer Priority: 100             
                Peer KS Role: Secondary , Peer KS Status: Alive     
                Antireplay Sequence Number: 0

                IKE status: Established
                Counters:
                    Ann msgs sent: 31
                    Ann msgs sent with reply request: 2
                    Ann msgs recv: 64 
                    Ann msgs recv with reply request: 1
                    Packet sent drops: 7 
                    Packet Recv drops: 0 
                    Total bytes sent: 20887 
                    Total bytes recv: 40244

في إعداد البروتوكول الاختياري الوظيفي، يجب ملاحظة تدفق البروتوكول هذا:

IKE Exchange > ANN مع أولويات COOP المتبادلة > إختيار COOP > ANN من KS من الأساسي إلى الثانوي (السياسة وقاعدة بيانات GM والمفاتيح)

عندما لا يعمل COOP بشكل صحيح، أو إذا كان هناك تقسيم COOP، مثل أن تصبح KSs متعددة KS الأساسية، فيجب تجميع تصحيح الأخطاء هذه لاستكشاف الأخطاء وإصلاحها:

debug crypto isakmp
debug crypto gdoi ks coop all-levels 
show crypto isakmp sa
show crypto gdoi ks coop

إعداد IKE

مطلوب تبادل IKE ناجح ل GETVPN لتأمين قناة التحكم للنهج اللاحق وتنزيل SA. وفي نهاية عملية تبادل IKE الناجحة، يتم إنشاء SA ل GDOI_REKEY.

في الإصدارات الأقدم من Cisco IOS 15.4(1)T، يمكن عرض gdoi_REKEY باستخدام الأمر show crypto isakmp sa:

GM1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.13.2       10.1.11.2       GDOI_REKEY        1075 ACTIVE
10.1.11.2       10.1.13.2       GDOI_IDLE         1074 ACTIVE

IPv6 Crypto ISAKMP SA

GM1#

في الإصدار 15.4(1)T من Cisco IOS 15.4(1)T والإصدارات الأحدث، يتم عرض الأمر gdoi_REKEY هذا باستخدام الأمر show crypto gdoi rekey sa:

GM1#show crypto gdoi rekey sa
GETVPN REKEY SA
dst             src             conn-id         status
10.1.13.2       10.1.11.2       1114            ACTIVE

ملاحظة: بمجرد اكتمال عملية التبادل الأولية لنموذج IKE، يتم دفع السياسات والمفاتيح اللاحقة من نظام KS إلى نظام GM باستخدام GDOI_REKEY SA. لذلك فإنه لا يمكن الحصول على مفتاح لحالة عدم انتظام العمل في الدليل عندما تنتهي صلاحيتها، فهي تختفي عندما تنتهي دورة حياتها. ومع ذلك، يجب أن يكون هناك دائما SA GDOI_REKEY على GM لكي تتلقى القرود.

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

debug crypto isakmp 
debug crypto isakmp error
debug crypto isakmp detail (hidden command, if detailed isakmp exchange information
is needed)
debug crypto isakmp packet (hidden command, if packet level isakmp information is needed)

التسجيل، تنزيل النهج، وتثبيت SA

بمجرد نجاح مصادقة IKE، يتم تسجيل GM باستخدام KS. من المتوقع رؤية رسائل syslog هذه عندما يحدث هذا بشكل صحيح:

%GDOI-5-GM_REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey.
%GDOI-5-SA_KEK_UPDATED: SA KEK was updated
%GDOI-5-SA_TEK_UPDATED: SA TEK was updated
%GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.12.2 complete for group G1 using
address 10.1.13.2
%GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies
from KS 10.1.12.2 for group G1 & gm identity  10.1.13.2

يمكن التحقق من النهج والمفاتيح باستخدام هذا الأمر:

GM1#show crypto gdoi    
GROUP INFORMATION

    Group Name               : G1
    Group Identity           : 3333
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 1
    IPSec SA Direction       : Both

     Group Server list       : 10.1.11.2
                               10.1.12.2
                               
    Group member             : 10.1.13.2        vrf: None
       Version               : 1.0.4 
       Registration status   : Registered
       Registered with       : 10.1.12.2
       Re-registers in       : 139 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 10.1.11.2
       Last rekey seq num    : 0
       Unicast rekey received: 1
       Rekey ACKs sent       : 1
       Rekey Rcvd(hh:mm:ss)  : 00:05:20
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 1
       After latest register : 1
       Rekey Acks sents      : 1

 ACL Downloaded From KS 10.1.11.2:
   access-list   deny icmp any any
   access-list   deny eigrp any any
   access-list   deny ip any 224.0.0.0 0.255.255.255
   access-list   deny ip 224.0.0.0 0.255.255.255 any
   access-list   deny udp any port = 848 any port = 848
   access-list   permit ip any any

KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 878
    Encrypt Algorithm        : 3DES
    Key Size                 : 192     
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024    

TEK POLICY for the current KS-Policy ACEs Downloaded:
  Serial1/0:
    IPsec SA:
        spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac 
        sa timing:remaining key lifetime (sec): (200)
        Anti-Replay(Time Based) : 4 sec interval


GM1#
GM1#
GM1#show crypto ipsec sa

interface: Serial1/0
    Crypto map tag: gm1map, local addr 10.1.13.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.1.13.2, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/0
     current outbound spi: 0x0(0)
     PFS (Y/N): N, DH group: none

     local crypto endpt.: 10.1.13.2, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/0
     current outbound spi: 0x8BF147EF(2347845615)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, sibling_flags 80000040, crypto map: gm1map
        sa timing: remaining key lifetime (sec): (192)
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: Y  replay window size: 4
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x8BF147EF(2347845615)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, sibling_flags 80000040, crypto map: gm1map
        sa timing: remaining key lifetime (sec): (192)
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: Y  replay window size: 4
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:
GM1#

ملاحظة: باستخدام GETVPN، تستخدم شبكات SA الواردة والصادرة نفس SPI.

مع تسجيل GETVPN ونوع تثبيت السياسة من المشاكل، تكون هناك حاجة إلى عمليات تصحيح الأخطاء هذه لاستكشاف الأخطاء وإصلاحها:

debug crypto isakmp (KS and GM)
debug crypto gdoi ks registration all-levels (KS)
debug crypto gdoi gm registration all-level (GM)
debug crypto engine (GM only)
show crypto eli detail (multiple iterations on GM)

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

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

event manager applet debug
 event syslog pattern "RESTART"
 action 1.0 cli command "enable"
 action 2.0 cli command "debug crypto gdoi all all"

ريكي

بمجرد تسجيل GMs إلى KS وإعداد شبكة GETVPN بشكل صحيح، تكون KS الأساسية مسؤولة عن إرسال رسائل rekey إلى جميع GMs المسجلة إليها. يتم إستخدام رسائل rekey لمزامنة كل السياسات والمفاتيح والأوقات الزائفة على GMs. يمكن إرسال رسائل rekey من خلال أسلوب بث أحادي أو متعدد.

رأيت هذا syslog رسالة على ال KS عندما ال rekey رسالة أرسلت:

%GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group G1 from address
10.1.11.2 with seq # 11 

على ال GMs، هذا هو syslog أن يرى عندما يستلم هو المفتاح:

%GDOI-5-GM_RECV_REKEY: Received Rekey for group G1 from 10.1.11.2 to 10.1.20.2
with seq # 11

متطلبات زوج مفاتيح RSA ل rekey على KS

تتطلب وظيفة Rekey وجود مفاتيح RSA على KS. يوفر KS المفتاح العام لزوج مفاتيح RSA إلى GM من خلال هذه القناة الآمنة أثناء التسجيل. ثم يقوم مكتب الأخلاقيات بتوقيع رسائل GDOI المرسلة إلى GM مع مفتاح RSA الخاص في حمولة GDOI SIG. تتلقى GM رسائل GDOI وتستخدم مفتاح RSA العام للتحقق من الرسالة. يتم تشفير الرسائل بين KS و GM بواسطة KEK، والتي يتم توزيعها أيضا على GM أثناء التسجيل. وبمجرد اكتمال التسجيل، يتم تشفير المفاتيح التالية باستخدام KEK وتوقيعها باستخدام مفتاح RSA الخاص.

إذا لم يكن مفتاح RSA موجودا على KS أثناء تسجيل GM، تظهر هذه الرسالة على syslog:

%GDOI-1-KS_NO_RSA_KEYS: RSA Key - get : Not found, Required for group G1 

عندما لا تكون المفاتيح موجودة على KS، تسجل GM لأول مرة، ولكن المفتاح الرئيسي التالي يفشل من KS. في نهاية المطاف تنتهي صلاحية المفاتيح الموجودة على GM، ويتم إعادة تسجيلها مرة أخرى.

%GDOI-4-GM_RE_REGISTER: The IPSec SA created for group G1 may have expired/been
cleared, or didn't go through. Re-register to KS.

ونظرا لأنه يتم إستخدام زوج مفاتيح RSA لتوقيع رسائل rekey، فيجب أن تكون هذه الرسائل هي نفسها بين كل وحدات KS الأساسية والثانوية. وهذا يضمن أنه خلال فشل KS أساسي، لا يزال بالإمكان التحقق من صحة المفاتيح المرسلة من قبل KS ثانوي (KS الأساسي الجديد) بشكل صحيح بواسطة GMs. عندما يقوم بإنشاء زوج مفاتيح RSA على KS الأساسية، يجب إنشاء زوج المفاتيح باستخدام الخيار القابل للتصدير حتى يمكن تصديره إلى جميع KSs الثانوية من أجل تلبية هذا المتطلب.

تحليل مشاكل إعادة المفتاح

فشل إعادة توجيه KEK/TEK هو أحد أكثر مشاكل GETVPN شيوعا التي تتم مواجهتها في عمليات نشر العملاء. يجب أن تتبع المشكلات المتعلقة بحل المشكلات الرئيسية الخطوات الأساسية كما هو موضح هنا:

1. هل تم إرسال القردة من قبل KS؟
   
   يمكن التحقق من هذا الإجراء بواسطة أحد المراقبين لرسالة syslog الخاصة ب ٪GDOI-5-KS_SEND_UNICAST_REKEY أو بشكل أكثر دقة باستخدام هذا الأمر:
   
   

   KS1#show crypto gdoi ks rekey
   Group G1 (Unicast)
       Number of Rekeys sent               : 341
       Number of Rekeys retransmitted      : 0
       KEK rekey lifetime (sec)            : 1200
           Remaining lifetime (sec)        : 894
       Retransmit period                   : 10
       Number of retransmissions           : 5
       IPSec SA 1  lifetime (sec)          : 900
           Remaining lifetime (sec)        : 405

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

   KS1#show crypto gdoi ks members 
   
   Group Member Information : 
   
   Number of rekeys sent for group G1 : 346
   
   Group Member ID    : 10.1.14.2   GM Version: 1.0.4 
    Group ID          : 3333
    Group Name        : G1
    Key Server ID     : 10.1.11.2
    Rekeys sent       : 346
    Rekeys retries    : 0
    Rekey Acks Rcvd   : 346
    Rekey Acks missed : 0
   
    Sent seq num : 2       1       2       1
   Rcvd seq num :  2       1       2       1
   
   Group Member ID    : 10.1.13.2   GM Version: 1.0.4 
    Group ID          : 3333
    Group Name        : G1
    Key Server ID     : 10.1.12.2
    Rekeys sent       : 340
    Rekeys retries    : 0
    Rekey Acks Rcvd   : 340
    Rekey Acks missed : 0
   
    Sent seq num : 2       1       2       1
   Rcvd seq num :  2       1       2       1

2. هل تم تسليم حزم rekey في شبكة البنية الأساسية الأساسية؟
   
   يجب اتباع أستكشاف أخطاء IP وإصلاحها بشكل قياسي على مسار إعادة توجيه إعادة التوجيه للمفتاح لضمان عدم إسقاط حزم rekey في شبكة النقل بين KS و GM. بعض أدوات أستكشاف الأخطاء وإصلاحها الشائعة المستخدمة هنا هي قوائم التحكم في الوصول إلى الإدخال/الإخراج (ACLs) و NetFlow والتقاط الحزم في شبكة النقل.
   
   
3. هل وصلت حزم rekey إلى عملية GDOI لمعالجة إعادة المفتاح؟
   
   تحقق من إحصائيات مفتاح GM:
   
   

   GM1#show crypto gdoi gm rekey
   Group G1 (Unicast)
       Number of Rekeys received (cumulative)       : 340
       Number of Rekeys received after registration : 340
       Number of Rekey Acks sent                    : 340

4. هل عادت حزمة إقرار إعادة المفتاح إلى KS؟ 
   
   اتبع الخطوات من 1 إلى 3 لتتبع حزمة إقرار إعادة المفتاح من GM مرة أخرى إلى KS.

مفتاح البث المتعدد

يختلف مفتاح إعادة البث المتعدد عن إعادة مفتاح البث الأحادي في هذه الجوانب:

• بما أن multicast استعملت in order to نقلت هذا rekey ربط من ال KS إلى ال GMs، ال k لا يحتاج أن يكرر ال rekey ربط نفسه. يرسل KS نسخة واحدة فقط من حزمة rekey، ويتم نسخها في الشبكة التي تم تمكين البث المتعدد.
• لا توجد آلية للإقرار لمفتاح إعادة البث المتعدد، لذلك إذا لم تستلم GM حزمة المفتاح، فلن يكون ل KS معرفة به، وبالتالي لن يزيل GM من قاعدة بيانات GM الخاصة به. ونظرا لعدم وجود إقرار، فإن KS سيقوم دائما بإعادة إرسال حزم rekey استنادا إلى تكوين إعادة نقل المفتاح الخاص به.

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

• مشكلة تسليم الحزمة داخل البنية الأساسية لتوجيه البث المتعدد
• لم يتم تمكين التوجيه من نهاية إلى نهاية للبث المتعدد داخل الشبكة 

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

ما إن يعين أنت أن الإصدار خاص إلى multicast rekey، دققت أن KS يرسل المفتاح إلى ال multicast عنوان يعين.

%GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey for group G1 from address
10.1.11.2 to 226.1.1.1  with seq # 6 

اختبر اتصال البث المتعدد بين KS و GM مع طلب بروتوكول رسائل التحكم في الإنترنت (ICMP) إلى عنوان البث المتعدد. يجب أن ترد جميع GMs التي تعد جزءا من مجموعة البث المتعدد على إختبار الاتصال. تأكد من إستثناء ICMP من نهج تشفير KS لهذا الاختبار.

KS1#ping 226.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 226.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.21.2, 44 ms

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

التحقق من ترحيل مستوى التحكم

عرض

عندما يقوم العملاء بترقية GM الخاص بهم إلى إصدار جديد من Cisco IOS، فقد يواجهون حالات فشل إعادة مفتاح KEK مع ظهور هذه الرسالة في syslog:

%GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 1 in seq payload for
group G1, last seq # 11
%GDOI-3-GDOI_REKEY_FAILURE: Processing of REKEY payloads failed on GM 10.1.13.2 in the group G1,
with peer at 10.1.11.2
%CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.1.11.2

يحدث هذا السلوك بسبب مشكلة قابلية التشغيل البيني التي تم تقديمها مع التحقق من عدم إعادة التشغيل الذي تتم إضافته لرسائل مستوى التحكم. وعلى وجه التحديد، سيقوم KS الذي يقوم بتشغيل التعليمات البرمجية القديمة بإعادة تعيين رقم تسلسل إعادة مفتاح KEK إلى 1، وسيتم إسقاط هذا من قبل GM الذي يقوم بتشغيل التعليمات البرمجية الجديدة عند تفسيرها على أنها حزمة rekey معاد تشغيلها. للحصول على مزيد من التفاصيل، راجع معرف تصحيح الأخطاء من Cisco CSCta05809 (GETVPN: مستوى تحكم GETVPN معقول لإعادة التشغيل)، وقيود تكوين GETVPN.

الخلفية

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

• إعادة تكوين الرسائل من KS إلى GM
• رسائل إعلان التعاون بين KSs

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

الحل

لحل هذه المشكلة، يجب ترقية كل من GM و KS إلى إصدارات Cisco IOS بعد ميزة التحقق من إعادة تشغيل مستوى التحكم. باستخدام رمز Cisco IOS الجديد، لا يقوم KS بإعادة تعيين رقم التسلسل مرة أخرى إلى 1 لمفتاح KEK، ولكنه بدلا من ذلك يستمر في إستخدام رقم التسلسل الحالي ويقوم فقط بإعادة تعيين رقم التسلسل لمفاتيح TEK.

تتضمن إصدارات Cisco IOS هذه ميزات التحقق من إعادة التشغيل:

• 12.4(15)T10
• 12.4(22)T3
• 12.4(24)T2
• 15.0(1)M والإصدارات الأحدث 

مشاكل أخرى ذات صلة بإعادة التشغيل

• فشل البرنامج بسبب رسائل فشل التحقق من إعادة التشغيل (معرف تصحيح الأخطاء من Cisco CSCtc52655)

أخطاء إعادة تشغيل مستوى التحكم

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

• Syslog من GM و KS
• تصحيح أخطاء ISAKMP
• تصحيح أخطاء GDOI (rekey and replay) من كل من KS و GM

مشاكل تجزئة حزمة مستوى التحكم

مع GETVPN، يعد تجزئة حزمة مستوى التحكم مشكلة مشتركة، ويمكن أن تظهر نفسها في أحد السيناريوهين عندما تكون حزم مستوى التحكم كبيرة بشكل يكفي أنها ستتطلب تجزئة IP:

• حزم إعلان بروتوكول GetVPN
• حزم مفتاح GetVPN

حزم إعلان COOP

تحمل حزم إعلان COOP معلومات قاعدة بيانات GM، وبالتالي يمكن أن تنمو بشكل كبير في نشر GETVPN كبير. من التجربة السابقة، ستنتج شبكة GETVPN التي تتكون من 1500+ GMs حزم إعلان أكبر من 18024 بايت، وهو حجم المخزن المؤقت الضخم الافتراضي من Cisco IOS. عندما يحدث هذا، يفشل KS في تخصيص مخزن مؤقت كبير بما يكفي لإرسال حزم ANN مع هذا الخطأ:

%SYS-2-GETBUF: Bad getbuffer, bytes= 18872 -Process= "Crypto IKMP", ipl= 0, pid= 183

لتصحيح هذا الشرط، يوصى بتوليف المخزن المؤقت هذا:

buffers huge permanent 10
buffers huge size 65535

إعادة مفاتيح الحزم

كما يمكن أن تتجاوز الحزم النمطية ل GetVPN حجم وحدة الانتقال الأقصى ل IP (MTU) النموذجي 1500 عندما يكون نهج التشفير كبيرا، مثل السياسة التي تتكون من 8+ سطر من إدخالات التحكم في الوصول (ACEs) في قائمة التحكم في الوصول (ACL) للتشفير.

مشكلة التجزئة والتعريف

في كلا السيناريوهين السابقين، يجب أن يكون GETVPN قادرا على إرسال واستقبال حزم UDP المجزأة بشكل صحيح in order to عمل COOP أو GDOI rekey بشكل صحيح. يمكن أن يكون تجزئة IP مشكلة في بعض بيئات الشبكة. على سبيل المثال، تتطلب الشبكة التي تتكون من مستوى إعادة توجيه متعدد المسارات (ECMP) ذي تكلفة متساوية، وبعض الأجهزة في مستوى إعادة التوجيه، إعادة تجميع ظاهرية لحزم IP المجزأة، مثل إعادة تجميع التجزئة الظاهرية (VFR).

لتحديد المشكلة، تحقق من أخطاء إعادة التجميع على الجهاز حيث يشتبه في أن حزم UDP 848 المجزأة لم يتم استقبالها بشكل صحيح:

KS1#show ip traffic | section Frags
  Frags: 10 reassembled, 3 timeouts, 0 couldn't reassemble
         0 fragmented, 0 fragments, 0 couldn't fragment

إذا إستمرت حالات انتهاء المهلة لإعادة التجميع في الزيادة، أستخدم الأمر debug ip error لتأكيد ما إذا كان الإسقاط جزءا من تدفق حزمة rekey/COOP. وبمجرد التأكد من ذلك، يجب تنفيذ أستكشاف أخطاء إعادة توجيه IP وإصلاحها بشكل طبيعي لعزل الجهاز الدقيق في مستوى إعادة التوجيه الذي قد يكون قد أسقط الحزم. تتضمن بعض الأدوات الشائعة الاستخدام ما يلي:

• التقاط الحزمة
• إحصائيات إعادة توجيه حركة المرور
• إحصائيات ميزة الأمان (جدار الحماية، IPS)
• إحصائيات VFR

مشكلات قابلية التشغيل البيني ل GDOI

تم العثور على العديد من مشاكل قابلية التشغيل البيني مع GETVPN على مر السنوات، ومن المهم ملاحظة إصدارات برنامج Cisco IOS بين KS و GM وبين KSs لمسائل قابلية التشغيل البيني.

من بين المشاكل الأخرى المعروفة الخاصة بقابلية التشغيل البيني ل GETVPN:

• التحقق من ترحيل مستوى التحكم
• تغيير سلوك مفتاح GetVPN KEK
• معرف تصحيح الأخطاء من Cisco CSCub42920 (GETVPN: KS يفشل في التحقق من صحة التجزئة في ACK rekey من إصدارات GM السابقة) 
• معرف تصحيح الأخطاء من Cisco CSCuw48400 (GetVPN GM يعجز عن التسجيل أو يفشل rekey - sig-hash > default SHA-1)
• معرف تصحيح الأخطاء من Cisco CSCvg19281 ( يتعدد GETVPN GM يتعطل بعد الترحيل إلى زوج KS جديد؛ إذا كان إصدار GM أقدم من 3.16، وتمت ترقية KS من رمز سابق إلى 3.16 أو أحدث، يمكن أن تحدث هذه المشكلة) 

إجراء ترقية IOS ل GetVPN

يجب اتباع إجراء ترقية Cisco IOS هذا عندما يلزم إجراء ترقية رمز Cisco IOS في بيئة GETVPN:

1. قم بترقية KS الثانوي أولا وانتظر حتى اكتمال عملية إختيار COOP KS.
2. كرر الخطوة 1 لجميع KSs الثانوية.
3. ترقية KS الأساسية.
4. ترقية GMs.

أستكشاف أخطاء مستوى بيانات GETVPN وإصلاحها 

بالمقارنة مع مشاكل مستوى التحكم، فإن مشاكل مستوى بيانات GETVPN هي مشاكل حيث تحتوي GM على السياسة والمفاتيح لإجراء تشفير مستوى البيانات وفك تشفيرها، ولكن لسبب ما لا يعمل تدفق حركة مرور البيانات من نهاية إلى نهاية. تتعلق معظم مشاكل مستوى البيانات ل GETVPN بإعادة توجيه IPsec العامة، وليست خاصة ب GETtvpn. لذلك ينطبق معظم نهج أستكشاف الأخطاء وإصلاحها الموصوف هنا على مشاكل لوحة بيانات IPsec العامة أيضا.

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

• ما هو الجهاز المسؤول - تشفير الموجه أو فك تشفير الموجه؟
• في أي إتجاه تحدث المشكلة - مدخل أو مخرج؟

أدوات أستكشاف أخطاء مستوى بيانات GetVPN وإصلاحها

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

فيما يلي بعض أدوات تصحيح أخطاء مستوى البيانات:

• قوائم الوصول
• محاسبة أسبقية IP
• Netflow
• عدادات الواجهة
• عدادات التشفير
• عدادات الإسقاط العامة لكل ميزة وإعادة التوجيه السريع IP Cisco Express Forwarding (CEF)
• التقاط الحزمة المضمنة (EPC)
• تصحيح أخطاء مستوى البيانات (تصحيح أخطاء حزم IP و CEF)

يمكن التحقق من نقاط التفتيش الموجودة في قاعدة البيانات في الصورة السابقة باستخدام الأدوات التالية:

تشفير GM

• واجهة Ingress LAN
           قائمة التحكم في الوصول (ACL) للإدخال
           Ingress NetFlow
           التقاط حزمة مضمنة
           محاسبة أسبقية الإدخال
  
  
• محرك التشفير
           show crypto ipsec sa 
           إظهار تفاصيل IPsec للتشفير
           إظهار إحصائيات مسرع محرك التشفير
  
  
• واجهة Egress WAN
           Egress NetFlow
           التقاط حزمة مضمنة
           محاسبة أسبقية المخرجات

فك تشفير GM

• واجهة WAN للمدخل
            قائمة التحكم في الوصول (ACL) للإدخال
            Ingress NetFlow
            التقاط حزمة مضمنة
            محاسبة أسبقية الإدخال
  
  
• محرك التشفير
           show crypto ipsec sa
           عرض تفاصيل IPsec للتشفير
           إظهار إحصائيات مسرع محرك التشفير
  
  
• واجهة Egress LAN
           Egress NetFlow
           التقاط حزمة مضمن

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

عدادات التشفير/فك التشفير

تستند عدادات التشفير/فك التشفير على الموجه إلى تدفق IPsec. للأسف لا يعمل هذا بشكل جيد مع GETVPN نظرا لأن GETVPN يقوم عادة بنشر سياسة تشفير "السماح ip any" التي تقوم بتشفير كل شيء. لذلك إذا حدثت المشكلة فقط لبعض التدفقات وليس الكل، فإن هذه العدادات يمكن أن تكون نوعا ما صعبة الاستخدام من أجل التقييم الصحيح إذا تم تشفير الحزم أو فك تشفيرها عندما يكون هناك ما يكفي من حركة مرور بيانات خلفية مهمة تعمل.

GM1#show crypto ipsec sa | in encrypt|decrypt
    #pkts encaps: 100, #pkts encrypt: 100, #pkts digest: 100
    #pkts decaps: 100, #pkts decrypt: 100, #pkts verify: 100

Netflow

يمكن إستخدام NetFlow لمراقبة كل من حركة مرور المدخل والمخرج على كلا GMs. لاحظ مع سماح GETVPN بالإصدار أي سياسة، وسيتم تجميع حركة المرور التي تم تشفيرها ولا توفر معلومات كل تدفق. بعد ذلك، سيتعين تجميع المعلومات لكل تدفق مع وضع علامة أسبقية/أسبقية DSCP الموضحة لاحقا.

في هذا المثال، يتم عرض NetFlow ل 100 عملية إختبار اتصال من مضيف خلف GM1 إلى مضيف خلف GM2 في نقاط التفتيش المختلفة.

تشفير GM

تكوين Netflow:

interface Ethernet0/0
 description LAN  
 ip address 192.168.13.1 255.255.255.0
 ip flow ingress
 ip pim sparse-dense-mode
!
interface Serial1/0
 description WAN interface
 ip address 10.1.13.2 255.255.255.252
 ip flow egress
 ip pim sparse-dense-mode
 crypto map gm1map

إخراج Netflow:

GM1#show ip cache flow | be SrcIf
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Et0/0         192.168.13.2    Se1/0*        192.168.14.2    32 8DE1 6523   100 
Et0/0         192.168.13.2    Se1/0         192.168.14.2    01 0000 0800   100 
GM1#

ملاحظة: في المخرج السابق، * يشير إلى حركة مرور المخرج. يعرض الخط الأول حركة مرور البيانات المشفرة للخروج (مع البروتوكول 0x32 = ESP) من واجهة WAN، والسطر الثاني مدخل ICMP حركة مرور الوصول إلى واجهة LAN.

فك تشفير GM

التكوين:

interface Ethernet0/0
 description LAN interface
 ip address 192.168.14.1 255.255.255.0
 ip flow egress
 ip pim sparse-dense-mode
!
interface Serial1/0
 description WAN interface
 ip address 10.1.14.2 255.255.255.252
 ip flow ingress
 ip pim sparse-dense-mode
 crypto map gm1map

إخراج Netflow:

GM2#show ip cache flow | be SrcIf
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Se1/0         192.168.13.2    Et0/0         192.168.14.2    32 8DE1 6523   100 
Se1/0         192.168.13.2    Et0/0*        192.168.14.2    01 0000 0800   100 
GM2#

تمييز أسبقية DSCP/IP

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

• إستخدام ESP-NULL كتحويل IPsec. لا يزال IPsec يجري تضمين ESP ولكن لا يتم تطبيق أي تشفير على الحمولة، لذلك فإنها تكون مرئية في التقاط الحزمة.
• وضع علامة على تدفق IP باستخدام نقطة رمز خدمات مميزة (DSCP)/وضع علامة أسبقية استنادا إلى خصائص L3/L4 الخاصة بها.

يتطلب ESP-NULL تغييرات على كلا نقطتي نهاية النفق وغالبا لا يتم السماح به بناء على نهج أمان العميل. لذلك، توصي Cisco عادة باستخدام تمييز أسبقية/DSCP بدلا من ذلك.

المخطط المرجعي للأسبقية/DSCP

ToS (hex)	ToS(عشري)	أسبقية IP	DSCP	ثنائي
0xE0	224	التحكم في الشبكة 7	56 وحدة التحكم CS7	11100000
0xC0	192	التحكم في الشبكة البينية 6	48 CS6	11000000
0xB8	184	5 حرج	46 فولت	10111000
0xA0	160		40 CS5	10100000
0x88	136	تجاوز 4 فلاش	34 أف-41	10001000
0x80	128		32 وحدة التحكم CS4	10000000
0x68	104	3 فلاش	26 أف 31	01101000
0x60	96		24 CS3	01100000
0x48	72	منفذان فوريان	18 أف 21	01001000
0x40	64		16 وحدة التحكم CS2	01000000
0x20	32	أولوية واحدة	8 CS1	00100000
0x00	0	روتين 0	0 DFLT	00000000

تمييز الحزم باستخدام DSCP/أسبقية

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

بي بي آر

interface Ethernet1/0
 ip policy route-map mark
!
access-list 150 permit ip host 172.16.1.2 host 172.16.254.2
!
route-map mark permit 10
 match ip address 150
 set ip precedence flash-override

MQC

class-map match-all my_flow
 match access-group 150
!
policy-map marking
 class my_flow
  set ip precedence 4
!
interface Ethernet1/0
 service-policy input marking

إختبار اتصال الموجه

GM1-host#ping ip
Target IP address: 192.168.14.2
Repeat count [5]:  
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 136
...
<snip>

ملاحظة: من الأفضل دائما مراقبة تدفق حركة المرور العادي وملف تعريف أسبقية DSCP قبل تطبيق التمييز بحيث يكون تدفق حركة المرور المميز فريدا.

مراقبة الحزم المميزة

محاسبة أسبقية IP

interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 ip accounting precedence input

middle_router#show interface precedence 
Ethernet0/0 
  Input
Precedence 4:  100 packets, 17400 bytes

قائمة التحكم في الوصول (ACL) للواجهة

middle_router#show access-list 144
Extended IP access list 144
    10 permit ip any any precedence routine
    20 permit ip any any precedence priority
    30 permit ip any any precedence immediate
    40 permit ip any any precedence flash
    50 permit ip any any precedence flash-override (100 matches)
    60 permit ip any any precedence critical
    70 permit ip any any precedence internet (1 match)
    80 permit ip any any precedence network

التقاط حزمة مضمنة

التقاط الحزم المضمن (EPC) هو أداة مفيدة لالتقاط الحزم على مستوى الواجهة لتحديد ما إذا كانت الحزمة قد وصلت إلى جهاز معين. تذكر أن EPC يعمل جيدا لحركة مرور النص الواضح، ولكنه يمكن أن يكون تحديا عندما يتم تشفير الحزم التي يتم الاستيلاء عليها. لذلك يجب إستخدام تقنيات مثل تمييز DSCP/أسبقية التي تمت مناقشتها سابقا أو حروف IP الأخرى، مثل طول حزمة IP، مع EPC لجعل أستكشاف الأخطاء وإصلاحها أكثر فعالية.

تتبع حزمة IOS-XE من Cisco 

هذه ميزة مفيدة لتتبع مسار إعادة توجيه الميزات على جميع الأنظمة الأساسية التي تعمل بنظام التشغيل Cisco IOS-XE، مثل CSR1000V و ASR1000 و ISR4451-X.

المشاكل الشائعة لمستوى بيانات GetVPN

لا يختلف أستكشاف أخطاء مستوى بيانات IPsec ل GETtvpn وإصلاحها غالبا عن أستكشاف أخطاء مستوى بيانات IPsec التقليدية وإصلاحها من نقطة إلى نقطة، مع إستثنائين بسبب خصائص مستوى البيانات الفريدة هذه ل GETtvpn.

فشل مكافحة إعادة التشغيل المستند إلى الوقت

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

1. تعرف على الحزمة التي يتم إسقاطها بسبب فشل شريط الفيديو ثم حدد تشفير GM بعد ذلك.
   
   قبل الإصدار 15.3(2)T، لم يقم syslog لفشل TBAR بطباعة عنوان المصدر للحزمة الفاشلة، لذلك يجعل هذا من الصعب جدا تحديد الحزمة التي فشلت. وقد تم تحسين هذا بشكل ملحوظ في الإصدار 15.3(2)T والإصدارات الأحدث، حيث يطبع Cisco IOS هذا:
   
   

   %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed
           connection id=13, sequence number=1
   
   %GDOI-4-TIMEBASED_REPLAY_FAILED: An anti replay check has failed in group G1:
   my_pseudotime = 620051.84 secs, peer_pseudotime = 619767.09 secs, replay_window =
   4 (sec), src_ip = 192.168.13.2, dst_ip = 192.168.14.2

   
   تم تنفيذ محفوظات TBAR أيضا في هذا الإصدار:
   
   

   GM2#show crypto gdoi gm replay 
   Anti-replay Information For Group G1:
     Timebased Replay:
       Replay Value             : 621388.66 secs
       Input Packets            : 0        Output Packets           : 0    
       Input Error Packets      : 2        Output Error Packets     : 0    
       Time Sync Error          : 0        Max time delta           : 0.00 secs
   
   
   TBAR Error History (sampled at 10pak/min):
       19:29:32.081 EST Wed Nov 13 2013: src=192.168.13.2; my_pst=620051.84 secs;
   peer_pst=619767.09 secs; win=4

   
   

   ملاحظة: تم تنفيذ التحسينات المذكورة سابقا في Cisco IOS-XE بواسطة معرف تصحيح الأخطاء من Cisco CSCun49335 وفي Cisco IOS بواسطة معرف تصحيح الأخطاء من Cisco CSCub91811.

   
   بالنسبة لإصدارات Cisco IOS التي لم تحتوي على هذه الميزة، يمكن أن يوفر أيضا تفاصيل إعادة تشغيل Debug crypto gdoi gm هذه المعلومات، رغم أن تصحيح الأخطاء هذا يطبع معلومات TBAR لجميع حركة المرور (ليس فقط الحزم التي تم إسقاطها بسبب فشل TBAR)، لذلك قد لا يكون من الممكن تشغيلها في بيئة إنتاج.
   
   

   GDOI:GM REPLAY:DET:(0):my_pseudotime is 621602.30 (secs), peer_pseudotime is 621561.14
   (secs), replay_window is 4 (secs), src_addr = 192.168.14.2, dest_addr = 192.168.13.2

2. بمجرد تحديد مصدر الحزمة، يجب أن تكون قادرا على العثور على تشفير GM. ثم ينبغي مراقبة الطابع الزمني الزائف على كل من تشفير أو فك تشفير الآلية العالمية من أجل أي انحراف ممكن في الزمن الزجري. وأفضل طريقة للقيام بذلك هي مزامنة كل من GMs و KS مع NTP، وتجميع معلومات الوقت الزائف بصورة دورية مع ساعة نظام مرجعي عليها كلها لتحديد ما إذا كانت المشكلة ناجمة عن انحراف الساعة على GMs.

GM1

GM1#show crypto gdoi gm replay
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *21:06:26.469 EST Wed Nov 13 2013

Anti-replay Information For Group G1:
  Timebased Replay:
    Replay Value             : 625866.26 secs
    Input Packets            : 0        Output Packets           : 0    
    Input Error Packets      : 0        Output Error Packets     : 0    
    Time Sync Error          : 0        Max time delta           : 0.00 secs

جي إم 2

GM2#show crypto gdoi gm replay
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *21:06:26.743 EST Wed Nov 13 2013

Anti-replay Information For Group G1:
  Timebased Replay:
    Replay Value             : 625866.51 secs
    Input Packets            : 4        Output Packets           : 4    
    Input Error Packets      : 2        Output Error Packets     : 0    
    Time Sync Error          : 0        Max time delta           : 0.00 secs

في المثال السابق، إذا كان الوقت الكاذب (كما تشير إليه قيمة الإعادة) مختلف بشكل كبير بين GMs عندما يتم التقاط المخرجات بنفس الوقت المرجعي، ثم يمكن أن تعزى المشكلة إلى انحراف الساعة.

ملاحظة: في النظام الأساسي لموجه الخدمات المجمعة (Cisco) 1000 Series، بسبب بنية النظام الأساسي، يشير datapath الموجود على معالج تدفق الكم (QFP) بالفعل إلى ساعة الحائط لعد حزم الوقت الكاذب. وقد تسبب ذلك في حدوث مشاكل مع TBAR عندما يتغير وقت ساعة الحائط بسبب مزامنة NTP. وثقت هذا مشكلة مع cisco بق id CSCum37911.

حفظ رأس PMTUD و GETVPN

باستخدام GETtvpn، لا يعمل اكتشاف MTU للمسار (PMTUD) بين تشفير GMs وفك تشفيرها، ويمكن للحزم الكبيرة باستخدام مجموعة بت عدم التجزئة (DF) أن تصبح سوداء. يرجع السبب في أن هذا لا يعمل إلى حفظ رأس GETVPN حيث يتم الاحتفاظ بعناوين مصدر/وجهة البيانات في رأس تضمين ESP. وهذا موضح في هذه الصورة:

كما تظهر الصورة، ينهار PMTUD مع GETVPN مع هذا التدفق:

1. تصل حزمة البيانات الكبيرة على تشفير GM1.
2. تتم إعادة توجيه حزمة ESP بعد التشفير من GM1 ويتم تسليمها إلى الوجهة.
3. إذا كان هناك إرتباط عبور مع IP MTU بقيمة 1400 بايت، فسيتم إسقاط حزمة ESP، وسيتم إرسال حزمة ICMP 3/4 ذات رسالة كبيرة للغاية نحو مصدر الحزمة، وهو مصدر حزمة البيانات.
4. يتم إسقاط حزمة ICMP3/4 إما بسبب عدم إستبعاد ICMP من نهج تشفير GETVPN، أو إسقاطه من قبل المضيف الطرفي لأنه لا يعرف أي شيء حول حزمة ESP (حمولة غير مصدق عليها).

وباختصار، لا يعمل PMTUD مع GETVPN اليوم. in order to عملت حول هذا إصدار، cisco يوصي هذا steps:

1. قم بتنفيذ "ip tcp adjust-mss" لتقليل حجم مقطع حزمة TCP لعدد مرات لاستيعاب مصروفات التشفير العامة والحد الأدنى للمسار MTU في شبكة النقل.
2. امسح بت DF في حزمة البيانات عند وصولهم إلى تشفير GM لتجنب PMTUD.

مشاكل مستوى بيانات IPsec العامة

يشبه معظم أستكشاف أخطاء مستوى بيانات IPsec وإصلاحها أنفاق IPsec التقليدية من نقطة إلى نقطة. إحدى المشكلات الشائعة هي ٪CRYPTO-4-RECVD_PKT_MAC_ERR. راجع syslog "٪CRYPTO-4-RECVD_PKT_MAC_ERR:" رسالة الخطأ مع فقدان إختبار الاتصال عبر أستكشاف أخطاء نفق IPsec وإصلاحها للحصول على مزيد من تفاصيل أستكشاف الأخطاء وإصلاحها.

مشكلات معروفة

يمكن إنشاء هذه الرسالة عند إستلام حزمة IPsec لا تطابق SPI في SADB. راجع معرف تصحيح الأخطاء من Cisco CSCtd47420 - GETVPN - CRYPTO-4-RECVD_PKT_NOT_IPsec الذي تم الإعلام عنه ل PKT الذي لا يطابق التدفق. مثال على ذلك:

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip)
 vrf/dest_addr= /192.168.14.2, src_addr= 192.168.13.2, prot= 50

يجب أن تكون هذه الرسالة ٪CRYPTO-4-RECVD_PKT_INV_SPI، وهو ما يتم الإبلاغ عنه ل IPsec التقليدي وكذلك على بعض الأنظمة الأساسية للأجهزة مثل ASR. تم إصلاح هذه المشكلة التجميلية بواسطة معرف تصحيح الأخطاء من Cisco CSCup80547: خطأ في إرسال تقرير CRYPTO-4-RECVD_PKT_NOT_IPsec ل ESP PAK.

ملاحظة: يمكن أن تظهر هذه الرسائل أحيانا بسبب خطأ GETvpn آخر CSCup34371: يقوم GETVPN GM بإيقاف إلغاء تجزئة حركة المرور بعد مفتاح TEK.

في هذه الحالة، لا يمكن ل GM فك تشفير حركة مرور GETtvpn، رغم أن لها IPsec SA صالح في SADB (يتم إعادة تكوين SA). تختفي المشكلة بمجرد انتهاء صلاحية SA وإزالتها من SADB. تتسبب هذه المشكلة في انقطاع كبير، لأن مفتاح TEK يتم أداؤه مسبقا. على سبيل المثال، يمكن أن يكون الانقطاع 22 دقيقة في حالة مدة بقاء TEK التي تبلغ 7200 ثانية. راجع وصف الخطأ للشرط المحدد الذي يجب تلبيته لمواجهة هذا الخطأ.

أستكشاف أخطاء GETVPN وإصلاحها على الأنظمة الأساسية التي تعمل بنظام التشغيل Cisco IOS-XE

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

تحتوي الأنظمة الأساسية التي تعمل بنظام Cisco IOS-XE على عمليات تنفيذ خاصة بالأنظمة الأساسية، وغالبا ما تتطلب تصحيح بيانات خاص بالنظام الأساسي لمشاكل GetVPN. فيما يلي قائمة بالأوامر المستخدمة عادة لاستكشاف أخطاء GETVPN وإصلاحها على الأنظمة الأساسية التالية:

show crypto eli all

إظهار إحصائيات نهج IPsec لبرنامج النظام الأساسي

إظهار المخزون النشط ل IPsec لبرنامج النظام الأساسي

إظهار ميزة QFP النشطة ل IPsec على جهاز النظام الأساسي الكل

إظهار إحصائيات QFP النشطة لأجهزة النظام الأساسي واضحة

إظهار ميزة QFP النشطة لأجهزة النظام الأساسي واضح

show crypto ipsec sa

show crypto gdoi

إظهار التشفير الداخلي ل IPsec

debug crypto ipSec

خطأ تصحيح أخطاء التشفير في بروتوكول IPsec

حالات تصحيح أخطاء التشفير إلى ipSec

رسالة تصحيح أخطاء التشفير إلى ipSec

debug crypto ipSec hw-req

تفاصيل تصحيح أخطاء تشفير gdoi تحت الحمراء

debug crypto gdoi gm rekey detail

القضايا المشتركة ل ASR1000

فشل تثبيت نهج IPsec (إعادة التسجيل المستمرة)

قد يستمر ASR1000 GM في التسجيل إلى الخادم الرئيسي إذا لم يدعم محرك التشفير سياسة IPsec أو الخوارزمية التي تم تلقيها. على سبيل المثال، في منصات ASR المستندة إلى Nitrox (مثل ASR1002)، لا يتم دعم سياسات Suite-B أو SHA2 وهذا يمكن أن يتسبب في أعراض إعادة التسجيل المستمرة.

مشكلات شائعة تتعلق بالترحيل/الترقية

تحديد شريط ASR1000

على النظام الأساسي ASR1000، قدم إصلاح معرف الأخطاء من Cisco CSCum37911 قيدا على هذا النظام الأساسي حيث يكون وقت الشريط أقل من 20 ثانية غير مدعوم. راجع قيود GetVPN على IOS-XE.

تم فتح خطأ التعزيز هذا لرفع هذا التقييد، معرف تصحيح الأخطاء من Cisco CSCuq25476 - يحتاج ASR1k إلى دعم حجم نافذة شريط GETVPN أقل من 20 ثانية.

تحديث: تم رفع هذا التقييد منذ ذلك الحين مع إصلاح معرف تصحيح الأخطاء من Cisco CSCur57558، ولم يعد قيدا في XE3.10.5 و XE3.13.2 والرمز اللاحق.

لاحظ أيضا، ل GM الذي يعمل على cisco IOS-XE منصة (ASR1k أو ISR4k)، من المستحسن بشدة أن يركض الجهاز إصدارا مع الإصلاح لهذه المشكلة إذا تم تمكين TBAR؛ معرف تصحيح الأخطاء من Cisco CSCut91647 - GETVPN على IOS-XE: GM يسقط الحزم بشكل غير صحيح بسبب فشل TBAR.

مسألة تصنيف ISR4x00

تم العثور على تراجع على النظام الأساسي ISR4x00 حيث يتم تجاهل سياسات الرفض. لمزيد من التفاصيل، راجع معرف تصحيح الأخطاء من Cisco CSCut14355 - GETVPN - ISR4300 GM يتجاهل سياسة الرفض.

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

• Cisco Group Encrypted Transport VPN (GET VPN) - أنظمة
• الدعم التقني والمستندات - Cisco Systems