إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يوفر هذا الدليل مسار قراءة متسلسل عبر دليل تصميم الشبكات Azure للعملاء الذين يوصلون Azure إلى Amazon Web Services (AWS)، أو Google Cloud، أو نقل أحمال العمل من مزود سحابة آخر. اتبع الخطوات المرقمة لتصميم اتصال آمن ومراقب بين Azure وبنية السحابة الحالية لديك.
لماذا يأتي الاكتشاف أولا
الشبكات عبر السحابة تربط Azure ببيئة أو أكثر خارجية للسحابة. قد تشغل أحمال عمل في AWS أو Google Cloud تحتاج إلى اتصال خاص بخدمات Azure، أو قد تقوم بنقل التطبيقات من سحابة أخرى إلى Azure مع الحفاظ على الاتصال بالتطبيقات التي تبقى خلفها. في كلتا الحالتين، يجب أن تتكامل شبكة Azure الخاصة بك مع البنية التحتية التي لا تتحكم بها بالكامل في الجانب الآخر.
يبدأ هذا المسار بالاكتشاف بدلا من تصميم البنية التحتية ل Azure. تقوم أولا برسم خريطة الطوبولوجيا السحابية المتعددة الحالية لديك (فهم ما يمر أين، وكيف يتصل، وأي حركة مرور تتدفق بين السحب) قبل تصميم جانب Azure. هذا النهج الذي يعتمد على الاكتشاف أولا يمنع إعادة العمل: إذا صممت شبكات Azure دون فهم طوبولوجيا AWS أو Google Cloud الخاصة بك، فإنك تخاطر بحدوث تعارضات عناوين IP، وفجوات في الاتصال، ونقاط عمياء أمنية.
تستخدم معمارية الهدف شبكة Azure Virtual Wide Area Network (WAN) كمركز نقل (ما يعادل Azure لبوابة النقل AWS) مع أنفاق VPN IPSec إلى بوابة AWS الافتراضية الخاصة وGoogle Cloud VPN. يقوم Azure Firewall في مركز افتراضي آمن بفحص جميع حركة المرور عبر السحابة والفروع. يتطلب DNS تخطيطا دقيقا للانتقال للحفاظ على عمل حل الأسماء عبر حدود السحابة أثناء الترحيل.
المتطلبات المسبقه
- اقرأ خطة الشبكات ونظرة التصميم في Azure للحصول على التعريف بخدمات الشبكات المتاحة في Azure.
- اكتشاف كامل للطوبولوجيا لبيئات AWS وGoogle Cloud الخاصة بك:
- AWS: تشغيل مركز ترحيل AWS أو اكتشاف عبء العمل على AWS لجرد السحب الخاصة الافتراضية (VPCs)، وبوابات النقل، والاتصال بين VPCs.
- Google Cloud: استخدم مركز ذكاء الشبكة لرسم خرائط شبكات VPC، ومرفقات الاتصال السحابي، وقواعد جدار الحماية.
- تدفقات حركة المرور عبر السحابة في المستندات: أي التطبيقات تتواصل بين السحب، وعرض النطاق الترددي المطلوب، وحساسية زمن التأخير، ومتطلبات التشفير.
- أنشئ قائمة بمجموعات عناوين IP عبر السحب الثلاث لتحديد التداخلات.
مسار قراءتك
المراحل التالية توجهك خلال تصميم الشبكات عبر السحابة بالتتابع.
المرحلة الأولى: الاكتشاف
ابدأ بالاكتشاف. افهم المشهد السحابي المتعدد قبل تصميم بنية Azure التحتية.
1. الاتصال عبر المناطق ومتعدد السحب
هذه المقالة هي نقطة قرارك الأساسية في التصميم. حدد طوبولوجيا السحابة المتعددة: أي VPCs من AWS وGoogle Cloud VPCs تحتاج إلى اتصال ب Azure، وما هي حركة المرور التي تتدفق بين السحب، وأي نمط معماري يناسب مقياسك. استخدم تعيين الخدمة بين مزودي الخدمات السحابية (بوابة النقل إلى Virtual WAN، مجموعات الأمان إلى مجموعات أمن الشبكة، الارتباط من VPC إلى VNet) لترجمة تصميمك الحالي إلى مصطلحات Azure.
2. WAN ظاهرية
Virtual WAN هو نموذج النقل الموصى به عندما يكون لديك عدة VPCs أو فروع أو مناطق أو حواف سحابية. يوفر Virtual WAN ما يعادل بوابة AWS Transit في Azure: التوجيه الآلي، الأمان المركزي، ونطاق متعدد الفروع/المناطق. قيم ما إذا كان عقار السحابة المشترك لديك يبرر Virtual WAN أم أن استخدام Hub and Spokes أبسط مع VPN Gateway يكفي.
المرحلة الثانية: الأسس
3. الشبكات الافتراضية والشبكات الفرعية
صمم Azure VNet الخاص بك كمنطقة هبوط لأحمال العمل المنقولة أو المتصلة. خريطة من مفاهيم VPC في AWS وGoogle Cloud VPC: تتحول شبكات VPC الفرعية إلى شبكات Azure الفرعية، ومناطق التوافر ترسم إلى مناطق توفر Azure، وجداول المسارات تتبع أنماطا مشابهة. ركز على حجم الشبكة الفرعية لأعباء العمل التي تقع في Azure.
خطط لمساحة عناوين غير متداخلة عبر جميع السحب الثلاث. هذه الخطوة ضرورية للاتصال عبر السحابة: إذا تداخلت نطاقات Azure VNet مع نطاقات AWS VPC أو Google Cloud VPC، فلن تتمكن من إنشاء أنفاق VPN بينها. وثق كل كتلة CIDR مستخدمة عبر جميع البيئات قبل تخصيص مساحة عناوين Azure.
5. مجموعات أمان الشبكات ومجموعات أمان التطبيقات
قم بعكس قواعد مجموعات الأمان في AWS وجدار الحماية الخاص ب Google Cloud كمجموعات أمان الشبكة Azure (NSGs). ترجم قواعد السماح والرفض الحالية إلى صيغة NSG. استخدم مجموعات أمان التطبيقات (ASGs) لمحاكاة التجميع القائم على الوسوم الذي توفره مراجع مجموعة الأمن في AWS.
المرحلة 3: الاتصال
قم بإعداد أنفاق VPN عبر IPSec بين Azure وAWS أو Google Cloud للنقل السحابي المشفر. ربط Azure VPN Gateway (أو اتصالات Virtual WAN VPN) ب AWS Virtual Private Gateway وGoogle Cloud VPN. اختر عرض النطاق الترددي للأنفاق بناء على احتياجاتك من حركة المرور عبر السحابة. خطط للأنفاق الزائدة لتجنب نقاط الفشل الفردية.
المرحلة الرابعة: الأمن
7. أمان DNS وحل الأسماء الخاصة
خطط لاستراتيجية تحويل DNS قبل نقل أعباء العمل. التطبيقات في AWS أو Google Cloud تحل أسماء المضيفين التي قد تحتاج إلى الإشارة إلى Azure بعد الترحيل. تكوين Azure DNS Private Resolver مع نقاط نهاية صادرة لحل الأسماء عبر السحابة. راجع قائمة التحقق لتحويل DNS لاحقا في هذا المقال للحصول على إرشادات ترحيل خطوة بخطوة.
نشر Azure Firewall في مركز افتراضي آمن لفحص جميع حركة المرور عبر السحابة والفروع. كل حزمة تعبر بين Azure وAWS أو Google Cloud تمر عبر جدار الحماية لتسجيل السجلات وتطبيق السياسات. استخدم قواعد الشبكة لأنماط حركة المرور عبر السحابة وتصفية استخبارات التهديدات لحجب الوجهات الخبيثة المعروفة.
المرحلة 5: العمليات
9. مراقبة الشبكة وقابلية الرصد
المناطق العابرة للسحابة أصعب في التشخيص لأنك لا تتحكم في كلا طرفي كل اتصال. تمكين Azure Network Watcher لاختبار الاتصال، وتشخيص نفق VPN، والتقاط الحزم. راقب وقت تشغيل النفق، وفترة التأخير بين السحب، ومعدل النقل مقابل متطلبات الطاقة الإنتاجية. قم بتعيين تنبيهات لقطع الاتصال بالأنفاق التي تؤثر على توفر التطبيقات عبر السحابة.
المقالات الشرطية
أدرج هذه المقالات بناء على متطلباتك الخاصة:
| شرط | مقالة | متى يجب التضمين |
|---|---|---|
| تطبيق موجه للجمهور | الدخول إلى الإنترنت | تطبيقك المنتقلا مواجها للإنترنت (يتطلب وصولا مباشرا للعامة) |
| تطبيق HTTP/HTTPS | جدار الحماية لتطبيقات الويب | الطبقة 7 WAF مطلوبة لتطبيقات الويب الموجهة للجمهور |
| توزيع الطبقة 7 مطلوب | تسليم التطبيق والأداء | تحتاج إلى توزيع حركة المرور العالمية أو الإقليمية بعد الهجرة |
| نقاط النهاية العامة | حماية DDoS | لديك متطلبات وقت تشغيل للخدمات الموجهة للجمهور |
| يفضل المحور والسبوك | طوبولوجيا المحور والتحدث | مساحة السحابة المشتركة لديك صغيرة بما يكفي بحيث لا يكون Virtual WAN مبررا |
| Azure متعدد المناطق | الشبكات متعددة المناطق | يمتد هدفك على Azure عبر عدة مناطق تتجاوز الاتصال عبر السحابة |
| الوصول إلى مسؤول الأجهزة الافتراضية | وصول المطور والإدارة | تحتاج إلى وصول آمن من RDP/SSH إلى الأجهزة الافتراضية المستضافة في Azure |
| الخروج المركزي | الوصول إلى الإنترنت الصادر | سياسة الخروج المركزية من الإنترنت هي جزء من تصميمك المستهدف |
| عقار VNet الكبير | إدارة الشبكات المركزية | ينمو جانب Azure ليصبح عقارا متعدد الاشتراكات تحت حكم |
| نقاط نهاية PaaS الخاصة | الوصول الخاص بنظام PaaS | تشمل البنية المستهدفة خدمات Azure PaaS مع نقاط نهاية خاصة |
قائمة التحقق لاكتشاف السحب العرضية
قبل أن تصمم شبكات Azure، قم بتعيين خدمات السحابة الحالية لديك بنظائر Azure. هذا الرسم الخيطي يسرع قرارات التصميم ويمنع عدم التوافق في التوقعات.
تعيين خدمات AWS إلى Azure
| خدمة AWS | Azure Equivalent | ملاحظات |
|---|---|---|
| بوابة النقل | WAN ظاهرية | مركز توجيه مركزي لأنظمة VPC متعددة ومناطق متعددة وسحابة متعددة |
| VPC | الشبكة الافتراضية في Azure | حدود الشبكة المعزولة مع الشبكات الفرعية وجداول المسار |
| الpeering في VPC | تشاشير VNet | الاتصال المباشر بين شبكتين افتراضيتين |
| مجموعات الأمان | مجموعات أمان الشبكة (NSGs) | تصفية حركة المرور ذات الحالة على مستوى الشبكة الفرعية أو واجهة الشبكة |
| قوائم التحكم في الوصول للشبكة | NSGs (مستوى الشبكة الفرعية) | تجمع مجموعات Azure NSG بين وظائف مجموعة الأمن وNACL |
| البوابة الخاصة الافتراضية | VPN Gateway | نقطة إنهاء VPN في IPSec |
| الاتصال المباشر | Azure ExpressRoute | اتصال خاص مخصص (ليس عبر الإنترنت العام) |
| المناطق المستضافة الخاصة للطريق 53 | مناطق Azure Private DNS | حل أسماء Private DNS ضمن الشبكات الافتراضية |
| جداول المسارات | User-Defined المسارات (UDRs) | التوجيه المخصص لتجاوز مسارات نظام Azure أو المسارات الضمنية في AWS |
| Load Balancer المرن (ALB/NLB) | موازن تحميل Azure / Application Gateway | توازن الأحمال L4 وL7؛ توفر Application Gateway قدرات WAF مشابهة ل AWS ALB مع AWS WAF |
| AWS WAF | Azure Web Application Firewall | حماية HTTP/HTTPS من الطبقة 7 |
| جدار الحماية الشبكي | Azure Firewall | جدار حماية شبكة حالة مع ذكاء تهديدات |
تعيين خدمة Google Cloud إلى Azure
| خدمة جوجل كلاود | Azure Equivalent | ملاحظات |
|---|---|---|
| شبكة VPC | الشبكة الافتراضية في Azure | مورد عالمي في Google Cloud؛ Regional in Azure (استخدم تشاير VNet للتعامل عبر المناطق) |
| الاتصال السحابي | Azure ExpressRoute | اتصال خاص مخصص |
| السحابة الافتراضية | VPN Gateway | أنفاق IPSec VPN |
| Cloud NAT | بوابة Azure NAT | الوصول الصادر إلى الإنترنت للموارد الخاصة |
| راوتر سحابي | Azure Route Server | تبادل المسارات الديناميكي BGP مع الأجهزة الافتراضية للشبكة |
| درع السحابة | Azure Web Application Firewall | DDoS في الطبقة 7 وحماية التطبيقات |
| قواعد جدار الحماية | مجموعات أمان الشبكة | تصفية حركة المرور (قواعد Google Cloud عالمية؛ مجموعات Azure NSG هي لكل شبكة فرعية أو لكل شبكة (NIC) |
| مناطق DNS الخاصة بالسحابة | مناطق Azure Private DNS | حل الاسم الخاص داخل الشبكات |
| مركز استخبارات الشبكات | Azure Network Watcher | مراقبة الشبكة، التشخيص، وتصور الطوبولوجيا |
قائمة التحقق من تحويل DNS
تحويل DNS هو الخطوة الأعلى خطورة في الانتقال عبر السحب. اتبع هذه القائمة لتقليل فشل الدقة أثناء الانتقال.
قبل الترحيل
- قيم وقت العيش (TTL) أقل على جميع سجلات DNS التي تتغير. اضبط TTL على 60–300 ثانية على الأقل قبل الانتقال ب48 ساعة. تضمن هذه الخطوة انتهاء صلاحية الذاكرة المؤقتة بسرعة عند تحديث السجلات.
- وثق كل سجل DNS يشير إلى البنية التحتية التي تقوم بنقلها: سجلات A للخوادم، سجلات CNAME للخدمات، سجلات MX للبريد، وسجلات SRV لاكتشاف الخدمة.
- Configure Azure DNS Private Resolver with outbound endpoints in your Azure VNet. يقوم هذا المحلل بتوجيه الاستعلامات الخاصة بالمناطق المستضافة في AWS/Google Cloud إلى خوادم DNS الصاعدة المناسبة خلال فترة التعايش.
- اختبر التقديم والرجوع للدقة من Azure VNets إلى أسماء مستضافة في AWS/Google Cloud قبل ترحيل أي أعباء عمل.
خلال الهجرة
- تحديث سجلات CNAME للخدمات التي تنتقل إلى Azure. Point CNAMEs إلى الواجهة الأمامية لـ Azure أو مدير حركة بيانات Azure أو Azure Application Gateway endpoints أثناء انتقال كل خدمة.
- تحديث سجلات المضيف A للخوادم الفردية التي تنتقل للنقل. استبدل عناوين IP الخاصة ب AWS أو Google Cloud بعناوين IP الخاصة Azure في مناطق DNS الخاصة بك.
- حافظ على تفعيل التوجيه الشرطي حتى تستمر الأسماء في المناطق التي لم تنتقل إليها بعد في الحل عبر خوادم DNS الخاصة بالسحابة الأصلية.
بعد عملية الترحيل
- تحقق من الدقة من جميع المواقع: العملاء المحليين، وشبكات Azure VNet، وأي أحمال عمل متبقية على AWS أو Google Cloud يجب أن تحل الأسماء المنقولة بشكل صحيح.
- ارفع قيم TTL إلى مستويات الإنتاج (3,600 ثانية أو أكثر) بعد تأكيد الدقة المستقرة.
- قم بإزالة المحولات الشرطية للمناطق التي تم نقلها بالكامل إلى Azure DNS. احتفظ بالمحولات فقط للمناطق التي تبقى في AWS أو Google Cloud.
ما بنيته
باتباع هذا المسار القراءة، قمت بتوصيل Azure ببيئة AWS أو Google Cloud الحالية لديك عبر النقل المشفر، وفحص الجدار الناري المركزي، ومراقبة الاتصال. تصميمك يشمل:
- اكتشاف الطوبولوجيا متعددة السحب ورسم خرائط الخدمات
- Virtual WAN أو بنية النقل محور وكلمة
- أنفاق VPN عبر IPSec إلى AWS وGoogle Cloud
- Azure Firewall for cross-cloud traffic inspection
- تحويل DNS مع Private Resolver لحل الأسماء عبر السحابة
- مراقبة Network Watcher لصحة الأنفاق وأدائها
الخطوات التالية
- مسار الشبكات بنظام الرفع والانتقال: إذا كان لديك أيضا أعباء عمل محلية تنتقل مباشرة إلى Azure IaaS
- ترحيل وتحديث مسار الشبكات: إذا اعتمد نشر Azure الخاص بك خدمات وحاويات PaaS
- مراحل التصميم بنظرة سريعة: للملخص العام القائم على المراحل لتصميم شبكة Azure
- خطة وتصميم شبكة Azure نظرة عامة: لاستكشاف جميع الخدمات المتاحة بناء على القدرات