مقدمة

Virtual Connect هو خيار إضافي أداة إضافية للاتصال السحابي بمثيل مخصص لإجراء Webex Calling (مثيل مخصص). يتيح Virtual Connect للعملاء توسيع شبكتهم الخاصة بشكل آمن عبر الإنترنت باستخدام أنفاق IP VPN من نقطة إلى نقطة. يوفر خيار الاتصال هذا إنشاءًا سريعًا لاتصال الشبكة الخاصة باستخدام معدات العميل الحالية (CPE) والاتصال بالإنترنت.

تستضيف Cisco وتدير وتضمن أنفاق IP VPN الزائدة والوصول المطلوب إلى الإنترنت في منطقة (مناطق) مركز بيانات مثيلات Cisco المخصصة حيث تكون الخدمة مطلوبة. وبالمثل ، فإن المسؤول مسؤول عن CPE المقابلة وخدمات الإنترنت المطلوبة لإنشاء Virtual Connect.

سيتضمن كل طلب Virtual Connect في منطقة مثيلات مخصصة معينة أنفاق لتغليف التوجيه العام (GRE) المحمية بواسطة تشفير IPSec (GRE عبر IPSec) ، واحد لكل مركز بيانات Cisco في المنطقة المحددة.

يحتوي Virtual Connect على حد للنطاق الترددي يبلغ 250 ميجابت في الثانية لكل نفق ويوصى به لعمليات النشر الأصغر. نظرًا لاستخدام أنفاق VPN من نقطة إلى نقطة ، يجب أن تمر كل حركة المرور إلى السحابة من خلال CPE الرئيسي للعميل ، وبالتالي قد لا يكون مناسبًا حيث يوجد الكثير من المواقع البعيدة. للحصول على خيارات التناظر البديلة الأخرى ، يرجى الرجوع الاتصال السحابي .

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

تتضمن المتطلبات الأساسية لإنشاء Virtual Connect ما يلي:

  • يقدم العميل

    • اتصال بالإنترنت بنطاق ترددي كافٍ لدعم النشر

    • عنوان IP العامة لنفقين من IPSec

    • عناوين IP الخاصة بنقل GRE من جانب العميل لنفقين من GRE

  • الشريك والعميل

    • العمل معًا لتقييم متطلبات النطاق الترددي

    • تأكد من دعم جهاز الشبكة لتوجيه بروتوكول بوابة الحدود (BGP) و GRE عبر تصميم نفق IPSec

  • يقدم الشريك أو العميل

    • فريق شبكة لديه معرفة بتقنيات أنفاق VPN من موقع إلى موقع

    • فريق شبكة لديه معرفة بـ BGP و eBGP ومبادئ التوجيه العامة

  • Cisco

    • قامت Cisco بتعيين أرقام نظام ذاتي خاص (ASNs) وعناوين IP عابرة لواجهات نفق GRE

    • Cisco بتعيين شبكة عامة ولكن غير قابلة للتوجيه عبر الإنترنت من الفئة C (/ 24) لعنونة سحابة مثيل مخصصة


إذا كان لدى العميل جهاز CPE واحد فقط ، فسيكون النفقان باتجاه مركزي بيانات Cisco (DC1 و DC2) في كل منطقة من جهاز CPE هذا. يمتلك العميل أيضًا خيارًا لجهازين CPE ، ثم يجب توصيل كل جهاز CPE بنفق واحد فقط باتجاه مركزي بيانات Cisco (DC1 و DC2) في كل منطقة. يمكن تحقيق التكرار الإضافي عن طريق إنهاء كل نفق في موقع / موقع مادي منفصل داخل البنية التحتية للعميل.

التفاصيل الفنية

نموذج النشر

يستخدم Virtual Connect بنية رأسية مزدوجة الطبقة ، حيث يتم توفير مستويات التوجيه والتحكم في GRE بواسطة جهاز واحد ويتم توفير مستوى تحكم IPSec بواسطة جهاز آخر.

