توزيع الأجهزة الظاهرية للشبكة عالية التوافر

تشرح هذه المقالة الخيارات الأكثر شيوعا لنشر مجموعة من الأجهزة الظاهرية للشبكة (NVAs) للتوافر العالي في Azure. عادةً ما يتم استخدام NVA للتحكم في تدفق نسبة استخدام الشبكة بين مقاطع الشبكة المصنفة بمستويات أمان مختلفة، على سبيل المثال بين شبكة ظاهرية لمنطقة De-Militarized (DMZ) والإنترنت العام.

هناك عدد من أنماط التصميم حيث يتم استخدام NVAs لفحص نسبة استخدام الشبكة بين مناطق الأمان المختلفة، على سبيل المثال:

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

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

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

المتطلبات المسبقة: تفترض هذه المقالة فهما أساسياً لشبكة Azure وموازنات تحميل Azureوتوجيه نسبة استخدام الشبكة الظاهرية (UDRs).

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

• وقت التقارب: كم من الوقت يستغرق في كل تصميم لتوجيه نسبة استخدام الشبكة بعيداً عن مثيل NVA فاشل?
• دعم المخطط: ما هي تكوينات NVA التي يدعمها كل خيار تصميم? مجموعات NVA نشطة/نشطة/ نشطة/احتياطية، مع تكرار n+1?
• تماثل نسبة استخدام الشبكة: هل يفرض تصميم معين على NVA تنفيذ ترجمة عناوين الشبكة المصدر (SNAT) على الحزم لتجنب التوجيه غير المتماثل? أم يتم فرض تماثل نسبة استخدام الشبكة بوسائل أخرى?

ستصف الأقسام التالية في المستند أكثر البنى المستخدمة شيوعًا لدمج NVAs في شبكة Hub و Spook.

نظرة عامة على بنيات قابلية الوصول العالية

تصف البنيات التالية الموارد والتكوين اللازمين لـ NVAs عالية التوفر:

تصميم موازن التحميل

يستخدم هذا التصميم موازني تحميل Azure لعرض مجموعة من NVAs لبقية الشبكة:

• يتم استخدام موازن التحميل الداخلي لإعادة توجيه نسبة استخدام الشبكة الداخلية من Azure والأماكن المحلية إلى NVAs. يتم تكوين موازن التحميل الداخلي هذا مع قواعد منافذ HA، بحيث تتم إعادة توجيه كل منفذ TCP/UDP إلى مثيلات NVA.
• يعرض موازن التحميل العام NVAs للإنترنت. نظرا لأن منافذ قابلية الوصول العالية مخصصة لنسبة استخدام الشبكة الواردة، يجب فتح كل منفذ TCP/UDP فردي في قاعدة موازنة تحميل مخصصة.

يصف الرسم البياني التالي تسلسل القفزات التي ستتبعها الحزم من الإنترنت إلى خادم التطبيق في VNet متحدث:

قم بتنزيل ملف Visio لهذه البنية.

آلية إرسال حركة المرور من المتحدثين الرسميين إلى الإنترنت العام من خلال NVAs هي مسار يحدده المستخدم لـ 0.0.0.0/0 مع عنوان IP الداخلي لـ Load Balancer.

بالنسبة لحركة المرور بين Azure والإنترنت العام، سيعبر كل اتجاه لتدفق حركة المرور موزعًا مختلفًا لـ Azure Load (حزمة الدخول من خلال ALB العام، وحزمة الخروج من خلال ALB الداخلي). نتيجة لذلك، إذا كان التماثل المروري مطلوبًا، فيجب إجراء ترجمة عنوان الشبكة المصدر (SNAT) من قبل مثيلات NVA لجذب حركة المرور العائدة وتجنب عدم التماثل المروري.

يمكن استخدام هذا التصميم أيضًا لفحص حركة المرور بين Azure والشبكات المحلية:

إن آلية إرسال حركة المرور بين المتحدثين من خلال NVAs هي نفسها تمامًا، لذلك لا يتم توفير مخطط إضافي. في المخططات التوضيحية أعلاه، نظرًا لأن Talk 1 لا يعرف عن نطاق Spe 2، فإن 0.0.0.0/0 UDR سيرسل حركة المرور الموجهة إلى Talk 2 إلى موازن الحمل الداخلي في NVA.

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

يتمتع موازن الحمل Azure بوقت تقارب جيد جدًا في حالة انقطاع NVA الفردي. نظراً لأنه يمكن إرسال تحقيقات السلامة كل 5 ثوان، ويستغرق الأمر 3 تحقيقات فاشلة للإعلان عن مثيل خلفي خارج الخدمة، فإنه عادةً ما يستغرق 10-15 ثانية لموازن تحميل Azure لتقارب نسبة استخدام الشبكة إلى مثيل NVA مختلف.

يدعم هذا الإعداد كلاً من التكوينات النشطة/النشطة والنشطة/الاحتياطية. ومع ذلك، بالنسبة للتكوينات النشطة/الاحتياطية، تحتاج مثيلات NVA إلى تقديم منفذ TCP/UDP أو نقطة نهاية HTTP التي لا تستجيب لفحوصات صحة موازن التحميل ما لم يكن المثيل في الدور النشط.

استخدام موازنات التحميل L7

