مقدمة

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

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

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

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

قبل إرسال طلب الاقتران لـ Virtual Connect، تأكد من تنشيط خدمة Dedicated Instance في تلك المنطقة المعنية.

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

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

  • يقدم العميل

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

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

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

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

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

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

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

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

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

  • Cisco

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

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

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

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

نموذج النشر

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

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

يوضح الشكل أدناه مثالاً لنموذج نشر الاتصال الافتراضي لخيار التركيز 2 على جانب العميل.

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

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

يقتصر النطاق الترددي لكل نفق على 250 ميجابايت في الثانية. ولضمان الفشل الفعال، يجب ألا يتجاوز إجمالي حركة المرور عبر النفقين 250 ميجابايت في الثانية، حيث سيتم توجيه كل حركة المرور عبر نفق واحد في حالة حدوث فشل.

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

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

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

مناطق الاتصال الافتراضية

التوجيه

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

  • تحافظ شركة سيسكو على وتخصص

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

    • عنوان وجهة نقل النفق (جانب شركة سيسكو)

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

      • تقوم شركة Cisco بالتعيين من نطاق الاستخدام الخاص المخصص: 64512 إلى 65534

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

    • سوف تقوم شركة سيسكو بتقسيم المخصص /24 شبكة إلى 2 /25 واحد لكل مركز بيانات في المنطقة المعنية

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

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

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

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

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

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

تدفق حركة المرور في الاتصال الافتراضي

تدفق حركة المرور عند فتح كلا النفقين

مثيل مخصص - اتصال افتراضي

توضح هذه الصورة بنية شبكة Virtual Connect ، وتوضح تدفق حركة المرور عندما تكون الأنفاق الأساسية والثانوية قيد التشغيل.

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

التعاريف:

  • فرضية العميل:
    • يمثل هذا شبكة العميل الموجودة في الموقع، حيث يتواجد المستخدمون وأجهزتهم (على سبيل المثال، هواتف IP وأجهزة الكمبيوتر التي تعمل بنظام عملاء UC).
    • يجب أن تصل حركة المرور القادمة من هنا إلى تطبيقات الاتصالات الموحدة المستضافة في مراكز بيانات Cisco.
  • مراكز بيانات Cisco Webex Calling Dedicated Instance (المثيل المخصص) (WxC-DI DC-A وWxC-DI DC-B):
    • هذه هي مراكز البيانات التابعة لشركة Cisco التي تستضيف تطبيقات الاتصالات الموحدة.
    • DC-A و DC-B متميزان جغرافيًا، مما يوفر التكرار.
    • يحتوي كل مركز بيانات على شبكة فرعية خاصة به لتطبيقات الاتصالات الموحدة:
      • دي سي-أ subnet:X.X.X.0/25
      • دي سي-بي subnet:X.X.X.128/25
  • GRE/IPsec الأنفاق (النفق 1 والنفق 2):
    • هذه هي الاتصالات الآمنة والمشفرة بين مقر العميل و مركز بيانات Cisco عبر شبكة الإنترنت العامة.
    • GRE (تغليف التوجيه العام): يتم استخدام هذا البروتوكول لتغليف بروتوكولات طبقة الشبكة المختلفة داخل روابط نقطة إلى نقطة افتراضية. إنه يسمح لبروتوكولات التوجيه مثل BGP بالعمل عبر النفق.
    • IPsec (أمان بروتوكول الإنترنت): توفر مجموعة البروتوكولات هذه خدمات الأمان التشفيرية (المصادقة والنزاهة والسرية) لاتصالات IP. يقوم بتشفير حركة المرور المغلفة بـ GRE، مما يضمن نقل البيانات بشكل آمن عبر الإنترنت.
  • بروتوكول بوابة الحدود (BGP):
    • BGP هو بروتوكول التوجيه المستخدم لتبادل معلومات التوجيه بين مقر العميل و مراكز بيانات Cisco.