عند الانتهاء من الاتصال الظاهري الاتصال ، سيتم إنشاء اثنين من GRE عبر أنفاق IPSec بين شبكة مؤسسة العميل ومراكز بيانات Cisco الخاصة بالمثيل المخصص. واحد لكل مركز بيانات فائض داخل المنطقة المعنية. يتم تبادل عناصر الشبكات الإضافية المطلوبة للتناظر من قبل الشريك أو العميل إلى Cisco عبر نموذج تنشيط Control Hub Virtual Connect.

يوضح الشكل 1 مثالاً طراز النشر Virtual Connect لخيار 2-المركّز من جانب العميل.

Virtual Connect - VPN هو تصميم Hub ، حيث يتم توصيل مواقع Hub الخاصة بالعميل بـ DC1 و DC2 لمراكز بيانات المثيل المخصص داخل منطقة معينة.

يوصى باستخدام موقعي Hub لتحسين التكرار ، ولكن موقع One Hub الذي يحتوي على نفقين هو أيضًا طراز النشر مدعوم.


عرض النطاق الترددي لكل نفق محدد بـ 250 ميجابت في الثانية.


ستحتاج المواقع البعيدة الخاصة بالعميل داخل نفس المنطقة إلى الاتصال مرة أخرى بموقع (مواقع) المحور عبر شبكة WAN الخاصة بالعميل وليست مسؤولية Cisco عن هذا الاتصال.

من المتوقع أن يعمل الشركاء بشكل وثيق مع العملاء ، مما يضمن اختيار المسار الأمثل لمنطقة خدمة "Virtual Connect".

يوضح الشكل 2 المناطق المخصصة للاتصال السحابي للمثيلات.

التوجيه

يتم تنفيذ التوجيه لوظيفة Virtual Connect أداة إضافية باستخدام BGP (eBGP) بين المثيل المخصص وجهاز فرضية العميل (CPE). ستقوم Cisco بالإعلان عن شبكتها الخاصة لكل وحدة تحكم في المنطقة (DC) فائضة عن الحاجة داخل منطقة ما إلى CPE الخاص بالعميل ، ويكون CPE مطلوبًا للإعلان عن مسار افتراضي إلى Cisco.

  • Cisco بصيانة وتخصيص

    • عنوان IP لواجهة النفق (ارتباط عابر للتوجيه) تقوم Cisco بتعيينه من مساحة عنوان مشتركة معينة (غير قابلة للتوجيه بشكل عام)

    • عنوان تحويل النفق (من جانب Cisco)

    • أرقام النظام الذاتي الخاص (ASN) لتكوين توجيه BGP للعميل

      • تعيّن Cisco من نطاق الاستخدام الخاص المعين: من 64512 إلى 65534

  • تستخدم eBGP لتبادل المسارات بين المثيل المخصص و CPE

    • ستقوم Cisco بتقسيم الشبكة المعينة / 24 إلى 2/25 شبكة لكل DC في المنطقة المعنية

    • في Virtual Connect ، يتم الإعلان عن كل شبكة / 25 مرة إلى CPE بواسطة Cisco عبر أنفاق VPN ذات الصلة من نقطة إلى نقطة (ارتباط عابر)

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

    • يتم تكوين جانب Cisco من كل نفق GRE (عنوان IP لواجهة النفق) كجوار BGP على CPE

    • يلزم استخدام CPE للإعلان عن مسار افتراضي عبر كل من الأنفاق

    • يعد CPE مسؤولاً عن إعادة توزيع المسارات المكتسبة ، كما هو مطلوب ، داخل شبكة مؤسسة القاطع.

  • في ظل حالة فشل الارتباط غير الفاشل ، سيكون لدى CPE واحد نفقان نشطان / نشطان. بالنسبة إلى عقدتين CPE ، سيكون لكل CPE نفق نشط واحد ويجب أن تكون كلتا عقدتي CPE نشطة وتمرير حركة المرور. في ظل سيناريو عدم الفشل ، يجب تقسيم حركة المرور إلى نفقين يتجهان إلى الوجهة الصحيحة / 25 وجهة ، إذا تعطل أحد النفق ، يمكن للنفق المتبقي نقل حركة المرور لكليهما. في ظل سيناريو الفشل هذا ، عندما تكون الشبكة / 25 معطلة ، يتم استخدام شبكة / 24 كطريق احتياطي. سترسل Cisco حركة مرور العملاء عبر شبكة WAN الداخلية الخاصة بها نحو DC الذي فقد الاتصال.

