الترحيل إلى Azure Virtual WAN

يتيح Azure Virtual WAN للشركات تبسيط اتصالها العالمي من أجل الاستفادة من نطاق شبكة Microsoft العالمية. توفر هذه المقالة تفاصيل فنية للشركات التي ترغب في الترحيل من طوبولوجيا مركزية وتحدثية مدارة من قبل العميل، إلى تصميم يستفيد من مراكز Virtual WAN التي تديرها Microsoft.

للحصول على معلومات حول المزايا التي تتيحها شبكة Azure Virtual WAN للمؤسسات التي تعتمد شبكة عالمية حديثة تركز على السحابة، راجع بنية شبكة النقل العام و Virtual WAN.

Figure: Azure Virtual WAN

تم اعتماد نموذج اتصال Azure hub-and-spoke من قبل الآلاف من عملائنا للاستفادة من سلوك التوجيه الانتقالي الافتراضي لـAzure Networking من أجل إنشاء شبكات سحابية بسيطة وقابلة للتطوير. تعتمد Azure Virtual WAN على هذه المفاهيم وتقدم قدرات جديدة تسمح بطوبولوجيا الاتصال العالمي، ليس فقط بين المواقع المحلية وAzure، ولكن أيضًا تسمح للعملاء بالاستفادة من نطاق شبكة Microsoft لزيادة شبكاتهم العالمية الحالية.

توضح هذه المقالة كيفية ترحيل بيئة مركز وتحدث مدارة من قبل العميل، إلى مخطط يستند إلى Azure Virtual WAN.

السيناريو

شركة Contoso هي منظمة مالية عالمية لها مكاتب في كل من أوروبا وآسيا. ويخططون لنقل تطبيقاتهم الحالية من مركز بيانات محلي إلى Azure وقد قاموا ببناء تصميم أساسي يستند إلى بنية النظام المحوري المدارة من قبل العملاء، بما في ذلك الشبكات الظاهرية للمحور الإقليمي للاتصال المختلط. كجزء من الانتقال إلى التقنيات المستندة إلى السحابة، تم تكليف فريق الشبكة بضمان تحسين اتصالها للأعمال للمضي قدما.

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

Figure: Contoso existing network topology

يمكن فهم النقاط التالية من مخطط الشبكة الحالي:

• يتم استخدام تخطيط الشبكة المحورية في مناطق متعددة بما في ذلك دوائر ExpressRoute للاتصال مرة أخرى بشبكة واسعة النطاق (WAN) خاصة مشتركة.

• تحتوي بعض هذه المواقع أيضًا على أنفاق VPN مباشرة في Azure للوصول إلى التطبيقات المستضافة داخل السحابة.

المتطلبات

تم تكليف فريق الشبكات بتقديم نموذج شبكة عالمي يمكنه دعم ترحيل Contoso إلى السحابة ويجب تحسينه في مجالات التكلفة والحجم والأداء. باختصار، يجب استيفاء المتطلبات التالية:

• تزويد كل من ربع رأس (HQ) والمكاتب الفرعية بمسار محسن للتطبيقات المستضافة على السحابة.
• إزالة الاعتماد على مراكز البيانات المحلية الحالية (DC) لإنهاء VPN مع الاحتفاظ بمسارات الاتصال التالية:
  • الفرع إلى VNet: يجب أن تكون المكاتب المتصلة بشبكة VPN قادرة على الوصول إلى التطبيقات التي تم ترحيلها إلى السحابة في منطقة Azure المحلية.
  • من فرع إلى مركز إلى Hub-to-VNet: يجب أن تكون المكاتب المتصلة بشبكة VPN قادرة على الوصول إلى التطبيقات التي تم ترحيلها إلى السحابة في منطقة Azure البعيدة.
  • فرع إلى فرع: يجب أن تكون المكاتب الإقليمية المتصلة بشبكة VPN قادرة على التواصل مع بعضها البعض ومواقع HQ/DC المتصلة بـExpressRoute.
  • من فرع إلى مركز إلى مركز إلى فرع: يجب أن تكون المكاتب المتصلة بشبكة VPN المنفصلة عالميًا قادرة على التواصل مع بعضها البعض وأي مواقع HQ/DC متصلة بـ ExpressRoute.
  • من فرع إلى إنترنت: يجب أن تكون المواقع المتصلة قادرة على الاتصال بالإنترنت. يجب تصفية نسبة استخدام الشبكة هذه وتسجيلها.
  • VNet-to-VNet: يجب أن تكون الشبكات الظاهرية المحورية في نفس المنطقة قادرة على الاتصال ببعضها البعض.
  • VNet-to-Hub إلى Hub-to-VNet: يجب أن تكون الشبكات الظاهرية المحورية في المناطق المختلفة قادرة على التواصل مع بعضها البعض.
