Share via

توفرت بشكل كبير عبر المباني والاتصال VNet إلى VNet

  • مقالة

توفر هذه المقالة نظرة عامة على خيارات التكوين المتوفرة بشكل كبير لاتصالك عبر المباني و VNet إلى VNet باستخدام عبارات Azure VPN.

حول التكرار في بوابة VPN

تتكون كل بوابة Azure VPN من مثيلين عند تكوينها في وضع الاستعداد النشط. عند إخضاع المثيل النشط للصيانة المخطط لها أو حدوث عطل مفاجئ فيه، فإن مثيل الاستعداد سيتولى (تجاوز الفشل) تلقائيًا، وسيستأنف اتصالات S2S VPN أو VNet-to-VNet. سيؤدي التبديل إلى حدوث انقطاع لمدة قصيرة. في حالة إجراء الصيانة المخطط لها، يجب استعادة الاتصال في غضون 10 إلى 15 ثانية. بالنسبة للمشكلات غير المخطط لها، يكون استرداد الاتصال أطول، حوالي 1 إلى 3 دقائق في أسوأ الحالات. بالنسبة لاتصالات عميل P2S VPN بالبوابة، يتم قطع اتصال اتصالات P2S ويحتاج المستخدمون إلى إعادة الاتصال من أجهزة العميل.

Diagram shows an on-premises site with private I P subnets and on-premises V P N connected to an active Azure V P N gateway to connect to subnets hosted in Azure, with a standby gateway available.

أماكن عمل متعددة متوفرة بدرجة كبيرة

للتزويد بأفضل توفر لاتصالات الشبكة الظاهرية الخاصة، هناك بعض الخيارات المتاحة:

  • أجهزة شبكة ظاهرية خاصة متعددة محلية
  • بوابة شبكة Azure الظاهرية الخاصة Active-active
  • مزيج من كليهما

أجهزة VPN محلية متعددة

يمكنك استخدام العديد من أجهزة الشبكة الظاهرية الخاصة من الشبكة المحلية للاتصال ببوابة شبكة Azure الظاهرية الخاصة، كما هو موضح في الرسم التخطيطي التالي:

Diagram shows multiple on-premises sites with private I P subnets and on-premises V P N connected to an active Azure V P N gateway to connect to subnets hosted in Azure, with a standby gateway available.

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

  1. تحتاج إلى إنشاء اتصالات الشبكة الظاهرية الخاصة موقع إلى موقع متعددة من أجهزة شبكة ظاهرية خاصة إلى Azure. عند توصيل أجهزة شبكة ظاهرية خاصة متعددة من نفس الشبكة المحلية إلى Azure، تحتاج إلى إنشاء بوابة شبكة محلية واحدة لكل جهاز شبكة ظاهرية خاصة، واتصال واحد من بوابة شبكة Azure الظاهرية الخاصة لكل بوابة شبكة محلية.
  2. أن يكون لبوابات الشبكة المحلية المطابقة لأجهزتك VPN عناوين IP عامة فريدة في خاصية "GatewayIpAddress".
  3. BGP مطلوب لهذا التكوين. يجب أن يكون لكل بوابة شبكة محلية تمثل جهاز VPN عنوان IP فريد لنظير BGP محدد في خاصية "BgpPeerIpAddress".
  4. يجب استخدام BGP للإعلان عن نفس البادئات المحلية للشبكة إلى بوابة شبكة Azure الظاهرية الخاصة بك، وسيتم إعادة توجيه نسبة استخدام الشبكة عبر هذه الأنفاق في وقت واحد.
  5. يجب استخدام Equal-cost multi-path routing (ECMP).
  6. يتم حساب كل اتصال مقابل الحد الأقصى لعدد الأنفاق لبوابة Azure VPN. راجع صفحة إعدادات بوابة VPN للحصول على أحدث المعلومات حول الأنفاق والاتصالات ومعدل النقل.

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

بوابات الشبكة الظاهرية الخاصة Active-active