كما هو موضح في الرسم التخطيطي أعلاه، تحتاج الأجهزة المنتشرة في مقر العميل إلى إنشاء اثنين GRE/IPSEC الأنفاق.

اتفاقيات التسمية المستخدمة أدناه مع XX / YY وDC-A وDC-B هي نسخ عامة لجميع المناطق التي يتم فيها تقديم المثيل المخصص. ستكون هذه القيم فريدة لكل منطقة والقيم الفعلية لكل منطقة. يتم توفير القيم المحددة أثناء تنشيط الاتصال الافتراضي.

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

  • نفق 1: يقوم بربط مقر العميل بـ "المثيل المخصص DC-A" (مركز البيانات A) عبر الإنترنت. يستخدم هذا النفق BGP AS:64XX1 على جانب العميل وBGP AS:64XX2 على جانب DC-A للمثيل المخصص. يتم تقسيم تكوينات مصدر نفق IPSEC وGRE بين التفاصيل التي يوفرها العميل والتفاصيل التي توفرها Cisco.
  • نفق 2: يقوم بربط مقر العميل بـ "مركز البيانات B المخصص DC-B" عبر الإنترنت. يستخدم هذا النفق BGP AS:64YY1 على جانب العميل وBGP AS:64YY2 على جانب DC-B للمثيل المخصص. مثل النفق 1، يتم مشاركة تكوينات مصدر نفق IPSEC وGRE بين العميل وشركة Cisco.

في BGP AS:64XX و BGP AS:64YY, XX و YY خاصان بمنطقة معينة.

بمجرد GRE/IPSEC يتم إنشاء الأنفاق لمراكز بيانات Webex Calling Dedicated Instance (A وB)، ويجب أن يتلقى العميل المسارات التالية المعلن عنها من Cisco عبر جلسات BGP المقابلة.

  • بالنسبة لـ DC-A: سيتم الإعلان عن المسارات من شركة سيسكو X.X.X.0/25 و X.X.x.0/24. اختياريًا إذا تم طلب IaaS وتكوينه لمسارات العميل Y.Y.Y.0/25 و Y.Y.Y.0/24 سيتم الإعلان عنها من شركة سيسكو.
  • بالنسبة لـ DC-B: سيتم الإعلان عن المسارات من شركة سيسكو X.X.X.128/25 و X.X.x.0/24. اختياريًا إذا تم طلب IaaS وتكوينه لمسارات العميل Y.Y.Y.128/25 و Y.Y.Y.0/24 سيتم الإعلان عنها من شركة سيسكو.
  • يحتاج العميل إلى الإعلان عن 0.0.0./0 الطريق إلى سيسكو من خلال كلا الاتصالين (الأنفاق)
  • يجب على العميل اتباع أطول بادئة (/25) المسارات لإرسال حركة المرور إلى شركة Cisco عبر الأنفاق المعنية عندما يكون كلا النفقين قيد التشغيل.
  • ستقوم شركة Cisco بإعادة حركة المرور عبر نفس الأنفاق للحفاظ على حركة المرور متماثلة.

تدفق حركة المرور:

  • حركة المرور المتجهة إلى "تطبيقات DC-A UC" (X.X.X.0/25) من موقع العميل يتدفق عبر النفق 1.
  • حركة المرور المتجهة إلى "تطبيقات DC-B UC" (X.X.X.128/25) من موقع العميل يتدفق عبر النفق 2.

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

مثيل مخصص - اتصال افتراضي

كما هو موضح في الرسم التخطيطي أعلاه، عندما يكون النفق إلى DC-A لأسفل، فإن نقطة الوصول الحدودية التي تم إنشاؤها من خلال النفق إلى DC-A سوف تنخفض.

التأثير على BGP: عندما ينخفض النفق 1، فسوف تنخفض أيضًا جلسة BGP عبر هذا النفق. وبالتالي، لن تتمكن DC-A بعد الآن من الإعلان عن مساراتها (على وجه التحديد X.X.X.0/25) إلى العميل عبر هذا المسار. ومن ثم، سوف يكتشف جهاز توجيه العميل أن المسار غير قابل للوصول.