• توفير القدرة لمستخدمي تجوال Contoso (الكمبيوتر المحمول والهاتف) للوصول إلى موارد الشركة أثناء عدم وجودهم على شبكة الشركة.

هندسة شبكة WAN الافتراضية

يظهر الشكل التالي طريقة عرض عالية المستوى لطوبولوجيا الهدف المحدثة باستخدام Azure Virtual WAN لتلبية المتطلبات المفصلة في القسم السابق.

Figure: Azure Virtual WAN architecture

الملخص:

• لا يزال HQ في أوروبا ExpressRoute متصلًا، ويتم ترحيل وحدة DC المحلية في أوروبا بالكامل إلى Azure ويتم إيقاف تشغيلها الآن.
• تظل آسيا DC وHQ متصلين بشبكة WAN الخاصة. تستخدم Azure Virtual WAN الآن لزيادة شبكة الناقل المحلي وتوفير الاتصال العالمي.
• تم نشر مراكز Azure Virtual WAN في كل من مناطق Azure في غرب أوروبا وجنوب شرق آسيا لتوفير مركز اتصال للأجهزة المتصلة بـExpressRoute وVPN.
• توفر المراكز أيضًا إنهاء VPN للمستخدمين المتنقلين عبر أنواع عملاء متعددة باستخدام اتصال OpenVPN بشبكة الشبكة العالمية، ما يسمح بالوصول ليس فقط إلى التطبيقات التي تم ترحيلها إلى Azure، ولكن أيضًا أي موارد متبقية في الموقع.
• الاتصال بالإنترنت للموارد داخل شبكة ظاهرية توفرها Azure Virtual WAN.

الاتصال بالإنترنت للمواقع البعيدة التي توفرها Azure Virtual WAN أيضًا. توزيع الإنترنت المحلي المدعوم عبر تكامل الشريك للوصول الأمثل إلى خدمات SaaS مثل Microsoft 365.

الترحيل إلى Virtual WAN

يوضح هذا القسم الخطوات المختلفة للترحيل إلى Azure Virtual WAN.

الخطوة 1: مركز أحادي المنطقة يديره العميل

يظهر الشكل التالي مخطط منطقة واحد لـ Contoso قبل طرح Azure Virtual WAN:

Figure 1: Single region manual hub-and-spoke

تماشيًا مع نهج النظام المحوري، تحتوي الشبكة الظاهرية المركزية المدارة من قبل العميل على العديد من كتل الوظائف:

• الخدمات المشتركة (أي وظيفة مشتركة مطلوبة من قبل العديد من المحاور). مثال: تستخدم Contoso وحدات تحكم مجال Windows Server على الأجهزة الظاهرية للبنية الأساسية كخدمة (IaaS).
• يتم توفير خدمات جدار حماية IP/التوجيه بواسطة جهاز ظاهري لشبكة خارجية، ما يتيح توجيه IP من طبقة إلى محور-3.
• خدمات الدخول/الخروج عبر الإنترنت بما في ذلك Azure Application Gateway لطلبات HTTPS الواردة وخدمات الوكيل التابعة لجهة خارجية التي تعمل على الأجهزة الظاهرية للوصول الصادر المصفاة إلى موارد الإنترنت.
• بوابة الشبكة الظاهرية ExpressRoute وVPN للاتصال بالشبكات المحلية.

الخطوة 2: نشر مراكز شبكة WAN الظاهرية

نشر مركز Virtual WAN في كل منطقة. قم بإعداد مركز Virtual WAN باستخدام وظائف VPN وExpressRoute كما هو موضح في المقالات التالية:

