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

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

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

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

أجهزة شبكة ظاهرية خاصة متعددة محلية

يمكنك استخدام العديد من أجهزة الشبكة الظاهرية الخاصة من الشبكة المحلية للاتصال ببوابة شبكة 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 الظاهرية الخاصة بك، و10 لأجهزة Basic and Standard SKUs، و30 SKU HighPerformance.

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

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

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

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 عنوان بروتوكول إنترنت عام فريد، وسينشئ كل منها نفق أمان برتوكول الإنترنت ومفتاح إنترنت تبادلي لجهاز الشبكة الظاهرية الخاصة المحلي المحدد في بوابة الشبكة المحلية والاتصال. تجدر الإشارة إلى أن كلا قسمي VPN في الواقع جزء من الاتصال نفسه. ستظل بحاجة إلى تكوين جهاز الشبكة الظاهرية الخاصة المحلي لقبول أو إنشاء نفقين شبكة ظاهرية خاصة موقع إلى موقع إلى عنواني بروتوكول الإنترنت العامين لبوابة شبكة Azure الظاهرية الخاصة.

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

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

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

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

Diagram shows a Dual Redundancy scenario.

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

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

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

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

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

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 مطلوب.

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

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