عملية الاتصال

تصف الخطوات عالية المستوى التالية كيفية إنشاء اتصال مع Virtual Connect for Dedicated Instance.

1

ضع طلبًا في Cisco CCW

2

قم بتنشيط Virtual Connect من Control Hub

3

تقوم Cisco بتنفيذ تكوين الشبكة

4

ينفذ العميل تكوين الشبكة

الخطوة 1: طلب CCW

Virtual Connect هي وظيفة أداة إضافية لـ Dedicated Instance في CCW.

1

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

2

إنشاء تقدير.

3

أضف رمز التخزين التعريفي "A-FLEX-3".

4

حدد خيارات التحرير.

5

في علامة تبويب الاشتراك التي تظهر ، حدد الخيارات والوظائف الإضافية.

6

ضمن الوظائف الإضافية الإضافية ، حدد خانة اختيار بجانب "Virtual Connect for Dedicated Instance". اسم SKU هو "A-FLEX-DI-VC".

7

أدخل كمية وعدد المناطق التي يلزم فيها Virtual Connect.


 
يجب ألا تتجاوز كمية Virtual Connect العدد الإجمالي للمناطق التي تم شراؤها للمثيلات المخصصة. أيضًا ، لا يُسمح إلا بطلب Virtual Connect واحد لكل منطقة.
8

عندما تكون راضيًا عن اختياراتك ، انقر فوق "تحقق" و "حفظ" في الجزء الأيمن العلوي من الصفحة.

9

انقر فوق حفظ ومتابعة لإنهاء طلبك. يتم تطبيق طلبك النهائي الآن في شبكة الطلب.

الخطوة 2: تنشيط Virtual Connect في Control Hub

1

سجّل الدخول إلى Control Hubhttps://admin.webex.com/login .

2

في الخدمات ، انتقل إلى الاتصال> Instacnce مخصص> الاتصال السحابي .

3

في بطاقة Virtual Connect ، يتم سرد كمية Virtual Connect التي تم شراؤها. يمكن للمسؤول الآن النقر فوق تنشيط لبدء تنشيط Virtual Connect.


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

عند النقر على ملف تنشيط زر قم بتنشيط Virtual Connect يتم عرض النموذج للمسؤول لتوفير التفاصيل الفنية لـ Virtual Connect المطلوبة لتكوينات النظراء على جانب Cisco.


 
يوفر النموذج أيضًا معلومات ثابتة من جانب Cisco ، بناءً على المنطقة المحددة. ستكون هذه المعلومات مفيدة لمسؤولي العملاء لتكوين CPE من جانبهم لإنشاء الاتصال.
  1. عنوان IP لنقل نفق GRE : يُطلب من العميل توفير عناوين IP الخاصة بالنقل من جانب العميل وستقوم Cisco بتخصيص عناوين IP بشكل ديناميكي بمجرد اكتمال التنشيط. يجب أن تسمح قائمة التحكم في الوصول (ACL) لـ IPSec لحركة المرور المثيرة للاهتمام IP / 32 لنقل النفق المحلي إلى IP / 32 لنقل النفق عن بُعد. يجب أن تحدد قائمة التحكم بالوصول (ACL) بروتوكول GRE IP فقط.


     
    يمكن أن يكون عنوان IP الذي يوفره العميل خاصًا أو عامًا.
  2. أقران IPSec : يُطلب من العميل توفير عناوين IP المصدر لـ IPSec Tunnel وتخصص Cisco عنوان IP للوجهة IPSec . يتم أيضًا دعم تنفيذ ترجمة NAT لعنوان نفق IPSEC داخلي إلى عنوان عام إذا لزم الأمر.


     

    يجب أن يكون عنوان IP الذي قدمه العميل عامًا.


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

انقر فوق ملف تنشيط زر بمجرد ملء جميع الحقول الإلزامية.

6