• البرنامج التعليمي: إنشاء اتصال من موقع إلى موقع باستخدام Azure Virtual WAN
• البرنامج التعليمي: إنشاء اقتران ExpressRoute باستخدام شبكة Azure Virtual WAN

ملاحظة

يجب أن تستخدم Azure Virtual WAN وحدة SKU القياسية لتمكين بعض مسارات نسبة استخدام الشبكة الموضحة في هذه المقالة.

Figure 2: Customer-managed hub-and-spoke to Virtual WAN migration

الخطوة 3: توصيل المواقع البعيدة (ExpressRoute وVPN) بشبكة Virtual WAN

قم بتوصيل مركز Virtual WAN بدوائر ExpressRoute الموجودة وإعداد شبكات VPN من موقع إلى موقع عبر الإنترنت إلى أي فروع بعيدة.

Figure 3: Customer-managed hub-and-spoke to Virtual WAN migration

عند هذه النقطة، ستبدأ معدات الشبكة المحلية في تلقي المسارات التي تعكس مساحة عنوان IP المعينة للشبكة الظاهرية المركزية المدارة بواسطة شبكة WAN الظاهرية. ستشاهد الفروع المتصلة بشبكة VPN البعيدة في هذه المرحلة مسارين إلى أي تطبيقات موجودة في الشبكات الظاهرية المحورية. يجب تكوين هذه الأجهزة لمتابعة استخدام النفق إلى المركز المدار من قبل العميل لضمان التوجيه المتماثل أثناء مرحلة الانتقال.

الخطوة 4: اختبار الاتصال المختلط عبر Virtual WAN

قبل استخدام مركز Virtual WAN المدار لاتصال الإنتاج، نوصي بإعداد شبكة ظاهرية محورية تجريبية واتصال الشبكة الظاهرية WAN الظاهرية. تحقق من أن الاتصالات ببيئة الاختبار هذه تعمل عبر ExpressRoute وSite to Site VPN قبل المتابعة مع الخطوات التالية.

Figure 4: Customer-managed hub-and-spoke to Virtual WAN migration

في هذه المرحلة، من المهم التعرف على أن كل من الشبكة الظاهرية الأصلية للمركز المدار من قبل العميل ومركز WAN الظاهري الجديد متصلان بنفس دائرة ExpressRoute. وبسبب ذلك، لدينا مسار نسبة استخدام الشبكة الذي يمكن استخدامه لتمكين المحاور في كلتا البيئتين من الاتصال. على سبيل المثال، ستجتاز نسبة استخدام الشبكة من محور متصل بالشبكة الظاهرية للمركز المدار من قبل العميل أجهزة MSEE المستخدمة لدائرة ExpressRoute للوصول إلى أي محور متصل عبر اتصال VNet بمركز Virtual WAN الجديد. يسمح هذا بالترحيل المرحلي للمتحدثين في الخطوة 5.

الخطوة 5: الاتصال الانتقالي إلى مركز WAN الظاهري

Figure 5: Customer-managed hub-and-spoke to Virtual WAN migration

أ. احذف اتصالات التناظر الموجودة من الشبكات الظاهرية Spoke إلى المركز القديم الذي يديره العميل. الوصول إلى التطبيقات في الشبكات الظاهرية المحورية غير متوفر حتى تكتمل الخطوات a-c.

ب. قم بتوصيل الشبكات الظاهرية المحورية بمركز Virtual WAN عبر اتصالات VNet.

ج. قم بإزالة أي مسارات معرفة من قبل المستخدم (UDR) كانت تستخدم سابقا داخل الشبكات الظاهرية المحورية للاتصالات بين المتحدثين. يتم تمكين هذا المسار الآن عن طريق التوجيه الديناميكي المتوفر داخل مركز Virtual WAN.

د. يتم الآن إيقاف تشغيل بوابات ExpressRoute وVPN الموجودة في المركز المدار من قبل العميل للسماح بالخطوة التالية (ه).

ه. قم بتوصيل المركز القديم المدار من قبل العميل (الشبكة الظاهرية المركزية) بمركز Virtual WAN عبر اتصال VNet جديد.

الخطوة 6: يصبح المركز القديم هو الخدمات المشتركة المحورية

لقد قمنا الآن بإعادة تصميم شبكة Azure لجعل مركز شبكة WAN الظاهرية النقطة المركزية في تخطيط الشبكة الجديد.

Figure 6: Customer-managed hub-and-spoke to Virtual WAN migration

نظرًا لأن مركز Virtual WAN هو كيان مدار ولا يسمح بنشر الموارد المخصصة مثل الأجهزة الظاهرية، فإن كتلة الخدمات المشتركة موجودة الآن كشبكة ظاهرية محورية وتستضيف وظائف مثل دخول الإنترنت عبر بوابة تطبيق Azure أو الجهاز الظاهري للشبكة. تنتقل نسبة استخدام الشبكة بين بيئة الخدمات المشتركة والأجهزة الظاهرية الخلفية الآن إلى المركز المدار بواسطة شبكة WAN الظاهرية.

الخطوة 7: تحسين الاتصال المحلي للاستفادة الكاملة من Virtual WAN

في هذه المرحلة، أكملت شركة Contoso في الغالب عمليات ترحيل تطبيقات الأعمال في Microsoft Cloud، مع وجود عدد قليل فقط من التطبيقات القديمة المتبقية داخل DC المحلي.

Figure 7: Customer-managed hub-and-spoke to Virtual WAN migration

للاستفادة من الوظائف الكاملة لـ Azure Virtual WAN، تقرر شركة Contoso إيقاف تشغيل اتصالات VPN المحلية القديمة الخاصة بها. أي فروع تستمر في الوصول إلى شبكات HQ أو DC قادرة على عبور شبكة Microsoft العمومية باستخدام توجيه النقل المضمن لـAzure Virtual WAN.

ملاحظة

ExpressRoute Global Reach مطلوب للعملاء الذين يرغبون في الاستفادة من العمود الفقري لـMicrosoft لتوفير ExpressRoute لعبور ExpressRoute (غير معروض الشكل 7.).

بنية الحالة النهائية ومسارات نسبة استخدام الشبكة

Figure: Dual region Virtual WAN

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

المسار 1

يعرض المسار 1 تدفق نسبة استخدام الشبكة من فرع متصل بشبكة S2S VPN في آسيا إلى Azure VNet في منطقة جنوب شرق آسيا.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يتم توصيل فرع آسيا عبر أنفاق مرنة تدعم S2S BGP في مركز شبكة WAN الظاهرية لجنوب شرق آسيا.

• يوجه مركز شبكة WAN الظاهرية في آسيا نسبة استخدام الشبكة محليًا إلى الشبكة الظاهرية المتصلة.

المسار 2

يظهر المسار 2 تدفق نسبة استخدام الشبكة من وحدة HQ الأوروبية المتصلة بـExpressRoute إلى Azure VNet في منطقة جنوب شرق آسيا.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يتم توصيل HQ الأوروبي عبر دائرة ExpressRoute إلى مركز شبكة WAN الظاهرية لغرب أوروبا.

• يتيح الاتصال العالمي من مركز إلى مركز WAN الظاهري نقل نسبة استخدام الشبكة إلى الشبكة الظاهرية المتصلة في المنطقة البعيدة.

المسار 3

يعرض المسار 3 تدفق نسبة استخدام الشبكة من منطقة آسيا المحلية DC المتصلة بشبكة WAN الخاصة بفرع متصل بـS2S الأوروبي.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يتم توصيل آسيا DC بشركة النقل المحلية الخاصة WAN.

• تنتهي دائرة ExpressRoute محليًا في اتصال Private WAN بمركز شبكة WAN الظاهرية في جنوب شرق آسيا.

• يتيح الاتصال العالمي من مركز إلى مركز WAN الظاهري نقل نسبة استخدام الشبكة.

المسار 4

يعرض المسار 4 تدفق نسبة استخدام الشبكة من Azure VNet في منطقة جنوب شرق آسيا إلى Azure VNet في منطقة غرب أوروبا.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يتيح الاتصال العالمي من مركز إلى مركز WAN الظاهري النقل الأصلي لجميع شبكات Azure VNets المتصلة دون مزيد من تكوين المستخدم.

المسار 5