يمكنك إنشاء بوابة Azure VPN في تكوين نشط-نشط، حيث يقوم كلا مثيلي الأجهزة الظاهرية للبوابة بإنشاء أنفاق S2S VPN إلى جهاز VPN المحلي، كما هو موضح في الرسم التخطيطي التالي:

Diagram shows an on-premises site with private I P subnets and on-premises V P N connected to two active Azure V P N gateway to connect to subnets hosted in Azure.

في هذا التكوين، يحتوي كل مثيل بوابة Azure على عنوان IP عام فريد، وسيقوم كل منها بإنشاء نفق IPsec/IKE S2S VPN لجهاز VPN المحلي المحدد في بوابة الشبكة المحلية والاتصال. تجدر الإشارة إلى أن كلا قسمي VPN في الواقع جزء من الاتصال نفسه. ستظل بحاجة إلى تكوين جهاز VPN المحلي لقبول أو إنشاء نفقي S2S VPN لهذين العنوانين العامين لبوابة Azure VPN.

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

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

Dual-redundancy: بوابات الشبكة الظاهرية الخاصة active-active لكل من Azure والشبكات المحلية

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

Diagram shows a Dual Redundancy scenario.

يمكنك هنا إنشاء بوابة Azure VPN في تكوين نشط، وإنشاء بوابة شبكة محلية واتصالات اثنين من أجهزة VPN المحلية كما هو موضح أعلاه. والنتيجة هي اتصال شبكة كاملة من 4 أنفاق أمان برتوكول الإنترنت بين الشبكة الظاهرية Azure والشبكة المحلية.

جميع البوابات والأنفاق نشطة من جانب Azure، لذلك تنتشر نسبة استخدام الشبكة بين جميع الأنفاق ال 4 في وقت واحد، على الرغم من أن كل تدفق TCP أو UDP سيتبع مرة أخرى نفس النفق أو المسار من جانب Azure. على الرغم من أن عن طريق نشر نسبة استخدام الشبكة، قد تشاهد معدل نقل أفضل قليلًا عبر أنفاق أمان برتوكول الإنترنت، والهدف الأساسي لهذا التكوين هو قابلية الوصول العالية. ونظرا للطبيعة الإحصائية للانتشار، من الصعب توفير القياس حول كيفية تأثير ظروف حركة مرور التطبيقات المختلفة على الإنتاجية الإجمالية.

يتطلب هذا المخطط بوابتي شبكة محلية واتصالين لدعم زوج من أجهزة VPN المحلية، وBGP مطلوب للسماح بالاتصالين بنفس الشبكة المحلية. هذه المتطلبات هي نفس المتطلبات المذكورة أعلاه.

قابلية الوصول عالية VNet-to-VNet

يمكن تطبيق نفس التكوين النشط أيضا على اتصالات Azure VNet-to-VNet. يمكنك إنشاء بوابات VPN نشطة-نشطة لكلا الشبكتين الظاهريتين، وتوصيلها معا لتشكيل نفس اتصال الشبكة الكامل من 4 أنفاق بين شبكتي VNets، كما هو موضح في الرسم التخطيطي التالي:

Diagram shows two Azure regions hosting private I P subnets and two Azure V P N gateways through which the two virtual sites connect.

وهذا يضمن وجود دائما زوج من الأنفاق بين الشبكتين الظاهريتين لأي أحداث صيانة مخطط لها، مما يوفر قابلية وصول أفضل. على الرغم من أن طبولوجيا نفس الاتصال بين المباني يتطلب اتصالين، فطبولوجيا VNet-to-VNet الموضحة أعلاه ستحتاج اتصال واحد فقط لكل بوابة. بالإضافة إلى ذلك، BGP اختياري ما لم يكن توجيه العبور عبر اتصال VNet إلى VNet مطلوب.

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

راجع تكوين البوابات النشطة باستخدام مدخل Microsoft Azure أو PowerShell.