بعد اكتمال نموذج تنشيط Virtual Connect لمنطقة معينة ، يمكن للعميل تصدير نموذج التنشيط من Control Hub ، الاتصال> مثيل مخصص> علامة تبويب الاتصال السحابي والنقر على إعدادات التصدير.


 
نظرًا لأسباب أمنية ، لن تكون المصادقة وكلمة مرور BGP متاحة في المستند الذي تم تصديره ، ولكن يمكن للمسؤول عرضهما في Control Hub من خلال النقر فوق عرض الإعدادات ضمن مركز التحكم ، الاتصال> مثيل مخصص> علامة تبويب الاتصال السحابي.

الخطوة 3: تقوم Cisco بتنفيذ تكوين الشبكة

1

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

2

ستكمل Cisco التكوينات المطلوبة على جهاز Cisco الجانبي بالداخل 5 أيام عمل . عند الانتهاء بنجاح ، سيتم تحديث الحالة إلى "مفعل" لتلك المنطقة المعينة في Control Hub.

الخطوة 4: ينفذ العميل تكوين الشبكة

تم تغيير الحالة إلى "تم تنشيطه" لإخطار مسؤول العميل بأن جانب Cisco من التكوينات لاتصال IP VPN قد اكتمل بناءً على المدخلات المقدمة من العميل. ولكن ، من المتوقع أن يكمل مسؤول العميل جانبه من التكوينات على CPEs ويختبر مسارات الاتصال لنفق Virtual Connect ليكون عبر الإنترنت. في حالة وجود أي مشكلات في وقت التكوين أو الاتصال ، يمكن للعميل الوصول إلى Cisco TAC للحصول على المساعدة.

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

IPsec المرحلة الأولى (تفاوض IKEv2) استكشاف الأخطاء وإصلاحها والتحقق من الصحة

تتضمن مفاوضات نفق IPsec مرحلتين ، مرحلة IKEv2 ومرحلة IPsec. إذا لم تكتمل مفاوضات مرحلة IKEv2 ، فلن يكون هناك بدء لمرحلة IPsec ثانية. أولاً ، قم بإصدار الأمر "show crypto ikev2 sa" (على معدات Cisco ) أو أمر مشابه على معدات الجهة الخارجية للتحقق مما إذا كانت جلسة IKEv2 نشطة. إذا كانت جلسة IKEv2 غير نشطة ، فقد تكون الأسباب المحتملة:

  • حركة المرور المثيرة للاهتمام لا تؤدي إلى تشغيل نفق IPsec.

  • تم تكوين قائمة الوصول نفق IPsec بشكل خاطئ.

  • لا يوجد اتصال بين العميل وعنوان IP لنقطة نهاية نفق IPsec المخصص.

  • لا تتطابق معلمات جلسة IKEv2 بين جانب المثيل المخصص وجانب العميل.

  • جدار الحماية يحظر حزم IKEv2 UDP .

أولاً ، تحقق من سجلات IPsec بحثًا عن أي رسائل تُظهر تقدم مفاوضات نفق IKEv2. قد تشير السجلات إلى مكان وجود مشكلة في مفاوضات IKEv2. قد يشير نقص رسائل التسجيل أيضًا إلى أن جلسة IKEv2 لم يتم تنشيطها.

بعض الأخطاء الشائعة في مفاوضات IKEv2 هي:
  • إعدادات IKEv2 على جانب CPE لا تتطابق مع جانب Cisco ، أعد التحقق من الإعدادات المذكورة:

    • تحقق من أن إصدار IKE هو الإصدار 2.

    • تحقق من أن معلمات التشفير والمصادقة تطابق التشفير المتوقع على جانب المثيل المخصص.


      عندما يكون تشفير "GCM" قيد الاستخدام ، يعالج بروتوكول GCM المصادقة ويضبط معلمة المصادقة على NULL.

    • تحقق من إعداد العمر.

    • تحقق من مجموعة معامل Diffie Hellman.

    • تحقق من إعدادات الوظيفة العشوائية الزائفة.

  • لم يتم تعيين قائمة الوصول لخريطة التشفير على:

    • تصريح GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255 "(أو أمر مكافئ)


      يجب أن تكون قائمة الوصول خاصة ببروتوكول "GRE" ولن يعمل بروتوكول "IP".

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


قد لا يبدأ جانب المثيل المخصص دائمًا تبادل IKEv2 وقد يتوقع في بعض الأحيان أن يكون جانب CPE الخاص بالعميل هو البادئ.

تحقق من تكوين جانب CPE للمتطلبات الأساسية التالية لبدء جلسة IKEv2:

  • تحقق من وجود قائمة الوصول تشفير IPsec لحركة مرور GRE (البروتوكول 50) من IP لنقل نفق CPE إلى عنوان IP الخاص بنفق المثيل المخصص.

  • تأكد من تمكين واجهة نفق GRE من أجل GRE keepalives ، إذا لم يكن الجهاز يدعم GRE keepalives ، فسيتم إخطار Cisco لأنه سيتم تمكين GRE keepalives على جانب المثيل المخصص افتراضيًا.

  • تأكد من تمكين BGP وتكوينه باستخدام عنوان الجار لعنوان IP الخاص بنفق المثيل المخصص.

عند التهيئة بشكل صحيح ، يبدأ ما يلي نفق IPsec ومفاوضات IKEv2 في المرحلة الأولى:

  • تحافظ GRE على الحياة من واجهة نفق GRE من جانب CPE إلى واجهة نفق GRE من جانب المثيل المخصص.

  • جلسة TCP المجاورة لـ BGP من جوار BGP في جانب CPE إلى جوار BGP من جانب المثيل المخصص.

  • Ping من عنوان IP للنفق الجانبي CPE إلى عنوان IP عنوان IP الجانبي المخصص.


    لا يمكن أن يكون Ping هو عنوان IP الخاص بالنفق لنقل IP، ويجب أن يكون عنوان IP للنفق لنقل IP للنفق.

إذا كان تتبع الحزمة مطلوبًا لحركة مرور IKEv2 ، فقم بتعيين عامل التصفية لـ UDP وإما المنفذ 500 (عندما لا يكون هناك جهاز NAT في منتصف نقاط نهاية IPsec) أو المنفذ 4500 (عند إدخال جهاز NAT في منتصف IPsec نقاط النهاية).

تحقق من أن حزم IKEv2 UDP مع المنفذ 500 أو 4500 يتم إرسالها واستلامها من وإلى عنوان IPsec عنوان IP بـ DI.


قد لا يبدأ مركز بيانات المثيل المخصص دائمًا أول حزمة IKEv2. المطلب هو أن جهاز CPE قادر على بدء حزمة IKEv2 الأولى نحو جانب المثيل المخصص.

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

قد لا تسمح بعض جدران الحماية ومعدات الإنترنت بتتبع المسار.

IPsec المرحلة الثانية (تفاوض IPsec) استكشاف الأخطاء وإصلاحها والتحقق من الصحة

تحقق من أن المرحلة الأولى من IPsec (أي اقتران أمان IKEv2) نشطة قبل استكشاف أخطاء المرحلة الثانية لـ IPsec وإصلاحها. قم بتنفيذ "show crypto ikev2 sa" أو أمر مكافئ للتحقق من جلسة IKEv2. في الإخراج ، تحقق من أن جلسة IKEv2 قد تم رفعها لأكثر من بضع ثوانٍ وأنها لا ترتد. يظهر وقت تشغيل الجلسة على أنه "وقت نشط" للجلسة أو ما يعادله في الإخراج.

بمجرد التحقق من جلسة IKEv2 على أنها نشطة ونشطة ، تحقق من جلسة IPsec. كما هو الحال مع جلسة IKEv2 ، قم بتنفيذ أمر "show crypto ipsec sa" أو أمر مكافئ للتحقق من جلسة IPsec. يجب أن تكون كل من جلسة IKEv2 وجلسة IPsec نشطة قبل إنشاء نفق GRE. إذا لم تظهر جلسة IPsec على أنها نشطة ، فتحقق من سجلات IPsec بحثًا عن رسائل الخطأ أو أخطاء التفاوض.

بعض المشكلات الأكثر شيوعًا التي قد تتم مواجهتها أثناء مفاوضات IPsec هي:

