تكوين البنية الأساسية لبوابة التطبيق
تتضمن البنية الأساسية لبوابة تطبيق Azure الشبكة الظاهرية والشبكات الفرعية ومجموعات أمان الشبكة (NSGs) والمسارات المعرفة من قبل المستخدم (UDRs).
الشبكة الظاهرية والشبكة الفرعية المخصصة
بوابة تطبيق عبارة عن توزيع مخصص في الشبكة الظاهرية الخاصة بك. تُطلب شبكة فرعية مخصصة، ضمن نطاق الشبكة الظاهرية لبوابة التطبيق. يمكن أن يكون لديك مثيلات متعددة لنشر Application Gateway معينة في شبكة فرعية. يمكنك أيضًا توزيع بوابات تطبيق أخرى في الشبكة الفرعية. ولكن لا يمكنك نشر أي مورد آخر في الشبكة الفرعية لبوابة التطبيق. لا يمكنك خلط v1 وv2 Application Gateway SKUs على نفس الشبكة الفرعية.
إشعار
نُهج نقطة نهاية خدمة الشبكة الظاهرية غير مدعومة حالياً في الشبكة الفرعية لـ Application Gateway.
حجم الشبكة الفرعية
تستخدم بوابة التطبيق عنوان IP خاصا واحدا لكل مثيل، بالإضافة إلى عنوان IP خاص آخر إذا تم تكوين IP واجهة أمامية خاصة.
يحتفظ Azure أيضا بخمسة عناوين IP في كل شبكة فرعية للاستخدام الداخلي. إنها العناوين الأربعة الأولى وعناوين IP الأخيرة. على سبيل المثال، ضع في اعتبارك 15 مثيلا لبوابة التطبيق بدون عنوان IP خاص للواجهة الأمامية. تحتاج إلى 20 عنوان IP على الأقل لهذه الشبكة الفرعية. تحتاج إلى 5 للاستخدام الداخلي و15 لمثيلات Application Gateway.
ضع في اعتبارك شبكة فرعية تحتوي على 27 مثيلا لبوابة التطبيق وعنوان IP لعنوان IP خاص للواجهة الأمامية. في هذه الحالة، تحتاج إلى 33 عنوان IP. تحتاج إلى 27 لمثيلات بوابة التطبيق، واحد للواجهة الأمامية الخاصة، و5 للاستخدام الداخلي.
يمكن أن تدعم Application Gateway (Standard أو WAF SKU) ما يصل إلى 32 مثيلا (32 عنوان IP للمثيل + تكوين IP خاص للواجهة الأمامية + 5 Azure محجوز). نوصي بحد أدنى لحجم الشبكة الفرعية من /26.
يمكن أن تدعم بوابة التطبيق (Standard_v2 أو WAF_v2 SKU) ما يصل إلى 125 مثيلا (125 عنوان IP للمثيل + تكوين IP خاص للواجهة الأمامية + 5 Azure محجوز). نوصي بحد أدنى لحجم الشبكة الفرعية من /24.
لتحديد السعة المتاحة لشبكة فرعية تحتوي على بوابات تطبيق موجودة تم توفيرها، خذ حجم الشبكة الفرعية واطرح عناوين IP الخمسة المحجوزة للشبكة الفرعية المحجوزة بواسطة النظام الأساسي. بعد ذلك، خذ كل بوابة واطرح الحد الأقصى لعدد المثيلات. لكل بوابة تحتوي على تكوين IP خاص للواجهة الأمامية، اطرح عنوان IP آخر لكل بوابة.
على سبيل المثال، إليك كيفية حساب العناوين المتوفرة لشبكة فرعية بثلاث بوابات ذات أحجام مختلفة:
- البوابة 1: بحد أقصى 10 مثيلات. يستخدم تكوين IP للواجهة الأمامية الخاصة.
- البوابة 2: مثيلان كحد أقصى. لا يوجد تكوين IP للواجهة الأمامية الخاصة.
- البوابة 3: بحد أقصى 15 مثيلا. يستخدم تكوين IP للواجهة الأمامية الخاصة.
- حجم الشبكة الفرعية: /24
- حجم الشبكة الفرعية /24 = 256 عنوان IP - 5 محجوزة من النظام الأساسي = 251 عنوانا متوفرا
- 251: البوابة 1 (10) - تكوين IP للواجهة الأمامية الخاصة = 240
- 240: البوابة 2 (2) = 238
- 238: البوابة 3 (15) - تكوين IP للواجهة الأمامية الخاصة = 222
هام
على الرغم من أن الشبكة الفرعية /24 غير مطلوبة لكل نشر Application Gateway v2 SKU، نوصي بشدة بذلك. تضمن الشبكة الفرعية /24 أن Application Gateway v2 لديها مساحة كافية لترقيات التوسع والصيانة للتحجيم التلقائي.
يجب التأكد من أن شبكة بوابة التطبيق الفرعية V2 تمتلك مساحة عنوان كافية لاستيعاب عدد المثيلات المطلوبة لخدمة الحد الأقصى المتوقع من نسبة استخدام الشبكة. إذا قمت بتحديد الحد الأقصى لعدد المثيلات، يجب أن يكون للشبكة الفرعية سعة لهذا العدد من العناوين على الأقل. لتخطيط السعة حول عدد المثيلات، راجع تفاصيل عدد المثيلات.
الشبكة الفرعية المسماة GatewaySubnet محجوزة لبوابات VPN. يجب نقل موارد Application Gateway v1 التي تستخدم GatewaySubnet الشبكة الفرعية إلى شبكة فرعية مختلفة أو ترحيلها إلى v2 SKU قبل 30 سبتمبر 2023، لتجنب فشل وحدة التحكم وعدم تناسق النظام الأساسي. للحصول على معلومات حول تغيير الشبكة الفرعية لمثيل Application Gateway موجود، راجع الأسئلة المتداولة حول بوابة التطبيق.
تلميح
يتم تخصيص عناوين IP من بداية مساحة الشبكة الفرعية المعرفة لمثيلات البوابة. كما يتم إنشاء المثيلات وإزالتها بسبب إنشاء البوابات أو أحداث التحجيم، قد يصبح من الصعب فهم العنوان المتوفر التالي في الشبكة الفرعية. لكي تتمكن من تحديد العنوان التالي لاستخدامه في بوابة مستقبلية ولديك نسق عنوان متقارب لعناوين IP الأمامية، ضع في اعتبارك تعيين عناوين IP للواجهة الأمامية من النصف العلوي من مساحة المجموعة الفرعية المحددة.
على سبيل المثال، إذا كانت مساحة عنوان الشبكة الفرعية هي 10.5.5.0/24، ضع في اعتبارك تعيين تكوين IP للواجهة الأمامية الخاصة للبوابات الخاصة بك بدءا من 10.5.5.254 ثم المتابعة مع 10.5.5.253 و10.5.5.252 و10.5.5.251 وما إلى ذلك للبوابات المستقبلية.
من الممكن تغيير الشبكة الفرعية لمثيل Application Gateway موجود داخل نفس الشبكة الظاهرية. لإجراء هذا التغيير، استخدم Azure PowerShell أو Azure CLI. للحصول على مزيدٍ من المعلومات، راجع الأسئلة المتداولة حول بوابة التطبيقات.
خوادم DNS لتحليل الاسم
يدعم مورد الشبكة الظاهرية تكوين خادم DNS، والذي يسمح لك للاختيار بين خوادم DNS الافتراضية أو المخصصة التي توفرها Azure. تحترم مثيلات بوابة التطبيق أيضا تكوين DNS هذا لأي تحليل للاسم. بعد تغيير هذا الإعداد، يجب إعادة تشغيل (إيقاف وبدء) بوابة التطبيق لكي تسري هذه التغييرات على المثيلات.
عندما يصدر مثيل Application Gateway استعلام DNS، فإنه يستخدم القيمة من الخادم الذي يستجيب أولا.
إشعار
إذا كنت تستخدم خوادم DNS مخصصة في الشبكة الظاهرية لبوابة التطبيق، يجب أن يكون خادم DNS قادرا على حل أسماء الإنترنت العامة. تتطلب بوابة التطبيق هذه الإمكانية.
إذن الشبكة الظاهرية
يتم نشر مورد Application Gateway داخل شبكة ظاهرية، لذلك يتم أيضا إجراء عمليات التحقق للتحقق من الإذن على مورد الشبكة الظاهرية. يتم إجراء هذا التحقق من الصحة أثناء كل من عمليات الإنشاء والإدارة وينطبق أيضا على الهويات المدارة لوحدة تحكم دخول بوابة التطبيق.
تحقق من التحكم في الوصول المستند إلى دور Azure للتحقق من أن المستخدمين ومديري الخدمة الذين يشغلون بوابات التطبيق لديهم على الأقل الأذونات التالية على الشبكة الظاهرية أو الشبكة الفرعية:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
يمكنك استخدام الأدوار المضمنة، مثل مساهم الشبكة، التي تدعم هذه الأذونات بالفعل. إذا لم يوفر الدور المضمن الإذن المناسب، يمكنك إنشاء دور مخصص وتعيينه. تعرف على المزيد حول إدارة أذونات الشبكة الفرعية.
إشعار
قد تضطر إلى السماح بوقت كاف لتحديث ذاكرة التخزين المؤقت ل Azure Resource Manager بعد تغيير تعيين الدور.
تحديد المستخدمين المتأثرين أو كيانات الخدمة لاشتراكك
من خلال زيارة Azure Advisor لحسابك، يمكنك التحقق مما إذا كان اشتراكك يحتوي على أي مستخدمين أو كيانات خدمة بإذن غير كاف. وفيما يلي تفاصيل تلك التوصية:
العنوان: تحديث إذن VNet لمستخدمي
بوابة التطبيق الفئة: تأثير الموثوقية
: عال
استخدام علامة التحكم المؤقت في التعرض لميزة Azure (AFEC)
كملحق مؤقت، قدمنا التحكم في التعرض لميزة Azure على مستوى الاشتراك (AFEC). يمكنك التسجيل في AFEC واستخدامه حتى تقوم بإصلاح الأذونات لجميع المستخدمين وكيانات الخدمة. سجل للحصول على الميزة باتباع نفس الخطوات مثل تسجيل ميزة المعاينة لاشتراك Azure الخاص بك.
الاسم: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Description: Disable Application Gateway Subnet Permission Check
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
إشعار
نقترح استخدام توفير AFEC فقط كتخفيف مؤقت حتى تقوم بتعيين الإذن الصحيح. يجب تحديد أولويات إصلاح الأذونات لجميع المستخدمين القابلين للتطبيق (وكيانات الخدمة) ثم إلغاء تسجيل علامة AFEC هذه لإعادة تقديم التحقق من الإذن على مورد الشبكة الظاهرية. نوصي بعدم الاعتماد على أسلوب AFEC هذا بشكل دائم لأنه ستتم إزالته في المستقبل.
Azure Virtual Network Manager
Azure Virtual Network Manager هي خدمة إدارة تسمح لك بتجميع الشبكات الظاهرية وتكوينها ونشرها وإدارتها عالميا عبر الاشتراكات. باستخدام Virtual Network Manager، يمكنك تعريف مجموعات الشبكة لتحديد الشبكات الظاهرية وتقسيمها منطقيًّا. بعد ذلك، يمكنك تحديد تكوينات الاتصال والأمان التي تريدها وتطبيقها عبر جميع الشبكات الظاهرية المحددة في مجموعات الشبكة في وقت واحد.
يسمح لك تكوين قاعدة مسؤول الأمان في Azure Virtual Network Manager بتحديد نهج الأمان على نطاق واسع وتطبيقها على شبكات ظاهرية متعددة في وقت واحد.
إشعار
تنطبق قواعد مسؤول الأمان الخاصة ب Azure Virtual Network Manager فقط على الشبكات الفرعية لبوابة التطبيق التي تحتوي على بوابات التطبيق مع تمكين عزل الشبكة. لا تحتوي الشبكات الفرعية مع بوابات التطبيق التي تم تعطيل عزل الشبكة عليها على قواعد مسؤول الأمان.
مجموعات أمان الشبكة
يمكنك استخدام مجموعات أمان الشبكة للشبكة الفرعية لبوابة التطبيق، ولكن كن على دراية ببعض النقاط والقيود الرئيسية.
هام
يتم تخفيف قيود NSG هذه عند استخدام نشر بوابة التطبيق الخاصة (معاينة).
قواعد الأمان المطلوبة
لاستخدام NSG مع بوابة التطبيق الخاصة بك، تحتاج إلى إنشاء أو الاحتفاظ ببعض قواعد الأمان الأساسية. يمكنك تعيين أولويتها بنفس الترتيب.
القواعد الواردة
نسبة استخدام الشبكة للعميل: السماح بنسبة استخدام الشبكة الواردة من العملاء المتوقعين (ك IP المصدر أو نطاق IP)، وللوجهة كبادئة IP للشبكة الفرعية بأكملها لبوابة التطبيق ومنافذ الوصول الواردة. على سبيل المثال، إذا كان لديك وحدات استماع مكونة للمنافذ 80 و443، يجب السماح بهذه المنافذ. يمكنك أيضا تعيين هذه القاعدة إلى Any.
| المصدر | منافذ المصدر | الوجهة | منافذ الوجهة | البروتوكول | Access |
|---|---|---|---|---|---|
<as per need> |
أي | <Subnet IP Prefix> |
<listener ports> |
TCP | السماح |
بعد تكوين وحدات الاستماع العامة والخاصة النشطة (مع القواعد) مع نفس رقم المنفذ، تغير بوابة التطبيق وجهة جميع التدفقات الواردة إلى عناوين IP الأمامية للبوابة الخاصة بك. يحدث هذا التغيير حتى بالنسبة للمستمعين الذين لا يشاركون أي منفذ. يجب تضمين عناوين IP العامة والخاصة للبوابة في وجهة القاعدة الواردة عند استخدام نفس تكوين المنفذ.
| المصدر | منافذ المصدر | الوجهة | منافذ الوجهة | البروتوكول | Access |
|---|---|---|---|---|---|
<as per need> |
أي | <Public and Private<br/>frontend IPs> |
<listener ports> |
TCP | السماح |
منافذ البنية الأساسية: السماح بالطلبات الواردة من المصدر كعلامة خدمة GatewayManager وأي وجهة. يختلف نطاق منفذ الوجهة استنادا إلى SKU وهو مطلوب لتوصيل حالة صحة الواجهة الخلفية. هذه المنافذ محمية/مؤمنة بواسطة شهادات Azure. لا يمكن للكيانات الخارجية بدء التغييرات على نقاط النهاية هذه دون وجود شهادات مناسبة.
- الإصدار 2: المنافذ 65200-65535
- الإصدار 1: المنافذ 65503-65534
| المصدر | منافذ المصدر | الوجهة | منافذ الوجهة | البروتوكول | Access |
|---|---|---|---|---|---|
| GatewayManager | أي | أي | <as per SKU given above> |
TCP | السماح |
تحقيقات Azure Load Balancer: السماح بنسبة استخدام الشبكة الواردة من المصدر كعلامة خدمة AzureLoadBalancer . يتم إنشاء هذه القاعدة بشكل افتراضي ل NSGs. يجب عدم تجاوزها باستخدام قاعدة رفض يدوية لضمان العمليات السلسة لبوابة التطبيق.
| المصدر | منافذ المصدر | الوجهة | منافذ الوجهة | البروتوكول | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | أي | أي | أي | أي | السماح |
يمكنك حظر كل حركة المرور الواردة الأخرى باستخدام قاعدة رفض الكل .
القواعد الخارجية
الصادرة إلى الإنترنت: السماح بنسبة استخدام الشبكة الصادرة إلى الإنترنت لجميع الوجهات. يتم إنشاء هذه القاعدة بشكل افتراضي ل NSGs. يجب عدم تجاوزها باستخدام قاعدة رفض يدوية لضمان العمليات السلسة لبوابة التطبيق. يجب عدم إنشاء قواعد NSG الصادرة التي ترفض أي اتصال صادر.
| المصدر | منافذ المصدر | الوجهة | منافذ الوجهة | البروتوكول | Access |
|---|---|---|---|---|---|
| أي | أي | الإنترنت | أي | أي | السماح |
إشعار
لا تسمح بوابات التطبيق التي لم يتم تمكين "عزل الشبكة" بإرسال نسبة استخدام الشبكة بين الشبكات الظاهرية النظيرة عند تعطيل السماح بنسبة استخدام الشبكة إلى الشبكة الظاهرية البعيدة.
مسارات مدعومة ومعرفة من قبل المستخدم
التحكم الدقيق في الشبكة الفرعية لبوابة التطبيق عبر قواعد جدول التوجيه ممكن في المعاينة العامة. لمزيد من المعلومات، راجع نشر بوابة التطبيق الخاصة (معاينة).
مع الوظائف الحالية، هناك بعض القيود:
هام
قد يؤدي استخدام UDRs على الشبكة الفرعية لبوابة التطبيق إلى ظهور الحالة الصحية في طريقة العرض الصحية الخلفية على أنها غير معروفة. كما قد يتسبب في فشل إنشاء تسجيلات بوابة التطبيق والمقاييس. نوصي بعدم استخدام UDRs على الشبكة الفرعية لبوابة التطبيق بحيث يمكنك عرض صحة الخلفية والسجلات والمقاييس.
v1: بالنسبة ل v1 SKU، يتم دعم UDRs على الشبكة الفرعية لبوابة التطبيق إذا لم تغير اتصال الطلب/الاستجابة من طرف إلى طرف. على سبيل المثال، يمكنك إعداد UDR في الشبكة الفرعية لبوابة التطبيق للإشارة إلى جهاز جدار حماية لفحص حزمة البيانات. ولكن يجب التأكد من إمكانية وصول حزمة البيانات إلى وجهتها المقصودة بعد الفحص. قد يؤدي الفشل في القيام بذلك إلى سلوك غير صحيح في فحص الصحة أو سلوك توجيه نسبة استخدام الشبكة. يتم أيضا تضمين المسارات المستفادة أو التوجيهات الافتراضية 0.0.0.0/0 التي يتم نشرها بواسطة Azure ExpressRoute أو بوابات VPN في الشبكة الظاهرية.
v2: بالنسبة إلى v2 SKU، هناك سيناريوهات مدعومة وغير مدعومة.
سيناريوهات v2 المدعومة
تحذير
قد يؤدي أي تكوين غير صحيح لجدول التوجيه إلى توجيه غير متماثل في بوابة التطبيق V2. تأكد من إرسال جميع حركة مرور وحدة الإدارة/التحكم مباشرة إلى الإنترنت وليس من خلال جهاز ظاهري. يمكن أيضا أن يتأثر التسجيل والمقاييس وفحوصات CRL.
السيناريو 1: UDR لتعطيل نشر مسار بروتوكول بوابة الحدود (BGP) إلى الشبكة الفرعية لبوابة التطبيق
يتم أحيانًا الإعلان عن مسار البوابة الافتراضية (0.0.0.0/0) عبر بوابات ExpressRoute أو VPN المقترنة بالشبكة الظاهرية لبوابة التطبيق. هذا السلوك يكسر حركة مرور مستوى الإدارة، ما يتطلب مسارا مباشرا إلى الإنترنت. في مثل هذه السيناريوهات، يمكنك استخدام UDR لتعطيل نشر مسار BGP.
لتعطيل نشر مسار BGP:
- إنشاء مورد جدول توجيه في Azure.
- قم بتعطيلمعلمات نشر مسار بوابة الشبكة الظاهرية.
- إقران جدول التوجيه بالشبكة الفرعية المناسبة.
يجب ألا يتسبب تمكين UDR لهذا السيناريو في مقاطعة أي إعدادات موجودة.
السيناريو 2: UDR لتوجيه 0.0.0.0/0 إلى الإنترنت
يمكنك إنشاء UDR لإرسال نسبة استخدام الشبكة 0.0.0.0/0 مباشرة إلى الإنترنت.
السيناريو 3: UDR لخدمة Azure Kubernetes (AKS) مع kubenet
إذا كنت تستخدم kubenet مع AKS ووحدة تحكم دخول بوابة التطبيق، فأنت بحاجة إلى جدول توجيه للسماح بتوجيه نسبة استخدام الشبكة المرسلة إلى pods من Application Gateway إلى العقدة الصحيحة. لا تحتاج إلى استخدام جدول توجيه إذا كنت تستخدم واجهة شبكة حاويات Azure.
لاستخدام جدول التوجيه للسماح ل kubenet بالعمل:
انتقل إلى مجموعة الموارد التي تم إنشاؤها بواسطة AKS. يجب أن يبدأ اسم مجموعة الموارد ب
MC_.ابحث عن جدول التوجيه الذي أنشأته AKS في مجموعة الموارد هذه. يجب تجهيز جدول التوجيه بالمعلومات التالية:
- يجب أن تكون بادئة العنوان هي نطاق IP للأنظمة التي تريد الوصول إليها في AKS.
- يجب أن يكون نوع الوثب التالي جهازا ظاهريا.
- يجب أن يكون عنوان الوثب التالي عبارة عن عنوان IP للعقدة التي تستضيف الأنظمة.
قم بإقران جدول التوجيه هذا إلى الشبكة الفرعية لبوابة التطبيق.
سيناريوهات v2 غير مدعومة
السيناريو 1: UDR للأجهزة الظاهرية
أي سيناريو يحتاج فيه 0.0.0.0/0 إلى إعادة توجيهه من خلال جهاز ظاهري أو شبكة ظاهرية مركزية/محورية أو محلية (نفق إجباري) غير مدعوم للإصدار 2.