مقدمة

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

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

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

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

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

المتطلبات المسبقة

تشمل المتطلبات الأساسية لإنشاء الاتصال الظاهري ما يلي:

  • يوفر العميل

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

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

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

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

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

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

  • يقوم الشريك أو العميل بتوفير

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

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

  • Cisco

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

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

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

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

نموذج النشر

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

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

يعرض الشكل التالي مثال نموذج نشر الاتصال الظاهري لخيار التركيز 2 من جانب العميل.

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

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

يقتصر النطاق الترددي لكل نفق على 250 ميجابت في الثانية.

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

يُتوقع من الشركاء العمل بشكل وثيق مع العملاء، مما يضمن اختيار المسار الأمثل لمنطقة خدمة 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 في المنطقة المعنية

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

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

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

    • يلزم إجراء CPE للإعلان عن مسار افتراضي عبر كل نفق

    • CPE قابل للاستجابة لإعادة توزيع المسارات المكتسبة داخل شبكة المؤسسة الخاصة بـ cutomer، حسب الطلب.

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

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

توضح الخطوات التالية عالية المستوى كيفية إنشاء اتصال باستخدام Virtual Connect للمثيل المخصص.
1

تقديم طلب في Cisco CCW

2

تنشيط الاتصال الظاهري من Control Hub

3

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

4

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

الخطوة 1: أمر اتفاقية الأسلحة التقليدية

Virtual Connect عبارة عن وظيفة إضافية للمثيل المخصص في CCW.

1

انتقل إلى موقع طلب CCW ثم انقر فوق "تسجيل الدخول" لتسجيل الدخول إلى الموقع:

https://apps.cisco.com/Commerce/guest.
2

إنشاء تقدير.

3

أضف "A-FLEX-3" SKU.

4

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

5

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

6

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

7

أدخل كمية وعدد المناطق التي يكون الاتصال الظاهري فيها مطلوبًا.

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

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

9

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

الخطوة 2: تنشيط الاتصال الظاهري في Control Hub

1

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

2

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

3

في بطاقة الاتصال الظاهري، يتم إدراج كمية الاتصال الظاهري التي تم شراؤها. يستطيع المسؤول الآن النقر على تنشيط لبدء تفعيل الاتصال الظاهري.

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

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

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

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

    يمكن أن يكون عنوان IP الذي يوفره العميل خاص أو عام.

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

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

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

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

6

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

لأسباب أمنية لن تتوفر المصادقة وكلمة مرور BGP في المستند الذي تم تصديره، ولكن يستطيع المسؤول عرض الشيء نفسه في Control Hub عن طريق النقر على عرض الإعدادات ضمن Control Hub، الاتصال > المثيل المكرّس > علامة تبويب الاتصال السحابي.

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

1

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

2

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

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

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

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

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

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

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

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

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

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

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

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

بعض الأخطاء الشائعة في تفاوض IKEv2 هي:

  • لا تتطابق إعدادات IKEv2 على جانب CPE مع جانب Cisco، أعد التحقق من الإعدادات المذكورة:

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

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

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

    • تحقق من إعداد مدى الحياة.

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

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

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

    • Permit GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255" (أو أمر مكافئ)

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

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

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

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

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

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

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

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

  • رسائل تنشيط GRE من واجهة نفق GRE من جانب CPE إلى واجهة نفق GRE من جانب المثيل المكرّس.

  • جلسة TCP جار BGP من جار BGP من جانب CPE إلى جار BGP من جانب المثيل المكرّس.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • تحقق من إعدادات "السرية الأمامية المثالية" ومن إعدادات المطابقة على جانب المثيل المكرّس.

  • تحقق من إعدادات مدى الحياة.

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

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

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

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

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

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

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

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

    إذا كانت رسائل 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 وتم التحقق من العناصر السابقة، فقد يلزم حينئذٍ التقاط الحزمة للتأكد من أن اختبار ping icmp يؤدي إلى حزمة GRE التي يتم تغليفها بعد ذلك في حزمة IPsec ثم إرسالها من عنوان IPsec المصدر إلى عنوان IPsec الوجهة. يمكن أن تساعد العدادات الموجودة على واجهة نفق GRE وعدادات جلسات IPsec أيضًا في إظهار. إذا كانت حزم الإرسال والاستقبال تتزايد.

بالإضافة إلى حركة مرور ping، يجب أن يُظهر التقاط أيضًا حزم keepalive GRE حتى أثناء حركة مرور الخمول. وأخيرًا، إذا تم تكوين BGP، فيجب أيضًا إرسال حزم BGP keepalive كحزم 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 المحلي مع ما يتوقعه جانب المثيل المخصص، تحقق من أن رقم AS المحلي يطابق معلمات المثيل المخصص المتوقعة.

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

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

تبديل توجيه BGP

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

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

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

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

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

تكوين MTU

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

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