يعرض المسار 5 تدفق نسبة استخدام الشبكة من مستخدمي VPN المتنقلين (P2S) إلى Azure VNet في منطقة غرب أوروبا.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يستخدم مستخدمو الكمبيوتر المحمول والأجهزة المحمولة عميل OpenVPN للاتصال الشفاف ببوابة P2S VPN في غرب أوروبا.

• يوجه مركز شبكة WAN الظاهرية لغرب أوروبا نسبة استخدام الشبكة محليًا إلى الشبكة الظاهرية المتصلة.

التحكم في الأمان والنهج عبر Azure Firewall

قامت شركة Contoso الآن بالتحقق من صحة الاتصال بين جميع الفروع والشبكات الظاهرية بما يتماشى مع المتطلبات التي تمت مناقشتها سابقا في هذه المقالة. لتلبية متطلباتهم للتحكم في الأمان وعزل الشبكة، يحتاجون إلى الاستمرار في فصل وتسجيل نسبة استخدام الشبكة عبر شبكة المركز. في السابق تم تنفيذ هذه الدالة بواسطة جهاز ظاهري للشبكة (NVA). تريد Contoso أيضًا إيقاف تشغيل خدمات الوكيل الحالية واستخدام خدمات Azure الأصلية لتصفية الإنترنت الصادرة.

Figure: Azure Firewall in Virtual WAN (Secured Virtual hub)

الخطوات عالية المستوى التالية مطلوبة لإدخال جدار حماية Azure في مراكز شبكة WAN الظاهرية لتمكين نقطة موحدة للتحكم في النهج. لمزيد من المعلومات حول هذه العملية ومفهوم المراكز الظاهرية الآمنة، راجع Azure Firewall Manager.

1. إنشاء نهج Azure Firewall.
2. ربط نهج جدار الحماية بمركز Azure Virtual WAN. تسمح هذه الخطوة لمركز Virtual WAN الحالي بالعمل كمركز ظاهري آمن، ونشر موارد جدار حماية Azure المطلوبة.

ملاحظة

هناك قيود تتعلق باستخدام المراكز الظاهرية الآمنة، بما في ذلك نسبة استخدام الشبكة بين المناطق. لمزيد من المعلومات، راجع Firewall Manager - المشاكل المعروفة.

تظهر المسارات التالية مسارات الاتصال الممكنة باستخدام مراكز Azure الظاهرية المؤمنة:

المسار 6

يعرض المسار 6 تدفق نسبة استخدام الشبكة الآمن بين الشبكات الظاهرية داخل نفس المنطقة.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• تقوم الشبكات الظاهرية المتصلة بنفس المركز الظاهري الآمن الآن بتوجيه نسبة استخدام الشبكة إلى عبر جدار حماية Azure.

• يمكن لـAzure Firewall تطبيق النهج على هذه التدفقات.

المسار 7

يعرض المسار 7 تدفق نسبة استخدام الشبكة من Azure VNet إلى الإنترنت أو خدمة أمان تابعة لجهة خارجية.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يمكن للشبكات الظاهرية المتصلة بـSecure Virtual Hub إرسال نسبة استخدام الشبكة إلى الوجهات العامة على الإنترنت، باستخدام Secure Hub كنقطة مركزية للوصول إلى الإنترنت.

• يمكن تصفية نسبة استخدام الشبكة هذه محليًا باستخدام قواعد Azure Firewall FQDN، أو إرسالها إلى خدمة أمان تابعة لجهة خارجية لفحصها.

المسار 8

يعرض المسار 8 تدفق نسبة استخدام الشبكة من الفرع إلى الإنترنت أو خدمة الأمان التابعة لجهة خارجية.

يتم توجيه نسبة استخدام الشبكة على النحو التالي:

• يمكن للفروع المتصلة بـSecure Virtual Hub إرسال نسبة استخدام الشبكة إلى الوجهات العامة على الإنترنت باستخدام Secure Hub كنقطة مركزية للوصول إلى الإنترنت.

• يمكن تصفية نسبة استخدام الشبكة هذه محليًا باستخدام قواعد Azure Firewall FQDN، أو إرسالها إلى خدمة أمان تابعة لجهة خارجية لفحصها.

الخطوات التالية

• تعرف على المزيد حول Azure Virtual WAN.
• تكوين Virtual WAN لملفات Azure NetApp