تُغير السحابة طريقة تصميم البنية الأساسية، بما في ذلك تصميم جدران الحماية، لأن الشبكة ليست فعلية أو في شبكات LAN الظاهرية بعد الآن. لا تتوفر كافة ميزات الشبكة الفعلية في شبكة ظاهرية (VNet). وهذا يشمل استخدام عناوين IP الحرة أو نسبة استخدام الشبكة البث والتي تؤثر على تنفيذ بنيات قابلية الوصول العالية. يُمكن/يجب تنفيذ موازنات التحميل للأجهزة الظاهرية للشبكة (NVAs) بطريقة مُعينة لتحقيق بنية قابلية وصول عالية (HA) داخل شبكة ظاهرية. يُقدم هذا الدليل نهجًا منظمًا لتصميم جدران حماية ذات قابلية وصول عالية في Azure باستخدام أجهزة ظاهرية تابعة لجهة خارجية.
خيارات لتصميم الأجهزة الظاهرية للشبكة عالية التوفر
عند نشر بنيات قابلية الوصول العالية، ثمة بعض الخيارات لتوفير تجاوز الفشل:
- جداول التوجيه المُدارة بواسطة واجهة برمجة تطبيقات Azure: يستخدم هذا الخيار جدوليّ توجيه، أحدهما نشط والآخر سلبي لتبديل عنوان IP للبوابة النشطة لجميع الخدمات التي تعمل على شبكة ظاهرية/شبكة فرعية.
- بروتوكول الإنترنت الحر المدار بواسطة واجهة برمجة تطبيقات Azure: يستخدم هذا الخيار عنوان بروتوكول الإنترنت ثانويًا على جدران الحماية يمكن نقله بين جدار حماية نشط وموقف.
- موازن التحميل المدار: يستخدم هذا الخيار موازن تحميل Azure للعمل كعنصر بروتوكول الإنترنت للبوابة للشبكة الفرعية، والذي يقوم بعد ذلك بإعادة توجيه نسبة استخدام الشبكة إلى جدار الحماية النشط. قد يقوم بإعادة توجيه نسبة استخدام الشبكة النشطة-النشطة لتوفير موازنة تحميل حقيقية.
تكمُن المشكلة في الخيارين الأولين في أن تجاوز الفشل نفسه بطيء. يجب أن يوجه جدار الحماية تجاوز الفشل، وهو في الأساس «إعادة تكوين» لخدمات Azure من خلال نشر جديد. اعتمادًا على مدى سرعة اكتمال هذا النشر، سيتم تقليل تدفقات نسبة استخدام الشبكة لعدة دقائق. علاوةً على ذلك، فإنه لا يسمح بتكوين نشط-نشط حيث يعمل كلا جداري الحماية في نفس الوقت.
هذا هو السبب في أن الخيار الثالث هو الأكثر تفضيلًا. يتم تصغير وقت التعطل حيث يمكن أن يفشل موازن التحميل على الفور تقريبًا إلى جدار الحماية الاحتياطي (في نشط-سلبي) أو مجرد إزالة الحمل من جدار الحماية الفاشل (في نشط-نشط). ولكن لا يمكنك فقط استخدام موازنات التحميل كـ «بوابات افتراضية» لأنها تؤثر على تدفق نسبة استخدام الشبكة ويجب أن تكون حزم بروتوكول تحكم الإرسال ذات حالة.
جُدران الحماية ذات الساقين
تبدأ الصورة التالية باثنين من FWs (FW-1 وFW-2)، مع موازن تحميل خارجي وخادم الواجهة الخلفية S1.
هذه البنية عبارة عن إعداد بسيط، يستخدم لنسبة استخدام الشبكة الواردة. تصل الحزمة إلى موازن التحميل، الذي يختار جدار الحماية الوجهة من تكوينها. ثم يُرسِل جدار الحماية المختار نسبة استخدام الشبكة إلى خادم الواجهة الخلفية (الويب). إذا تم تمكين SNAT ل جدار الحماية-1، فسيرى الخادم S1 نسبة استخدام الشبكة التي تأتي من بروتوكول الإنترنت الداخلي ل جدار الحماية-1، لذلك سيرسل أيضًا الرد على الحزمة إلى جدار الحماية-1. يمكن أن يحدث تجاوز الفشل بسرعة إلى جدار الحماية-2 في هذا السيناريو. بالنسبة لنسبة استخدام الشبكة الصادرة، يمكننا إضافة موازن تحميل آخر على الجانب الداخلي. عندما يبدأ الخادم S1 نسبة استخدام الشبكة، سيتم تطبيق نفس المبدأ. نسبة استخدام الشبكة تصل إلى موازن الحماية الداخلي (iLB)، الذي يختار جدار حماية يترجم بعد ذلك NAT للحل الخارجي:
جدران الحماية ثُلاثية الأرجل
تنشأ مشكلات عند إضافة واجهة أخرى إلى جدار الحماية، وتحتاج إلى تعطيل ترجمة NAT بين المناطق الداخلية. في هذه الحالة، راجع الشبكة الفرعية B والشبكة الفرعية -C:
سيتم موازنة تحميل التوجيه L3 بين المناطق الداخلية (الشبكة الفرعية-B والشبكة الفرعية -C) بدون ترجمة عناوين الشبكة. يُصبح هذا الإعداد أكثر وضوحًا بالنظر إلى تدفقات نسبة استخدام الشبكة بما في ذلك موازنات التحميل في طريقة عرض مختلفة. يُوضح الرسم التخطيطي أدناه طريقة العرض حيث ترتبط موازنات التحميل الداخلية [iLB] بـ NIC محدد على جدران الحماية:
باستخدام نسبة استخدام الشبكة L3 (بدون ترجمة عناوين الشبكة)، سيرى S2 عنوان IP S1 كعنوان المصدر. سيرسل S2 بعد ذلك نسبة استخدام الشبكة الإرجاع للشبكة الفرعية B (التي ينتمي إليها S1-IP) إلى موازن التحميل الداخلي في الشبكة الفرعية-C. نظرًا لأن موازنات التحميل الداخلية في الشبكة الفرعية-B وموازنات التحميل الداخلية في الشبكة الفرعية-C لا يقومان بمزامنة حالات جلسة العمل الخاصة بهم، اعتمادًا على نسبة استخدام الشبكة خوارزمية موازنة التحميل التي يمكن أن تنتهي في جدار الحماية-2. لا يعرف جدار الحماية-2 بشكل افتراضي أي شيء عن الحزمة الأولية (الخضراء)، لذلك سيتم إسقاط الاتصال.
يحاول بعض موردي جدار الحماية الاحتفاظ بحالة اتصال بين جدران الحماية، لكنهم سيحتاجون إلى مزامنة فورية تقريبًا لتكون محدثة في حالات الاتصال. تحقّق من مورد جدار الحماية إذا أوصى بهذا الإعداد.
أفضل طريقة للتعامل مع هذه المُشكلة هي القضاء عليها. في المثال أعلاه، يعني هذا الحل القضاء على الشبكة الفرعية-C، ما يجلب لنا مزايا الشبكات الظاهرية.
عزل المُضيفين في شبكة فرعية باستخدام مجموعات أمان الشبكة
عندما يكون هناك جهازان ظاهريان في شبكة فرعية واحدة، بإمكانك تطبيق NSG الذي يعزل نسبة استخدام الشبكة بين الاثنين. بشكلٍ افتراضي، يسمح بنسبة استخدام الشبكة داخل شبكة ظاهرية بالكامل. إضافة قاعدة Deny all على NSG، تعزل كافة الأجهزة الظاهرية عن بعضها البعض.
تستخدِم الشبكات الظاهرية نفس أجهزة التوجيه الخلفية (الظاهرية)
تستخدم الشبكة الظاهرية/الشبكات الفرعية نظام موجه خلفي واحد من Azure، وعلى هذا النحو، ليست هناك حاجة لتحديد عنوان IP للمُوجه لكل شبكة فرعية. يمكن أن تكون وجهة المسار في أي مكان في نفس الشبكة الظاهرية أو حتى في الخارج.
باستخدام الشبكات الظاهرية، بإمكانك التحكم في المسارات في كل شبكة فرعية. يُمكن أن تشير هذه المسارات أيضًا إلى IP واحد في شبكة فرعية أخرى. في الصورة أعلاه، ثمة موازن التحميل في الشبكة الفرعية-D، والذي يوازن التحميل بين جداري الحماية. عندما يبدأ S1 نسبة استخدام الشبكة (باللون الأخضر)، سيتم موازنة التحميل مع، على سبيل المثال، جدار الحماية-1. سيتصل جدار الحماية-1 بعد ذلك ب S2 (لا يزال أخضر). سيرسل S2 نسبة استخدام الشبكة الاستجابة إلى IP الخاص بـ S1 (كما تم تعطيل NAT). نظرًا لجداول التوجيه، يستخدم S2 نفس بروتوكول الإنترنت لموازنات التحميل مثل بوابته. قد يتطابق موازن التحميل مع نسبة استخدام الشبكة إلى جلسة العمل الأولية، لذلك سيشير دائما إلى نسبة استخدام الشبكة هذه مرة أخرى إلى جدار الحماية-1. ثم يقوم جدار الحماية-1 بإرساله إلى S1، وإنشاء تدفق نسبة استخدام شبكة متزامنة.
لكي يعمل هذا الإعداد، يجب أن يكون لدى جدار الحماية جدول توجيه (داخليًا) يشير إلى الشبكة الفرعية -B والشبكة الفرعية-C إلى الشبكة الفرعية الافتراضية الخاصة بها. هذه البوابة للشبكة الفرعية هي أول IP متاح منطقيًا في نطاق الشبكة الفرعية في الشبكة الظاهرية.
التأثير على خدماتِ الوكيل العكسي
عند نشر خدمة وكيل عكسي، عادة ما يكون خلف جدار الحماية. يمكنك بدلًا من ذلك وضعه في خط مع جدار الحماية وتوجيه نسبة استخدام الشبكة فعليًا من خلال جدار الحماية. تتمثل ميزة هذا الإعداد في أن خدمة الوكيل العكسي سوف ترى عنوان IP الأصلي للعميل المُتصل:
لهذا التكوين، تحتاج جداول التوجيه على الشبكة الفرعية-E إلى توجيه الشبكة الفرعية-B والشبكة الفرعية-C من خلال موازن التحميل الداخلي. تحتوي بعض خدمات الوكيل العكسي على جدران حماية مضمنة تسمح لك بإزالة جدران الحماية معًا في تدفق الشبكة هذا. تشير جدران الحماية المضمنة من الوكيل العكسي مباشرة إلى خوادم الشبكة الفرعية-B/C.
في هذا السيناريو، سيكون SNAT مطلوبًا على الوكيل العكسي أيضًا لتجنب إرجاع نسبة استخدام الشبكة للتدفق من خلال ورفضها من قبل جدران الحماية إلى الشبكة الفرعية-A.
VPN/ER
يوفر Azure خدمات VPN/ER التي تدعم BGP/عالية التوفر من خِلال بوابات الشبكة الظاهرية Azure. يحتفظ معظم المُهندسين المعماريين بهذه للاتصالات الخلفية أو غير المُتصلة بالإنترنت. يعني هذا الإعداد أن جدول التوجيه يحتاج إلى استيعاب الشبكات الفرعية خلف هذه الاتصالات أيضًا. على الرغم من عدم وجود فرق كبير في اتصال الشبكة الفرعية B/C، يوجد في تصميم نسبة استخدام الشبكة المرتاد، وإكمال الصورة:
في هذه البنية، سيتم إرسال نسبة استخدام الشبكة التي تصل إلى جدار الحماية من، على سبيل المثال الشبكة الفرعية-B إلى الشبكة الفرعية-X إلى موازن التحميل، والذي بدوره يرسلها إلى أي من جداري الحماية. سيرسل المسار الداخلي داخل جدار الحماية نسبة استخدام الشبكة مرة أخرى إلى الشبكة الفرعية-البوابة (IP المتوفر أولًا في الشبكة الفرعية-D). لا يتعين عليك إرسال نسبة استخدام الشبكة مباشرةً إلى جهاز البوابة نفسه، حيث سيتوفر مسار آخر على الشبكة الفرعية D لتوجيه الشبكة الفرعية-X إلى بوابة الشبكة الظاهرية. ستهتم Azure Networking بالتوجيه الفعلي.
ستتم إعادة توجيه نسبة استخدام الشبكة العائدة القادمة من الشبكة الفرعية-X إلى موازن التحميل في الشبكة الفرعية-D. سيكون لدى الشبكة الفرعية للبوابة أيضًا مسار مخصص يشير الشبكة الفرعية-B-C إلى موازن التحميل. الشبكة الفرعية D ليست عبر موزان التحميل. سيتم التعامل مع هذا على أنه توجيه منتظم بين الشبكة الظاهرية.
في حين أنه ليس في الرسم، من المنطقي أن تتضمن الشبكة الفرعية-B/C/D/البوابة أيضًا مسارًا للشبكة الفرعية A يشير إلى موازن التحميل. يتجنب هذا الترتيب توجيه الشبكة الظاهرية «المنتظمة» لتجاوز جدران الحماية. هذا كـ الشبكة الفرعية-A هو مجرد شبكة فرعية أخرى في الشبكات الظاهرية وفقًا لمُكدس شبكة Azure. لن يتعامل مع الشبكة الفرعية-A مختلف، على الرغم من أنك تعامله على أنه DMZ/Internet/etc.
الملخص
باختصار، الطريقة التي تتعامل بها مع جدران الحماية في الشبكات المحلية (المستندة إلى VLAN/ الفعلية)، مع العديد من الواجهات (الظاهرية أو المادية) ليست هي ذاتها كما تفعل في Azure. إذا لزم الأمر، فلا يزال بإمكانك (إلى حد ما)، ولكن ثمة طرق أفضل للتأكد من أنه يمكنك تقليل وقت التوقف عن العمل بسبب الفشل؛ لديك تطبيقات نشطة-نشطة وجداول توجيه نظيفة.
يُمكن العثور على مزيد من المعلومات حول استخدام موازنات التحميل كبوابات لجميع نسبة استخدام الشبكة في نظرة عامة على منافذ قابلية الوصول العالية.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- رولف زوميرمان | مهندس حلول سحابي أول
الخطوات التالية
تعرف على المزيد حول تقنيات المكونات:
الموارد ذات الصلة
استكشاف البنى ذات الصلة: