يستخدم 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 الذي فقد الاتصال.

يتضمن التفاوض نفق 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 (أي جمعية أمان 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.

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

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