الإعدادات الموجودة على جانب CPE لا تتطابق مع جانب المثيل المخصص ، أعد التحقق من الإعدادات:

  • تحقق من أن معلمات التشفير والمصادقة تطابق الإعدادات الموجودة على جانب المثيل المخصص.

  • تحقق من إعدادات سرية إعادة التوجيه المثالية وأن إعدادات المطابقة على جانب المثيل المخصص.

  • تحقق من إعدادات العمر.

  • تحقق من تكوين IPsec في وضع النفق.

  • تحقق من عناوين IPsec المصدر والوجهة.

استكشاف أخطاء واجهة النفق والتحقق منها

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

  • لا يتطابق نقل واجهة النفق VRF مع VRF لواجهة الاسترجاع (إذا تم استخدام تكوين VRF على واجهة النفق).


    إذا لم يتم استخدام تكوين VRF على واجهة النفق ، فيمكن تجاهل هذا الفحص.

  • لم يتم تمكين Keepalives على واجهة النفق الجانبي CPE


    إذا لم يتم دعم Keepalives على جهاز CPE ، فيجب إخطار Cisco بحيث يتم تعطيل عمليات الاحتفاظ الافتراضية على جانب المثيل المخصص أيضًا.

    إذا كانت keepalives مدعومة ، فتحقق من تمكين Keepalives.

  • القناع أو عنوان IP لواجهة النفق غير صحيح ولا يتطابق مع قيم المثيل المخصص المتوقعة.

  • عنوان نقل نفق المصدر أو الوجهة غير صحيح ولا يتطابق مع قيم المثيل المخصص المتوقعة.

  • يقوم جدار الحماية بحظر حزم GRE من إرسالها إلى نفق IPsec أو استلامها من نفق IPsec (يتم نقل نفق GRE عبر نفق IPsec)

يجب أن يتحقق اختبار ping من أن واجهة النفق المحلية قيد التشغيل وأن الاتصال جيد بواجهة النفق البعيد. قم بإجراء فحص ping من عنوان IP للنفق (وليس عنوان IP الخاص بالنقل) إلى عنوان IP للنفق البعيد.


تسمح قائمة الوصول المشفر لنفق IPsec الذي يحمل حركة مرور نفق GRE بعبور حزم GRE فقط. ونتيجة لذلك ، لن تعمل أجهزة الاتصال من عنوان IP الخاص بالنقل النفقي إلى عنوان IP الخاص بالنقل النفقي.

ينتج عن فحص ping حزمة GRE التي يتم إنشاؤها من IP الخاص بنفق المصدر إلى IP الخاص بنقل الوجهة بينما ستكون الحمولة الخاصة بحزمة GRE (عنوان IP الداخلي) هي المصدر والوجهة IP للنفق.

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

بالإضافة إلى حركة مرور ping ، يجب أن يُظهر الالتقاط أيضًا حزم GRE النشطة حتى أثناء حركة المرور الخاملة. أخيرًا ، إذا تم تكوين BGP ، فيجب أيضًا إرسال حزم BGP الفعالة كحزم GRE مغلفة في حزم IPSEC وكذلك عبر VPN.

استكشاف الأخطاء وإصلاحها والتحقق من صحة BGP

جلسات BGP

مطلوب BGP كبروتوكول توجيه عبر نفق VPN IPsec. يجب أن يقوم جار BGP المحلي بتأسيس جلسة eBGP مع جار مثيل BGP المخصص. عناوين IP الخاصة بجوار eBGP هي نفسها عناوين IP الخاصة بالنفق المحلي والبعيدة. تأكد أولاً من انتهاء جلسة BGP ثم تحقق من استلام المسارات الصحيحة من المثيل المخصص وإرسال المسار الافتراضي الصحيح إلى المثيل المخصص.

إذا كان نفق GRE قيد التشغيل ، فتحقق من نجاح الأمر ping بين عنوان IP لنفق GRE المحلي والبعيدة. إذا نجح الأمر ping ولكن جلسة BGP لم تظهر بعد ، فابحث عن أخطاء إنشاء BGP في سجل BGP.