الآن، بما أن النفق 1 معطل، فإن جهاز توجيه العميل في مقر العميل سوف يقوم تلقائيًا بإزالة المسارات التي تم تعلمها عبر النفق 1 من جدول التوجيه الخاص به أو وضع علامة عليها على أنها غير قابلة للوصول.

  • حركة المرور المتجهة إلى شبكة تطبيقات UC (X.X.X.0/24) أو الشبكة الفرعية DC-A (X.X.X.0/25) سيتم بعد ذلك إعادة توجيهها عبر النفق العامل نحو DC-B الذي يستمر في الإعلان عن X.X.X.0/24 وهذا يشمل X.X.X.0/25 شبكة.
  • سيتم رؤية سلوك مماثل إذا كان النفق إلى DC-B معطلاً بينما النفق إلى DC-A لا يزال مرتفعًا.

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

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

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

2

تنشيط الاتصال الافتراضي من مركز التحكم

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

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

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

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

9

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

الخطوة 2: تفعيل الاتصال الافتراضي في مركز التحكم

1

تسجيل الدخول إلى مركز التحكم https://admin.webex.com/login.

2

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

3

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

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

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

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

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

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

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

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

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

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

6

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

لأسباب أمنية، لن تكون المصادقة وكلمة مرور BGP متاحة في المستند المُصدَّر، ولكن يمكن للمسؤول عرضها في مركز التحكم بالنقر فوق إعدادات العرض ضمن مركز التحكم، الاتصال > مثيل مخصص > علامة التبويب "الاتصال السحابي".

الخطوة 3: تقوم شركة Cisco بإجراء تكوين الشبكة

1

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

2

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

الخطوة 4: يقوم العميل بإجراء تكوين الشبكة

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

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

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

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

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

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

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

  • جلسة TCP لجار BGP من جار BGP على جانب CPE إلى جار BGP على جانب Dedicated Instance.

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

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

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

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

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

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

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

استكشاف أخطاء المرحلة الثانية من 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 لا تتطابق مع جانب المثيل المخصص، أعد التحقق من الإعدادات:

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

  • تحقق من إعدادات Perfect Forward Secrecy وتأكد من تطابق الإعدادات على جانب Dedicated Instance.

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

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

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

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

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

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

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

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

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

    إذا تم دعم خاصية الاحتفاظ بالبيانات، فتأكد من تمكين خاصية الاحتفاظ بالبيانات.

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

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

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

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

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

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

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

بالإضافة إلى حركة مرور ping، يجب أن يعرض الالتقاط أيضًا حزم 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 المحلي مع ما يتوقعه جانب Dedictaed Instance، تأكد من أن رقم AS المحلي يتطابق مع معلمات Dedictaed Instance المتوقعة.

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

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

تبادل مسارات BGP

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

يتوقع حل VPN المخصص إنشاء نفقين من customer/partner جانب. يشير النفق الأول إلى مركز بيانات المثيل المخصص A ويشير النفق الثاني إلى مركز بيانات المثيل المخصص B. يجب أن يكون كلا النفقين في حالة نشطة ويتطلب الحل active/active النشر. سوف يعلن كل مركز بيانات مخصص عن مكانه المحلي /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، فسوف يقوم مركز البيانات A بإعادة توجيه حركة المرور إلى مركز البيانات B ثم يحاول مركز البيانات B إرسال حركة المرور مرة أخرى إلى المصدر عبر نفق مركز البيانات B. سيؤدي هذا إلى توجيه غير مثالي وقد يؤدي أيضًا إلى كسر حركة المرور عبر جدران الحماية. لذلك، من المهم أن يكون كلا النفقين في مكان واحد. active/active التكوين أثناء التشغيل العادي.

ال 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.