مشاركة عبر

تصميم اتصال بوابة عالي التوفر للاتصالات المحلية واتصالات VNet إلى VNet

  • مقالة

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

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

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

يظهر الرسم التخطيطي موقعا محليا مع شبكات I P فرعية خاصة وV P N محلي متصل ببوابة Azure V P N نشطة للاتصال بالشبكات الفرعية المستضافة في Azure، مع توفر بوابة الاستعداد.

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

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

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

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

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

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

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

هناك بعض المتطلبات والقيود:

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

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

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

يظهر الرسم التخطيطي موقعا محليا مع شبكات I P الفرعية الخاصة وV P N المحلية المتصلة ببوابة Azure V P N نشطة للاتصال بالشبكات الفرعية المستضافة في Azure.

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

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

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

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

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

يوضح الرسم التخطيطي سيناريو التكرار المزدوج.

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

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

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

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

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

يوضح الرسم التخطيطي منطقتين من مناطق Azure تستضيف شبكات I P الفرعية الخاصة وبوابتي Azure V P N التي يتصل من خلالها الموقعان الظاهريان.

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

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

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