- الرئيسية
- /
- المقال
شكرًا على ملاحظاتك.
مثيل مخصص - اتصال افتراضي
في هذه المقالة
هل لديك ملاحظات؟Virtual Connect هو خيار إضافي للاتصال السحابي بمثيل Webex Calling المخصص. يتيح Virtual Connect للعملاء توسيع شبكتهم الخاصة بأمان عبر الإنترنت باستخدام أنفاق IP VPN من نقطة إلى نقطة. نناقش هنا الطلب والتنشيط والتكوين لـ Virtual Connect.
مقدمة
Virtual Connect هو خيار إضافي للاتصال السحابي بالمثيل المخصص لـ Webex Calling (مثيل مخصص). يتيح Virtual Connect للعملاء توسيع شبكتهم الخاصة بأمان عبر الإنترنت باستخدام أنفاق IP VPN من نقطة إلى نقطة. يوفر خيار الاتصال هذا تأسيسًا سريعًا للاتصال بالشبكة الخاصة باستخدام معدات مقر العميل الحالية (CPE) والاتصال بالإنترنت.
تستضيف Cisco وتدير وتضمن أنفاق IP VPN المتكررة والوصول المطلوب إلى الإنترنت في منطقة (مناطق) مركز بيانات المثيل المخصص من Cisco حيث تكون الخدمة مطلوبة. وبالمثل، فإن المسؤول مسؤول عن خدمات CPE والإنترنت المقابلة المطلوبة لإنشاء Virtual Connect.
سيتضمن كل طلب اتصال افتراضي في منطقة مثيل مخصص معينة نفقين لتضمين التوجيه العام (GRE) محميين بتشفير IPsec (GRE عبر IPsec)، أحدهما لكل مركز بيانات Cisco في المنطقة المحددة.
يبلغ الحد الأقصى لعرض النطاق الترددي لـ Virtual Connect 250 ميجابت في الثانية لكل نفق ويوصى به لعمليات النشر الأصغر. نظرًا لاستخدام نفقي VPN من نقطة إلى نقطة، يجب أن تمر جميع حركة المرور إلى السحابة عبر عنوان CPE الخاص بالعميل، وبالتالي قد لا تكون مناسبة في حالة وجود الكثير من المواقع البعيدة. للحصول على خيارات نظير بديلة أخرى، راجع الاتصال السحابي.
قبل إرسال طلب النظير لـ Virtual Connect، تأكد من تنشيط خدمة المثيل المخصص في تلك المنطقة المعنية.
المتطلبات الأساسية
تتضمن المتطلبات الأساسية لإنشاء 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 بواسطة جهاز آخر.
عند الانتهاء من اتصال Virtual Connect، سيتم إنشاء نفقين GRE عبر IPsec بين شبكة مؤسسة العميل ومراكز بيانات Cisco للمثيل المخصص. واحد لكل مركز بيانات متكرر داخل المنطقة المعنية. يقوم الشريك أو العميل بتبادل عناصر الشبكة الإضافية المطلوبة للنظير إلى Cisco عبر نموذج تنشيط Control Hub Virtual Connect.
يوضح الشكل أدناه مثال نموذج نشر الاتصال الافتراضي لخيار 2-concentator من جانب العميل.
Virtual Connect - VPN هو تصميم محوري، حيث يتم توصيل مواقع مركز العميل بـ DC1 و DC2 لمراكز بيانات المثيل المخصص داخل منطقة معينة.
يوصى باستخدام موقعي Hub لتحسين التكرار، ولكن موقع One Hub الذي يحتوي على نفقين هو أيضًا نموذج نشر مدعوم.
يقتصر عرض النطاق الترددي لكل نفق على 250 ميجابت في الثانية. ولضمان تجاوز الأعطال بشكل فعال، يجب ألا تتجاوز حركة المرور المجمعة عبر كلا النفقين 250 ميجابت في الثانية، حيث سيتم توجيه كل حركة المرور عبر نفق واحد في حالة حدوث عطل.
وستحتاج المواقع البعيدة الخاصة بالعميل في نفس المنطقة إلى الاتصال مرة أخرى بموقع (مواقع) المحور عبر شبكة WAN الخاصة بالعميل ولا تتحمل Cisco مسؤولية هذا الاتصال.
من المتوقع أن يعمل الشركاء عن كثب مع العملاء، مما يضمن اختيار المسار الأمثل لمنطقة خدمة Virtual Connect.
يوضح الشكل أدناه المناطق النظيرة للاتصال السحابي للمثيل المخصص.
التوجيه
يتم تنفيذ إضافة التوجيه لـ 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 مسؤولة عن إعادة توزيع المسارات المكتسبة داخل شبكة مؤسسة العميل، حسب الحاجة.
-
-
في حالة فشل الارتباط غير الفاشل، سيحتوي CPE الفردي على نفقين نشطين/نشطين. بالنسبة لعقدتي CPE، سيكون لكل CPE نفق نشط واحد ويجب أن تكون كلتا عقدتي CPE نشطة وعابرة لحركة المرور. في ظل سيناريو عدم الفشل، يجب تقسيم حركة المرور إلى نفقين متجهين إلى الوجهتين الصحيحتين /25، وفي حالة تعطل أحد النفق، يمكن للنفق المتبقي نقل حركة المرور لكليهما. في ظل سيناريو الفشل هذا، عندما تكون الشبكة /25 معطلة، يتم استخدام شبكة /24 كمسار احتياطي. سترسل Cisco حركة مرور العملاء عبر شبكة WAN الداخلية الخاصة بها نحو DC الذي فقد الاتصال.
تدفق حركة مرور الاتصال الافتراضي
تدفق حركة المرور عند تشغيل كلا النفقين
توضح هذه الصورة بنية شبكة Virtual Connect، وتوضح بالتفصيل تدفق حركة المرور عند تشغيل كل من الأنفاق الأساسية والثانوية.
وهو يمثل نموذج اتصال نشط للعميل للوصول إلى تطبيقات UC المستضافة في مراكز بيانات Cisco، مع الاستفادة من أنفاق GRE/IPSEC المزدوجة عبر الإنترنت مع BGP لتبادل المسارات.
تعريفات:
- فرضية العميل:
- يمثل هذا شبكة العميل في الموقع، حيث يوجد المستخدمون وأجهزتهم (مثل هواتف IP وأجهزة الكمبيوتر التي تعمل بعملاء UC).
- يجب أن تصل حركة المرور الناشئة من هنا إلى تطبيقات UC المستضافة في مراكز بيانات Cisco.
- Cisco Webex Callingمراكز بيانات المثيل المخصص (المثيل المخصص) (WxC-di
DC-A وWxC-di DC-B):
- هذه هي مراكز بيانات Cisco التي تستضيف تطبيقات UC.
- تتميز DC-A و DC-B جغرافيًا، مما يوفر التكرار.
- يحتوي كل مركز بيانات على شبكة فرعية خاصة به لتطبيقات UC:
- الشبكة الفرعية DC-A: X.X.X.0/25
- الشبكة الفرعية DC-B: X.X.X.128/25
- أنفاق GRE/IPsec (النفق 1 والنفق 2):
- هذه هي الاتصالات الآمنة والمشفرة بين مقر العميل ومركز بيانات Cisco عبر الإنترنت العام.
- GRE (تضمين التوجيه العام): يُستخدم هذا البروتوكول لتغليف بروتوكولات طبقة الشبكة المختلفة داخل الارتباطات الافتراضية من نقطة إلى نقطة. وهو يسمح لبروتوكولات التوجيه مثل BGP بالعمل عبر النفق.
- IPsec (أمان بروتوكول الإنترنت): توفر مجموعة البروتوكولات هذه خدمات أمان التشفير (المصادقة والتكامل والسرية) لاتصالات IP. يقوم بتشفير حركة المرور المغلفة بـ GREE، مما يضمن النقل الآمن للبيانات عبر الإنترنت.
- بروتوكول بوابة الحدود (BGP):
- BGP هو بروتوكول التوجيه المستخدم لتبادل معلومات التوجيه بين مقر العميل ومراكز بيانات Cisco.
كما هو موضح في الرسم البياني أعلاه، تحتاج الأجهزة المنتشرة في أماكن العملاء إلى إنشاء نفقين GRE/IPSEC.
تعد اصطلاحات التسمية المستخدمة أدناه مع XX/YY و DC-A DC-B عامة لجميع المناطق التي يتم فيها تقديم مثيل مخصص. ستكون هذه القيم فريدة لكل منطقة والقيم الفعلية لكل منطقة. يتم توفير القيم المحددة أثناء تنشيط الاتصال الافتراضي.
على جانب Cisco، سيتم إنهاء أنفاق IPsec وGRE على أجهزة مختلفة. لذلك يجب على العميل التأكد من تكوين وجهة IPsec وعناوين IP لوجهة GRE على الأجهزة وفقًا لذلك. يمكن للعملاء استخدام نفس IP لـ GRE و IPSEC إذا كان مدعومًا على أجهزتهم. راجع الرسم البياني أعلاه. يتم توفير القيم المتعلقة بـ IP أثناء تنشيط الاتصال الافتراضي على البوابة الإلكترونية.
- النفق 1: يربط مقر العميل بـ «المثيل المخصص DC-A» (مركز البيانات A) عبر الإنترنت. يستخدم هذا النفق BGP AS:64XX1 على جانب العميل و BGP AS:64XX2 على جانب المثيل المخصص DC-A . يتم تقسيم تكوينات مصدر النفق IPSEC وGRE بين التفاصيل المقدمة من العميل والتفاصيل التي توفرها Cisco.
- النفق 2: يربط مقر العميل بـ «المثيل المخصص DC-B» (مركز البيانات B) عبر الإنترنت. يستخدم هذا النفق BGP AS:64YY1 على جانب العميل و BGP AS:64YY2 على جانب المثيل المخصص DC-B. وكما هو الحال مع Tunnel 1، تتم مشاركة تكوينات مصدر النفق IPSEC وGRE بين العميل وشركة Cisco.
في BGP AS:64XX و BGP AS:64YY، تكون XX و YY خاصة بمنطقة معينة.
بمجرد إنشاء أنفاق GRE/IPSEC لمراكز بيانات المثيل Webex Calling المخصص (A و B)، يجب أن يتلقى العميل المسارات التالية المعلن عنها من Cisco عبر جلسات BGP المقابلة .
- بالنسبة إلى DC-A: ستكون المسارات المُعلن عنها من Cisco هي X.X.0/25 وX.X.X.0/24. اختياريًا، إذا تم طلب IaaS وتكوينه للعميل، فسيتم الإعلان عن مسارات Y.Y.Y.0/25 وY.Y.Y.0/24 من Cisco.
- بالنسبة إلى DC-B: ستكون المسارات المُعلن عنها من Cisco هي X.X.128/25 وX.X.X.0/24. اختياريًا، إذا تم طلب IaaS وتكوينه للعملاء، فسيتم الإعلان عن مسارات Y.Y.Y.128/25 وY.Y.Y.0/24 من Cisco.
- يحتاج العميل إلى الإعلان عن المسار 0.0.0./0 إلى Cisco من خلال كل من الاتصالات (الأنفاق)
- يجب على العميل اتباع أطول مسارات البادئة (/25) لإرسال حركة المرور إلى Cisco من خلال الأنفاق المعنية عند تشغيل كلا النفقين.
- ستعيد Cisco حركة المرور من خلال نفس الأنفاق للحفاظ على حركة المرور متماثلة.
تدفق حركة المرور:
- تتدفق حركة المرور الموجهة إلى «تطبيقات DC-A UC» (X.X.X.0/25) من مقر العميل عبر النفق 1.
- تتدفق حركة المرور الموجهة إلى «تطبيقات DC-B UC» (X.X.X.128/25) من مقر العميل عبر النفق 2.
سيناريو الفشل: تدفق حركة المرور عندما يكون أحد الأنفاق معطلاً
كما هو موضح في الرسم البياني أعلاه عندما يكون النفق المؤدي إلى DC-A في الأسفل، سينخفض bgp الذي تم إنشاؤه من خلال النفق إلى DC-A.
التأثير على BGP: عندما ينخفض النفق 1، ستنخفض جلسة BGP فوق هذا النفق أيضًا . وبالتالي، لن تتمكن DC-A من الإعلان عن مساراتها (على وجه التحديد X.X.0/25) للعميل عبر هذا المسار. ومن ثم سيكتشف جهاز توجيه العميل المسار على أنه لا يمكن الوصول إليه.
الآن نظرًا لتعطل النفق 1، سيقوم جهاز توجيه العميل في مقر العميل تلقائيًا بإزالة المسارات التي تم التعرف عليها عبر النفق 1 من جدول التوجيه الخاص به أو وضع علامة عليها على أنها لا يمكن الوصول إليها.
- سيتم بعد ذلك إعادة توجيه حركة المرور الموجهة إلى شبكة تطبيقات UC (X.X.X.0/24) أو الشبكة الفرعية DC-A (X.X.0/25) من خلال نفق العمل باتجاه DC-B الذي يستمر في الإعلان عن X.X.X.0/24 الذي يتضمن شبكة X.X.X.0/25.
- سيظهر سلوك مماثل إذا كان النفق إلى DC-B معطلاً بينما لا يزال النفق إلى DC-A مرتفعًا.
عملية الاتصال
| 1 | |
| 2 | |
| 3 | |
| 4 |
الخطوة 1: طلب CCW
Virtual Connect هي إضافة لمثيل مخصص في CCW.
| 1 |
انتقل إلى موقع طلب CCW ثم انقر فوق تسجيل الدخول لتسجيل الدخول إلى الموقع: |
| 2 |
إنشاء تقدير. |
| 3 |
أضف رمز SKU «A-FLEX-3". |
| 4 |
حدد خيارات التحرير. |
| 5 |
في علامة تبويب الاشتراك التي تظهر، حدد الخيارات والإضافات. |
| 6 |
ضمن الإضافات الإضافية، حدد مربع الاختيار بجانب «الاتصال الافتراضي للمثيل المخصص». اسم وحدة التخزين (SKU) هو «A-FLEX-DI-VC». |
| 7 |
أدخل كمية وعدد المناطق التي يلزم فيها الاتصال الافتراضي. يجب ألا تتجاوز كمية Virtual Connect العدد الإجمالي للمناطق المشتراة للمثيل المخصص. أيضًا، يُسمح بطلب Virtual Connect واحد فقط لكل منطقة. |
| 8 |
عندما تكون راضيًا عن اختياراتك، انقر فوق التحقق والحفظ في الجزء العلوي الأيمن من الصفحة. |
| 9 |
انقر فوق «حفظ» و «متابعة» لإنهاء طلبك. يظهر طلبك النهائي الآن في شبكة الطلبات. |
الخطوة 2: تنشيط الاتصال الافتراضي في Control Hub
| 1 |
قم بتسجيل الدخول إلى مركز التحكم https://admin.webex.com/login. |
| 2 |
في قسم الخدمات، انتقل إلى الاتصال > المثيل المخصص > الاتصال السحابي. |
| 3 |
في بطاقة Virtual Connect، يتم إدراج كمية Virtual Connect المشتراة. يمكن للمسؤول الآن النقر فوق التنشيط لبدء تنشيط Virtual Connect. 
لا يمكن تشغيل عملية التنشيط إلا من قبل المسؤولين الذين لديهم دور «المسؤول الكامل للعميل». بينما يمكن للمسؤول الذي لديه دور «المشرف للقراءة فقط للعميل» عرض الحالة فقط. |
| 4 |
عند النقر فوق زر التنشيط، يتم عرض نموذج تنشيط الاتصال الافتراضي للمسؤول لتقديم التفاصيل الفنية لـ Virtual Connect المطلوبة للتكوينات النظيرة من جانب Cisco. يوفر النموذج أيضًا معلومات ثابتة من جانب Cisco، استنادًا إلى المنطقة المحددة. ستكون هذه المعلومات مفيدة لمسؤولي العملاء لتكوين CPE من جانبهم لإنشاء الاتصال. |
| 5 |
انقر على زر التنشيط بمجرد ملء جميع الحقول الإلزامية. |
| 6 |
بعد إكمال نموذج تنشيط الاتصال الافتراضي لمنطقة معينة، يمكن للعميل تصدير نموذج التنشيط من Control Hub، والاتصال > المثيل المخصص > علامة تبويب الاتصال السحابي والنقر على إعدادات التصدير. 
نظرًا لأسباب أمنية، لن تتوفر المصادقة وكلمة مرور BGP في المستند الذي تم تصديره، ولكن يمكن للمسؤول عرضها في Control Hub بالنقر فوق عرض الإعدادات ضمن مركز التحكم، والاتصال > مثيل مخصص > علامة تبويب الاتصال السحابي. |
الخطوة 3: تقوم Cisco بتكوين الشبكة
| 1 |
بمجرد اكتمال نموذج تنشيط الاتصال الافتراضي، سيتم تحديث الحالة إلى التنشيط قيد التقدم في الاتصال > المثيل المخصص > بطاقة الاتصال الافتراضي للاتصال السحابي. |
| 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.
-
تحقق من إعداد مدى الحياة.
-
تحقق من مجموعة معامل ديفي هيلمان.
-
تحقق من إعدادات الوظيفة العشوائية الزائفة.
-
-
لم يتم تعيين قائمة الوصول لخريطة التشفير إلى:
-
تصريح GRE (بروتوكول النقل النفقي المحلي) 255.255.255.255 (بروتوكول النقل عبر النفق عن بُعد) 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 الجانبية للمثيل المخصص.
-
جلسة TCP المجاورة لـ BGP من جار BGP من جانب CPE إلى جار BGP من جانب المثيل المخصص.
-
استخدم الأمر 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 المحلي إلى عنوان 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 مع جانب المثيل المخصص، أعد التحقق من الإعدادات:
-
تحقق من تطابق معاملات التشفير والمصادقة مع الإعدادات الموجودة على جانب المثيل المخصص.
-
تحقق من إعدادات Perfect Forward Secrecy ومن إعدادات المطابقة على جانب المثيل المخصص.
-
تحقق من إعدادات مدى الحياة.
-
تحقق من تكوين IPsec في وضع النفق.
-
تحقق من عناوين IPsec للمصدر والوجهة.
استكشاف أخطاء واجهة النفق وإصلاحها والتحقق من صحتها
عندما يتم التحقق من أن جلسات IPsec وIKEv2 نشطة، فإن حزم نفق GRE تبقى حية وقادرة على التدفق بين المثيل المخصص ونقاط نهاية نفق CPE. إذا كانت واجهة النفق لا تظهر الحالة، فإن بعض المشكلات الشائعة هي:
-
لا يتطابق VRF الخاص بنقل واجهة النفق مع VRF لواجهة الاسترجاع (في حالة استخدام تكوين VRF على واجهة النفق).
إذا لم يتم استخدام تكوين VRF على واجهة النفق، فيمكن تجاهل هذا الفحص.
-
لم يتم تمكين Keepalives على واجهة النفق الجانبي لـ CPE
في حالة عدم دعم عمليات حفظ البيانات على أجهزة CPE، يجب إخطار Cisco حتى يتم تعطيل عمليات الحفظ الافتراضية على جانب المثيل المخصص أيضًا.
في حالة دعم keepalives، تحقق من تمكين Keepalives.
-
القناع أو عنوان 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 وتم التحقق من العناصر السابقة، فقد يلزم التقاط الحزمة للتأكد من أن icmp ping ينتج عنه حزمة 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 والعكس صحيح. في هذا السيناريو، إذا تم إرسال حركة المرور إلى مركز البيانات 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» أو الأمر المكافئ من جانب العميل للمساعدة في الضبط الديناميكي لوحدة MTU لحركة المرور عبر نفق VPN.
