مقدمة

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

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

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

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

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

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

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

  • يوفر العميل

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

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

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

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

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

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

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

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

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

  • Cisco

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

    • تم تعيين شبكة Cisco العامة ولكن غير القابلة للتوجيه عبر الإنترنت من الفئة C (/24) لمعالجة Dedicated Instance Cloud

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

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

نموذج النشر

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

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

يعرض الشكل 1 مثالًا على نموذج نشر Virtual Connect لخيار 2-concentrator على جانب العميل.

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

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

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

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

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

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

التوجيه

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

  • تحتفظ Cisco وتعيينها

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

    • عنوان إنهاء خدمة نقل النفق (من جانب Cisco)

    • أرقام نظام الحكم الذاتي الخاص (ASNs) لتكوين توجيه 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 قابل للاستجابة لإعادة توزيع المسارات المكتسبة داخل شبكة المؤسسة الخاصة بـ cutomer، حسب الطلب.

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

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

تصف الخطوات التالية عالية المستوى كيفية إنشاء الاتصال مع الاتصال الظاهري للمثيل المخصص.
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

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

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

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

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

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

    يمكن أن يكون عنوان 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 الثانية. أولاً، قم بإصدار الأمر "إظهار التشفير ikev2 sa" (على معدات Cisco) أو أمر مماثل على معدات الطرف الثالث للتحقق مما إذا كانت جلسة IKEv2 نشطة أم لا. إذا كانت جلسة IKEv2 غير نشطة، يمكن أن تكون الأسباب المحتملة:

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

  • تمت إساءة تكوين قائمة الوصول إلى نفق IPsec.

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

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

  • يقوم جدار الحماية بحجب حزم IKEv2 UDP.

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

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

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

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

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

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

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

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

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

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

    • تصريح 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، فسيتم إخطار Cisco لأن keepalives GRE سيتم تمكينها على جانب المثيل المخصص بشكل افتراضي.

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

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

  • تذكارات GRE من واجهة نفق GRE الجانبي CPE إلى واجهة نفق GRE الجانبي للمثيل المخصص.

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

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

    لا يمكن أن يكون بينغ نقل النفق IP لنقل النفق IP، يجب أن يكون النفق IP إلى النفق IP.

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

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

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

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

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

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

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

    إذا كانت التذكيرات غير مدعومة على معدات CPE، فيجب إخطار Cisco حتى يتم تعطيل التذكيرات الافتراضية الموجودة على جانب المثيل المخصص كذلك.

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

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

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

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

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

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

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

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

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

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

جلسات BGP

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

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

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

  • لا يتطابق رقم 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 مسار مركز البيانات 25 لإرسال حركة المرور إلى مركز البيانات B، وسيستخدم النفق إلى مركز البيانات B طريق النسخ الاحتياطي /24 لإرسال حركة المرور إلى مركز البيانات A عبر مركز البيانات B.

من المهم، عندما يكون كلا النفقين نشطين، ألا يستخدم مركز البيانات A نفق لإرسال حركة المرور إلى مركز البيانات B والعكس بالعكس. في هذا السيناريو، إذا تم إرسال حركة المرور إلى مركز البيانات A مع وجهة مركز البيانات B، فإن مركز البيانات A سيقوم بإعادة حركة المرور إلى مركز البيانات B ومن ثم سيحاول مركز البيانات B إرسال حركة المرور إلى المصدر عبر نفق مركز البيانات 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" أو الأمر المكافئ وكذلك "مسار النفق\u0002mtu-discovery" أو الأمر المكافئ على جانب العميل للمساعدة في الضبط الديناميكي لحركة المرور عبر نفق VPN.