بعض مشكلات تفاوض BGP الأكثر شيوعًا هي:

  • لا يتطابق رقم AS البعيد مع رقم AS الذي تم تكوينه من جانب المثيل المخصص ، أعد التحقق من تكوين الجوار AS.

  • لا يتطابق رقم AS المحلي مع ما يتوقعه جانب المثيل Dedictaed ، تحقق من أن رقم AS المحلي يطابق معلمات المثيل المخصص المتوقعة.

  • يقوم جدار الحماية بحظر إرسال حزم BGP TCP المغلفة في حزم GRE إلى نفق IPsec أو استلامها من نفق IPSEC

  • لا يطابق عنوان IP المجاور لـ BGP البعيد عنوان IP لنفق GRE البعيد.

تبادل طريق BGP

بمجرد التحقق من جلسة BGP لكلا النفقين ، تأكد من إرسال المسارات الصحيحة واستلامها من جانب المثيل المخصص.

يتوقع حل Dedicated Instance VPN إنشاء نفقين من جانب العميل / الشريك. يشير النفق الأول إلى مركز بيانات المثيل المخصص A والنفق الثاني إلى مركز بيانات المثيل المخصص B. يجب أن يكون كلا النفقين في حالة نشطة ويتطلب الحل نشرًا نشطًا / نشطًا. سيقوم كل مركز بيانات مثيل مخصص بالإعلان عن مساره المحلي / 25 بالإضافة إلى مسار النسخ الاحتياطي / 24. عند التحقق من مسارات BGP الواردة من المثيل المخصص ، تأكد من أن جلسة BGP المرتبطة بالنفق الذي يشير إلى مركز بيانات المثيل المخصص A تتلقى مسار محلي لمركز بيانات المثيل المخصص A / 25 بالإضافة إلى مسار النسخ الاحتياطي / 24. بالإضافة إلى ذلك ، تأكد من أن النفق الذي يشير إلى مركز بيانات المثيل المخصص B يستقبل مسار محلي لمركز بيانات المثيل المخصص B / 25 بالإضافة إلى مسار النسخ الاحتياطي / 24. لاحظ أن مسار النسخ الاحتياطي / 24 سيكون نفس المسار المعلن عنه من مركز بيانات المثيل المخصص A ومركز بيانات المثيل المخصص ب.

يتم توفير التكرار لمركز بيانات المثيل المخصص إذا تعطلت واجهة النفق لمركز البيانات هذا. إذا فُقد الاتصال بمركز بيانات المثيل المخصص A ، فسيتم إعادة توجيه حركة المرور من مركز بيانات المثيل المخصص B إلى مركز البيانات A. في هذا السيناريو ، سيستخدم النفق إلى مركز البيانات B مسار مركز البيانات B / 25 لإرسال حركة المرور إلى مركز البيانات B والنفق إلى مركز البيانات B سيستخدم مسار النسخ الاحتياطي / 24 لإرسال حركة المرور إلى مركز البيانات أ عبر مركز البيانات ب.

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

يجب الإعلان عن المسار 0.0.0.0/0 من جانب العميل إلى جانب مركز بيانات المثيل المخصص. لن يتم قبول مسارات أكثر تحديدًا من جانب المثيل المخصص. تأكد من الإعلان عن المسار 0.0.0.0/0 من نفق مركز بيانات المثيل المخصص A ونفق مركز بيانات المثيل المخصص ب.

تكوين MTU

في جانب المثيل المخصص ، يتم تمكين ميزتين لضبط MTU ديناميكيًا لأحجام الحزم الكبيرة. يضيف نفق GRE المزيد من العناوين إلى حزم IP المتدفقة خلال جلسة VPN . يضيف نفق IPsec رؤوسًا إضافية أعلى رؤوس GRE مما يؤدي إلى تقليل أكبر وحدة الإرسال الكبرى المسموح بها عبر النفق.

يضبط نفق GRE ميزة MSS ويتم تمكين مسار نفق GRE في ميزة اكتشاف MTU على جانب المثيل المخصص. قم بتكوين "ip tcp Adjust-mss 1350" أو أمر مكافئ بالإضافة إلى "مسار النفق \ u0002mtu-discovery" أو أمر مكافئ من جانب العميل للمساعدة في الضبط الديناميكي لـ MTU لحركة المرور عبر نفق VPN .