تتمثل إحدى الحالات الخاصة لهذا التصميم في استبدال موازن الحمل العام Azure بموازن حمل الطبقة 7 مثل بوابة تطبيق Azure (التي يمكن اعتبارها NVA من تلقاء نفسها). في هذه الحالة، ستحتاج NVAs فقط إلى موازن حمل داخلي أمامها، نظرًا لأن حركة المرور من بوابة التطبيق سيتم الحصول عليها من داخل VNet، وعدم تناسق حركة المرور ليس مصدر قلق.

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

Azure Route Server

Azure Route Server هي خدمة تسمح لـ NVA بالتفاعل مع Azure SDN عبر بروتوكول Border Gateway (BGP). لن تتعلم NVAs فقط بادئات IP الموجودة في Azure VNets، ولكنها ستكون قادرة على إدخال المسارات في جداول التوجيه الفعالة للأجهزة الظاهرية في Azure.

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

تدعم طريقة الإدراج هذه كلاً من النشط/النشط (جميع NVAs تعلن عن نفس المسارات إلى خادم Azure Route )، بالإضافة إلى النشط/الاستعداد (أحدهما يعلن عن مسارات بمسار AS أقصر من الآخر). يدعم خادم Azure Route ما لا يزيد عن 8 مناطق مجاورة لـ BGP. وبالتالي، في حالة استخدام مجموعة تصغير من NVAs النشطة، سيدعم هذا التصميم 8 مثيلات NVA كحد أقصى.

وقت التقارب سريع جدًا في هذا الإعداد، وسيتأثر بمؤقتات البقاء على قيد الحياة ووقت الانتظار في منطقة BGP المجاورة. في حين أن خادم Azure Route يحتوي على مؤقتات افتراضية للبقاء على قيد الحياة ووقت الانتظار (60 ثانية و 180 ثانية على التوالي)، يمكن لـ NVAs التفاوض على مؤقتات أقل خلال إنشاء BGP المجاور. يمكن أن يؤدي ضبط هذه المؤقتات منخفضة جدًا إلى عدم استقرار BGP.

هذا التصميم هو الخيار الأكثر شيوعًا لـ NVAs التي تحتاج إلى التفاعل مع توجيه Azure، على سبيل المثال NVAs إنهاء VPN التي تحتاج إلى تعلم البادئات التي تم تكوينها في Azure VNets، أو الإعلان عن مسارات معينة عبر نظراء ExpressRoute الخاصين.

Gateway Load Balancer

Azure Gateway Load Balancer هو طريقة جديدة لإدراج NVAs في مسار البيانات دون الحاجة إلى توجيه حركة المرور باستخدام مسارات User-Defined. بالنسبة للآلات الافتراضية التي تكشف عن أعباء عملها عبر موازن تحميل Azure أو عنوان IP عام، يمكن إعادة توجيه حركة المرور الواردة والصادرة بشفافية إلى مجموعة من NVAs الموجودة في VNet مختلف. يصف الرسم التخطيطي التالي المسار الذي تتبعه الحزم لنسبة استخدام الشبكة الواردة من الإنترنت العام في حالة تعرض أحمال العمل التطبيق عبر موازن تحميل Azure:

تتمثل إحدى المزايا الرئيسية لطريقة الحقن NVA هذه في أن ترجمة عنوان الشبكة المصدر (SNAT) غير مطلوبة لضمان تناسق حركة المرور. تتمثل ميزة أخرى لخيار التصميم هذا في أنه يمكن استخدام NVAs نفسها لفحص حركة المرور من/إلى VNets المختلفة، وبالتالي تحقيق تعدد الوظائف من منظور NVA. لا يلزم تقارب VNet بين NVA VNet وVNet (شبكات) حِمل العمل، ولا يلزم وجود مسارات محددة من قبل المستخدم في VNet حِمل العمل، مما يبسط التكوين بشكل كبير.

يمكن استخدام إدخال الخدمة مع موازن تحميل البوابة للتدفقات الواردة التي تصل إلى موازن تحميل عام Azure (وحركة مرور الإرجاع الخاصة بها)، وكذلك للتدفقات الصادرة التي تنشأ في Azure. لا يمكن لحركة المرور East-West بين أجهزة Azure الظاهرية الاستفادة من موازن تحميل البوابة لإدخال NVA.

في مجموعة NVA، سيتم استخدام فحوصات التحقق من صحة Azure Load Balancer للكشف عن حالات فشل مثيل NVA الفردية، ما يحقق وقت تقارب سريع جدا (10-15 ثانية).

تغيير PIP-UDR

الفكرة الكامنة وراء هذا التصميم هي وجود الإعداد الذي سيكون مطلوبًا دون تكرار NVA، وتعديله في حالة ما إذا كانت NVA تعاني من وقت التعطل. يوضح الرسم البياني أدناه كيف يرتبط عنوان IP العام لـ Azure بـ NVA النشط (NVA 1)، وتحتوي المسارات المحددة من قبل المستخدم في المتحدثين على عنوان IP النشط لـ NVA كقفزة قادمة (10.0.0.37).

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

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

تتمثل إحدى فوائد هذا التصميم في عدم الحاجة إلى ترجمة عنوان الشبكة المصدر (SNAT) لضمان تناسق حركة المرور، نظرًا لوجود NVA واحدة فقط نشطة في أي وقت معين.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

• كيث ماير | مهندس حلول السحابة الأساسي
• Telmo Sampaio | مدير هندسة الخدمة الرئيسي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• تعرف على كيفية تنفيذ شبكة مختلطة آمنة باستخدام Azure Firewall.
• شبكات المحيط - إطار عمل اعتماد السحابة
• إطار عمل اعتماد Microsoft Cloud