الأسئلة المتداولة حول Application Gateway

توفر بوابة تطبيق Azure وحدة تحكم تسليم التطبيق كخدمة. وهي توفر مختلف قدرات موازنة أعباء الطبقة 7 للتطبيقات الخاصة بك. هذه الخدمة متاحة للغاية وقابلة للتطوير، وهي خدمة مدارة بشكل كامل بواسطة Azure.

Application Gateway تدعم التحجيم التلقائي وتفريغ TLS، وTLS من طرف إلى طرف، وجدار حماية تطبيق ويب (WAF)، وتقارب جلسة العمل المستندة إلى ملفات تعريف الارتباط، والتوجيه القائم على مسار URL، واستضافة المواقع المتعددة، وميزات أخرى. للحصول على قائمة كاملة من الميزات المعتمدة، راجع مقدمة إلى Application Gateway.

Application Gateway هي موازن تحميل في الطبقة 7، مما يعني أنها تعمل فقط مع استخدام شبكة الويب (HTTP وHTTPS وWebSocket وHTTP/2). وتدعم قدرات مثل إنهاء TLS، وترابط جلسة العمل المستندة إلى ملفات تعريف الارتباط، والترتيب الدوري لاستخدام الشبكة في موازنة التحميل. Load Balancer يعمل على توازن تحميل استخدام الشبكة في الطبقة 4 (TCP أو UDP).

Application Gateway تدعم HTTP وHTTPS وHTTP/2 وWebSocket.

راجع دعم HTTP/2.

راجع موارد الواجهة الخلفية المدعومة.

تطبيق Application Gateway v1 (Standard وWAF) متوفر في جميع مناطق Azure على مستوى العالم. كما أنها متاحة في Microsoft Azure التي تديرها 21Vianet وAzure Government.

للحصول على توفر Application Gateway v2 (Standard_v2 و WAF_v2)، راجع المناطق المدعومة ل Application Gateway v2.

Application Gateway هو نشر مخصص في الشبكة الظاهرية لديك.

إعادة التوجيه مدعومة. راجع نظرة عامة حول إعادة التوجيه في Application Gateway.

راجع ترتيب معالجة وحدات الاستماع.

إذا كنت تستخدم عنوان IP عاما كنقطة نهاية، فستجد معلومات IP وDNS على مورد عنوان IP العام. أو يمكنك العثور عليه في مدخل Microsoft Azure، في صفحة النظرة العامة لبوابة التطبيق. إذا كنت تستخدم عناوين IP داخلية، فابحث عن المعلومات في صفحة النظرة العامة. بالنسبة إلى v1 SKU، لن يكون للبوابات التي تم إنشاؤها بعد 1 مايو 2023 اسم DNS افتراضي مقترن تلقائيا بمورد IP العام. بالنسبة إلى V2 SKU، افتح مورد IP العام وحدد تكوين. يتوفر الحقل تسمية DNS (اختياري) لتكوين اسم DNS.

Keep-Alive تحكم المهلة المدة التي تنتظرها بوابة التطبيق للعميل لإرسال طلب HTTP آخر على اتصال مستمر قبل إعادة استخدامه أو إغلاقه. تحكم مهلة الخمول TCP المدة التي يتم فيها الاحتفاظ باتصال TCP مفتوحا إذا لم يكن هناك نشاط.

المهلة Keep-Alive في Application Gateway v1 SKU هي 120 ثانية وفي v2 SKU تكون 75 ثانية. بالنسبة لعناوين IP الخاصة، تكون القيمة غير قابلة للتكوين مع مهلة الخمول TCP لمدة 5 دقائق. مهلة خمول TCP تبلغ افتراضيًا 4 دقائق على IP الظاهري الأمامي (VIP) لكل من V1 وV2 SKU من Application Gateway. يمكنك تكوين قيمة مهلة الخمول TCP على مثيلات v1 وv2 Application Gateway لتكون في أي مكان بين 4 دقائق و30 دقيقة. لكل من مثيلات بوابة التطبيق v1 وv2، تحتاج إلى الانتقال إلى IP العام لبوابة التطبيق وتغيير مهلة الخمول TCP ضمن جزء التكوين من IP العام في المدخل. يمكنك تعيين قيمة مهلة خمول TCP من IP العام من خلال PowerShell بواسطة تشغيل الأوامر التالية:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

بالنسبة لاتصالات HTTP/2 بعنوان IP الأمامي على Application Gateway v2 SKU، يتم تعيين مهلة الخمول إلى 180 ثانية وهي غير قابلة للتكوين.

نعم. تعيد بوابة التطبيق استخدام اتصالات TCP الموجودة مع خادم الواجهة الخلفية.

‏‏لا. لا توجد طريقة لإعادة تسمية مورد Application Gateway. يجب عليك إنشاء مورد جديد باسم مختلف.

‏‏لا. لا توجد طريقة لاستعادة مورد Application Gateway أو عنوان IP العام الخاص به بعد الحذف. يجب إنشاء مصدر جديد.

في Application Gateway v1 SKU، يمكن تغيير VIP إذا قمت بإيقاف وبدء تشغيل بوابة التطبيق. ولكن اسم DNS المقترن ببوابة التطبيقات لا يتغير خلال عمر البوابة. لأنه لا يتم تغيير اسم DNS يجب استخدام اسم مستعار CNAME والإشارة إليه في عنوان DNS من بوابة التطبيقات. في Application Gateway v2 SKU، تكون عناوين IP ثابتة، لذلك لن يتغير عنوان IP واسم DNS على مدى عمر بوابة التطبيق.

نعم. يدعم Application Gateway v2 SKU عناوين IP العامة الثابتة وعناوين IP الداخلية الثابتة. يدعم V1 SKU عناوين IP الداخلية الثابتة.

تدعم بوابة التطبيق عنوان IP عاما واحدا فقط لكل بروتوكول IP. إذا تم تكوين بوابة التطبيق ك DualStack، فيمكنها دعم اثنين من عناوين IP العامة، أحدهما ل IPv4 والآخر ل IPv6.

راجع اعتبارات حجم الشبكة الفرعية في Application Gateway.

نعم. إضافة إلى مثيلات متعددة من نشر Application Gateway معين، يمكنك توفير مورد Application Gateway آخر فريد إلى شبكة فرعية موجودة تحتوي على مورد Application Gateway مختلف.

لا يمكن أن تدعم شبكة فرعية واحدة كلاً من V2 وV1 من Application Gateway SKUs.

نعم، ولكن سيناريوهات محددة فقط. لمزيد من المعلومات، راجع تكوين البنية الأساسية لـ Application Gateway.

نعم. راجع التعديلات على طلب.

يمكن أن تستغرق عمليات نشر Application Gateway v1 SKU الجديدة ما يصل إلى 20 دقيقة لتوفيرها. التغييرات في حجم المثيل أو العدد غير معطِّلة، وتظل البوابة نشطة خلال هذا الوقت.

تستغرق معظم عمليات النشر التي تستخدم V2 SKU حوالي 6 دقائق لتوفيرها. ومع ذلك، قد تستغرق العملية وقتا أطول اعتمادا على نوع التوزيع. على سبيل المثال، يمكن أن تستغرق عمليات التوزيع عبر مناطق توفر متعددة مع العديد من المثيلات أكثر من 6 دقائق.

يتم تطبيق التحديثات التي تم بدؤها على Application Gateway على مجال تحديث واحد في كل مرة. أثناء تحديث كل مثيلات مجال التحديث، تستمر المثيلات المتبقية في مجالات التحديث الأخرى في خدمة نسبة استخدام الشبكة¹. يتم استنزاف الاتصالات النشطة بأمان من المثيلات التي يتم تحديثها لمدة تصل إلى 5 دقائق للمساعدة في إنشاء اتصال بالمثيلات في مجال تحديث مختلف قبل بدء التحديث. أثناء التحديث، تعمل Application Gateway مؤقتا بأقصى سعة مخفضة، والتي يتم تحديدها من خلال عدد المثيلات التي تم تكوينها. تنتقل عملية التحديث إلى المجموعة التالية من المثيلات فقط إذا تمت ترقية المجموعة الحالية من المثيلات بنجاح.

¹ نوصي بحد أدنى لعدد المثيلات 2 ليتم تكوينه لتوزيع Application Gateway v1 SKU لضمان أن مثيل واحد على الأقل يمكن أن يخدم نسبة استخدام الشبكة أثناء تطبيق التحديثات.

تدعم بوابة التطبيق وكيل بروتوكول TLS/TCP من خلال وكيل الطبقة 4 في المعاينة.

لن يدعم وكيل الطبقة 7 لبوابة التطبيق مع بروتوكولات HTTP(S) بروتوكولات البريد الإلكتروني مثل SMTP وIMAP وPOP3. ومع ذلك، بالنسبة لبعض خدمات البريد الإلكتروني الداعمة، مثل Outlook Web Access (OWA) وActiveSync وحركة مرور AutoDiscovery التي تستخدم بروتوكولات HTTP(S)، يمكنك استخدام وكيل الطبقة 7، ويجب أن تتدفق نسبة استخدام الشبكة الخاصة بها. (ملاحظة: قد تكون الاستثناءات في قواعد WAF مطلوبة عند استخدام WAF SKU).

نعم. لمزيد من المعلومات، راجع ترحيل بوابة تطبيق Azure وجدار حماية تطبيق الويب من الإصدار 1 إلى الإصدار 2.

نعم. يستمر دعم Application Gateway v1 SKU. نوصي بشدة بالانتقال إلى الإصدار 2 للاستفادة من تحديثات الميزات في وحدة SKU هذه. لمزيد من المعلومات حول الاختلافات بين ميزات v1 وv2، راجع التحجيم التلقائي وApplication Gateway v2 المكررة في المنطقة. يمكنك ترحيل عمليات نشر Application Gateway v1 SKU يدويا إلى الإصدار 2 باتباع مستند ترحيل v1-v2.

‏‏لا. لا يدعم Application Gateway v2 طلبات الوكيل مع مصادقة NTLM أو Kerberos.

يمكن أن تحتوي أسماء عناوين الطلب على أحرف أبجدية رقمية وواصلات. يتم تجاهل أسماء عناوين الطلب التي تحتوي على أحرف أخرى عند إرسال طلب إلى هدف الواجهة الخلفية. يمكن أن تحتوي أسماء عناوين الاستجابة على أي أحرف أبجدية رقمية ورموز محددة كما هو محدد في RFC 7230.

نعم. قدم تحديث متصفح Chromium v80 تفويضا على ملفات تعريف الارتباط HTTP دون سمة SameSite ليتم التعامل معها على أنها SameSite=Lax. وهو ما يعني أنه لن يتم إرسال ملف تعريف ارتباط تقارب Application Gateway من قبل المستعرض في سياق جهة خارجية.

لدعم هذا السيناريو، تقوم بوابة التطبيق بإدخال ملف تعريف ارتباط آخر يسمى ApplicationGatewayAffinityCORS بالإضافة إلى ملف تعريف الارتباط الموجود ApplicationGatewayAffinity . ملفات تعريف الارتباط هذه متشابهة، ولكن ApplicationGatewayAffinityCORS ملف تعريف الارتباط يحتوي على سمتين إضافيتين تمت إضافتهما إليه: SameSite=None و Secure. تحافظ هذه السمات على جلسات عمل مثبتة حتى بالنسبة للطلبات عبر الأصل. لمزيد من المعلومات، راجع قسم الترابط المستند إلى ملف تعريف الارتباط.

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

يدعم Application Gateway v1 SKU سيناريوهات توفر عالٍ عند نشر مثيلين أو أكثر. يوزع Azure هذه المثيلات عبر مجالات التحديث والخطأ لضمان عدم فشل المثيلات جميعها في نفس الوقت. يدعم V1 SKU قابلية التوسع عن طريق إضافة مثيلات متعددة من نفس البوابة لمشاركة التحميل.

يضمن V2 SKU نشر المثيلات الجديدة تلقائيًا عبر مجالات الخطأ ومجالات التحديث. إذا اخترت تكرار المناطق، فإن أحدث المثيلات تنتشر أيضًا عبر مناطق التوفر لتوفير مرونة فشل المناطق.

استخدم Azure Traffic Manager لتوزيع نسبة استخدام الشبكة عبر بوابات تطبيقات متعددة في مراكز بيانات مختلفة.

نعم. يمكنك إعداد استنفاد الاتصال لتغيير الأعضاء داخل تجمع واجهة الخلفية دون تعطيل. لمزيد من المعلومات، راجع قسم استنزاف الاتصال في بوابة التطبيق.

نعم، يدعم Application Gateway v2 SKU التحجيم التلقائي. لمزيد من المعلومات، راجع التحجيم التلقائي وبوابة التطبيق المكررة للمنطقة.

‏‏لا. يتم توزيع المثيلات عبر مجالات الترقية ومجالات الخطأ.

نعم.

نعم.

نعم. يتم نشر Application Gateway دائمًا في شبكة فرعية لشبكة ظاهرية. يمكن أن تحتوي هذه الشبكة الفرعية على بوابات تطبيقات فقط. لمزيد من المعلومات، راجع متطلبات الشبكة الظاهرية والشبكة الفرعية.

إذا كان لديك اتصال IP، يمكن ل Application Gateway الاتصال بمثيلات خارج الشبكة الظاهرية الموجودة فيها. يمكن لـ Application Gateway أيضًا التواصل مع مثيلات خارج اشتراكها. إذا كنت تخطط لاستخدام عناوين IP داخلية كأعضاء تجمع واجهات خلفية، فاستخدم الشبكة الظاهرية للتناظر أو Azure VPN Gateway.

مثل أي محلل DNS، يكرم مورد Application Gateway قيمة مدة البقاء (TTL) لسجل DNS الخاص بالخادم الخلفي. بعد انتهاء صلاحية TTL، تقوم البوابة بإجراء بحث لتحديث معلومات DNS هذه. أثناء هذا البحث، إذا واجهت بوابة التطبيق مشكلة في الحصول على استجابة (أو لم يتم العثور على سجل DNS)، تستمر البوابة في استخدام آخر قيمة DNS جيدة معروفة لخدمة نسبة استخدام الشبكة. لمزيد من المعلومات، راجع عمليات كيفية عمل بوابة التطبيق.

تستخدم مثيلات بوابة التطبيق تكوين DNS للشبكة الظاهرية لتحليل الاسم. بعد تغيير أي تكوين لخادم DNS، تحتاج إلى إعادة تشغيل (إيقاف وبدء) بوابة التطبيق لخوادم DNS الجديدة لتعيينها. حتى ذلك الحين، قد تفشل تحليلات الأسماء المستندة إلى FQDN للاتصال الصادر.

‏‏لا. ولكن يمكنك نشر بوابات تطبيقات أخرى في الشبكة الفرعية.

يمكنك نقل بوابة تطبيق عبر الشبكات الفرعية داخل نفس الشبكة الظاهرية فقط. وهو مدعوم مع v1 مع واجهة أمامية عامة وخاصة (تخصيص ديناميكي) وv2 مع واجهة أمامية عامة فقط. لا يمكننا نقل بوابة التطبيق إلى شبكة فرعية أخرى إذا تم تخصيص تكوين IP للواجهة الأمامية الخاصة بشكل ثابت. يجب أن تكون بوابة التطبيق في حالة توقف لتنفيذ هذا الإجراء. إيقاف الإصدار 1 أو بدءه يغير IP العام. لا يمكن إجراء هذه العملية إلا باستخدام Azure PowerShell وAzure CLI عن طريق تشغيل الأوامر التالية:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

لمزيد من المعلومات، راجع Set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

راجع مجموعات أمان الشبكة في الشبكة الفرعية لـ Application Gateway.

راجع المسارات المعرفة من قبل المستخدم المدعومة في الشبكة الفرعية لـ Application Gateway.

‏‏لا. نهج نقطة نهاية الخدمة لحسابات التخزين غير مدعومة في الشبكة الفرعية لبوابة التطبيق وتكوينها يحظر حركة مرور البنية الأساسية ل Azure.

راجع حدود Application Gateway.

نعم. Application Gateway تدعم عنوان IP داخليًّا واحدًا وعنوان IP خارجيًّا واحدًا لكل بوابة تطبيقات.

نعم. يساعد تناظر الشبكة الظاهرية على موازنة الحمل في الشبكات الظاهرية الأخرى.

نعم، طالما يُسمح باستخدام الشبكة.

يتم دعم هندسة الخدمات الصغرى. للتحقيق في منافذ مختلفة، تحتاج إلى تكوين إعدادات خلفية متعددة.

‏‏لا.

راجع ترتيب قواعد المعالجة.

يحدد حقل المضيف الاسم الذي تريد إرسال التحقيق إليه عند تكوين مواقع متعددة على بوابة التطبيق. وإلا، استخدم 127.0.0.1. تختلف هذه القيمة عن اسم مضيف الجهاز الظاهري. تنسيقه هو <protocol>://<host>:<port><path>.

نعم. راجع تقييد الوصول إلى عناوين IP مصدر محددة.

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

يدعم Application Gateway v2 واجهات IPv4 وIPv6 الأمامية. حاليا، يتوفر دعم IPv6 لبوابات التطبيقات الجديدة فقط. لدعم IPv6، يجب أن تكون الشبكة الظاهرية مكدسا مزدوجا. لا يدعم Application Gateway v1 الشبكات الظاهرية مزدوجة المكدس.

يمكن تشغيل وحدات SKU v1 لبوابة التطبيق في وضع تشغيل معتمد FIPS 140-2، والذي يشار إليه عادة باسم "وضع FIPS". يستدعي وضع FIPS وحدة تشفير تم التحقق من صحتها FIPS 140-2 تضمن خوارزميات متوافقة مع FIPS للتشفير والتجزئة والتوقيع عند التمكين. لضمان تمكين وضع FIPS، FIPSMode يجب تكوين الإعداد عبر PowerShell أو قالب Azure Resource Manager أو REST API بعد تسجيل الاشتراك لتمكين تكوين FIPSmode.

ملاحظة: كجزء من التوافق مع FedRAMP، تخول حكومة الولايات المتحدة أن تعمل الأنظمة في وضع معتمد من FIPS بعد أغسطس 2024. خطوات لتمكين وضع FIPS في V1 SKU

• سجل ميزة "AllowApplicationGatewayEnableFIPS" لتسجيل الاشتراك في تكوين وضع FIPS.

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

استخدم الخطوات التالية للتسجيل في وضع FIPS في Application Gateway V1 باستخدام مدخل Microsoft Azure

1. قم بتسجيل الدخول إلى بوابة Azure.
2. في مربع البحث، أدخل الاشتراكات وحدد الاشتراكات.
3. حدد ارتباط اسم اشتراكك.
4. من القائمة اليمنى، ضمن الإعدادات حدد معاينة الميزات .
5. ترى قائمة بالميزات المتوفرة وحالة التسجيل الحالية.
6. من Preview features اكتب في مربع عامل التصفية AllowApplicationGatewayEnableFIPS، حدد الميزة، ثم حدد Register.

• بمجرد اكتمال الخطوة 1 ، يجب تعيين خاصية enableFips إلى True من خلال PowerShell أو قالب Azure Resource Manager أو REST API.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

لا يؤثر تغيير وضع FIPS على التوفر العام أجنحة التشفير على بوابات V1. ومع ذلك، عند استخدام تشفير المنحنى الناقص للشفرات، مع تعطيل وضع FIPS، يمكنك استخدام curve25519 و NistP256 و NistP384 بينما مع تمكين وضع FIPS يتم السماح فقط ب NistP256 و NistP384 ويتم تعطيل curve25519. نظرا لأن curve25519 يصبح غير متوفر في وضع FIPS، تأكد من أن عملائك يدعمون NistP256 أو NistP384 للاتصال الآمن قبل تمكين FIPS.

يدعم Application Gateway v2 حاليا تكوين واجهة IP الأمامية الخاصة فقط (لا يوجد IP عام) عبر المعاينة العامة. لمزيد من المعلومات، راجع نشر بوابة التطبيق الخاصة (معاينة).

لدعم التوفر العام الحالي، يدعم Application Gateway v2 المجموعات التالية:

• IP الخاص وعنوان IP العام
• عنوان IP العام فقط

لتقييد نسبة استخدام الشبكة فقط إلى عناوين IP الخاصة بالوظائف الحالية، اتبع هذه العملية:

1. إنشاء بوابة تطبيق بعنوان IP للواجهة الأمامية العامة والخاصة.

2. لا تقم بإنشاء أي وحدات استماع لعنوان IP للواجهة الأمامية العامة. لن تستمع بوابة التطبيق إلى أي حركة مرور على عنوان IP العام إذا لم يتم إنشاء مستمعين لها.

3. قم بإنشاء وإرفاق مجموعة أمان شبكة للشبكة الفرعية لبوابة التطبيق بالتكوين التالي بترتيب الأولوية:

   1. السماح بنسبة استخدام الشبكة من المصدر كعلامة الخدمة GatewayManager والوجهة كأي منفذ ومنفذ الوجهة ك 65200-65535. نطاق المنفذ هذا مطلوب لاتصالات البنية الأساسية لـ Azure. هذه المنافذ محمية (مؤمنة) بواسطة مصادقة الشهادة. لا يمكن للكيانات الخارجية، بما في ذلك مسؤولو مستخدم البوابة، بدء التغييرات على نقاط النهاية هذه دون وجود شهادات مناسبة.

   2. السماح بنسبة استخدام الشبكة من المصدر كعلامة الخدمة AzureLoadBalancer ومنفذ الوجهة كأي.

   3. رفض كل نسبة استخدام الشبكة الواردة من المصدر كعلامة الخدمة على الإنترنت ومنفذ الوجهة كأي. امنح هذه القاعدة أقل أولوية في القواعد الواردة.

   4. احتفظ بالقواعد الافتراضية مثل AllowVNetInBound بحيث لا يتم حظر الوصول على عنوان IP خاص.

   5. لا يمكن حظر الاتصال بالإنترنت الصادر. وإلا، فستواجه مشكلات في التسجيل والمقاييس.

نموذج تكوين NSG للوصول الخاص ب IP فقط:

يمكنك استخدام Azure PowerShell أو Azure CLI لإيقاف بوابة التطبيق وبدء تشغيلها. عند إيقاف "بوابة التطبيق" وبدء تشغيلها، تتوقف الفوترة وتبدأ أيضا. تؤدي أي عملية PUT تم إجراؤها على بوابة تطبيق متوقفة (مثل إضافة علامة أو فحص سلامة أو وحدة استماع) إلى بدء التشغيل. نوصي بإيقاف بوابة التطبيق بعد تحديث التكوين.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

تدعم Application Gateway الشهادات الموقعة ذاتيًا وشهادات المرجع المصدق (CA) وشهادات التحقق من الصحة الموسعة (EV) والشهادات متعددة المجالات (SAN) وشهادات البدل.

تدعم بوابة التطبيق مجموعات التشفير التالية:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

للحصول على معلومات حول كيفية تخصيص خيارات TLS، راجع تكوين إصدارات نُهج TLS ومجموعات التشفير في Application Gateway.

نعم. تدعم بوابة التطبيق تفريغ TLS وTLS من طرف إلى طرف، والذي يعيد تشفير نسبة استخدام الشبكة إلى الخلفية.

نعم. يمكنك تكوين Application Gateway بحيث يتم رفض TLS1.0 وTLS1.1 وTLS1.2. افتراضيًا، SSL 2.0 و3.0 معطَّلة بالفعل وغير قابلة للتكوين.

نعم. في Application Gateway، يمكنك تكوين مجموعات التشفير. لتعريف نهج مخصص، قم بتمكين مجموعة تشفير واحدة على الأقل من مجموعات التشفير التالية:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

تستخدم بوابة التطبيق SHA256 لإدارة الخلفية.

تدعم Application Gateway ما يصل إلى 100 شهادة TLS/SSL.

نعم، بوابة التطبيق تدعم الشهادات مع ملحقات OCSP وتدبيس OCSP لشهادات الخادم.

تدعم Application Gateway شهادات مصادقة تصل إلى 100.

نعم، Application Gateway v2 SKU تدعم خدمة Key Vault. لمزيد من المعلومات، راجع إنهاء TLS مع شهادات Key Vault.

لإجراء توجيه مستند إلى العديد من المجالات (مستند إلى العديد من المضيفين)، يمكنك إنشاء وحدات استماع متعددة المواقع، قم بإعداد الوحدات التي تستخدم HTTPS كبروتوكول، ثم ربط وحدات الاستماع هذه بقواعد التوجيه. لمزيد من المعلومات، راجع استضافة مواقع متعددة باستخدام Application Gateway.

‏‏لا. استخدم الأحرف الأبجدية الرقمية فقط في كلمة مرور ملف .pfx.

نشر أعضاء CA/Browser مؤخرا تقارير تفصل شهادات متعددة صادرة عن موردي CA يتم استخدامها من قبل عملائنا وMicrosoft ومجتمع التكنولوجيا الأكبر الذي كان خارج عن التوافق مع معايير الصناعة للمراجع المصدقة الموثوق بها بشكل عام. يمكن العثور على التقارير المتعلقة بالتقارير غير المتوافقة هنا:

• خطأ 1649951
• خطأ 1650910

وفقا لمتطلبات الامتثال لهذه الصناعة، بدأ موردو CA في إبطال المراجع المصدقة غير المتوافقة وإصدار المراجع المصدقة المتوافقة، ما يتطلب من العملاء إعادة إصدار شهاداتهم. تتعاون Microsoft بشكل وثيق مع هؤلاء الموردين لتقليل التأثير المحتمل على خدمات Azure. ومع ذلك، لا تزال الشهادات أو الشهادات الصادرة ذاتيا المستخدمة في سيناريوهات إحضار الشهادة الخاصة بك (BYOC) عرضة لخطر إبطالها بشكل غير متوقع.

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

للحصول على معلومات خاصة ب Application Gateway:

إذا كنت تستخدم شهادة صادرة عن أحد ICAs التي تم إبطالها، فقد تتم مقاطعة توفر التطبيق الخاص بك. اعتمادا على التطبيق الخاص بك، قد تتلقى رسائل خطأ مختلفة بما في ذلك على سبيل المثال لا الحصر:

• شهادة غير صالحة/شهادة مبطلة
• انتهت مهلة الاتصال
• HTTP 502

لتجنب أي انقطاع في التطبيق الخاص بك بسبب هذه المشكلة، أو لإعادة إصدار مرجع مصدق تم إبطاله، تحتاج إلى اتخاذ الإجراءات التالية:

1. اتصل بموفر الشهادة لمعرفة كيفية إعادة إصدار الشهادات.
2. بعد إعادة إصدارها، قم بتحديث شهاداتك على Application Gateway/WAF بسلسلة كاملة من الثقة (شهادة طرفية ومتوسطة وجذرية). استنادا إلى المكان الذي تستخدم فيه شهادتك، إما على وحدة الاستماع أو إعدادات HTTP لبوابة التطبيق، اتبع الخطوات هنا لتحديث الشهادات. لمزيد من المعلومات، تحقق من ارتباطات الوثائق المذكورة.
3. قم بتحديث خوادم التطبيقات الخلفية لاستخدام الشهادة التي تم إعادة إصدارها. اعتمادا على الخادم الخلفي الذي تستخدمه، قد تختلف خطوات تحديث الشهادة. تحقق من الوثائق من المورد الخاص بك.

لتحديث الشهادة في وحدة الاستماع:

1. في مدخل Microsoft Azure، افتح مورد Application Gateway.
2. افتح إعدادات وحدة الاستماع المقترنة بشهادتك.
3. حدد تجديد الشهادة المحددة أو تحريرها.
4. قم بتحميل شهادة PFX الجديدة باستخدام كلمة المرور وحدد حفظ.
5. الوصول إلى موقع الويب والتحقق مما إذا كان الموقع يعمل كما هو متوقع. لمزيد من المعلومات، راجع تجديد شهادات بوابة التطبيق.

إذا كنت تشير إلى الشهادات من Key Vault في وحدة إصغاء Application Gateway، نوصي بالخطوات التالية لتغيير سريع:

1. في مدخل Microsoft Azure، انتقل إلى إعدادات Key Vault المقترنة ببوابة التطبيق.
2. أضف الشهادة التي تم إعادة إصدارها أو استوردها في متجرك. لمزيد من المعلومات، راجع التشغيل السريع: إنشاء مخزن مفاتيح باستخدام مدخل Microsoft Azure.
3. بعد استيراد الشهادة، انتقل إلى إعدادات مستمع Application Gateway وضمن اختيار شهادة من Key Vault، حدد القائمة المنسدلة Certificate وحدد الشهادة المضافة مؤخرا.
4. حدد حفظ. لمزيد من المعلومات حول إنهاء TLS على بوابة التطبيق مع شهادات Key Vault، راجع إنهاء TLS مع شهادات Key Vault.

لتحديث الشهادة في إعدادات HTTP:

إذا كنت تستخدم v1 SKU لخدمة Application Gateway/WAF، يجب عليك تحميل الشهادة الجديدة كشهادة مصادقة خلفية.

1. في مدخل Microsoft Azure، افتح مورد Application Gateway.
2. افتح إعدادات HTTP المقترنة بشهادتك.
3. حدد Add certificate، وقم بتحميل الشهادة التي تم إعادة إصدارها، وحدد Save.
4. يمكنك إزالة الشهادة القديمة لاحقا عن طريق تحديد زر ... options بجوار الشهادة القديمة. حدد حذف ثم حدد حفظ. لمزيد من المعلومات، راجع تكوين TLS من طرف إلى طرف باستخدام بوابة التطبيق مع المدخل.

إذا كنت تستخدم V2 SKU لخدمة Application Gateway/WAF، فلن تضطر إلى تحميل الشهادة الجديدة في إعدادات HTTP نظرا لأن V2 SKU يستخدم "شهادات الجذر الموثوق بها"، ولا يلزم اتخاذ أي إجراء هنا.

نعم. يستخدم كل من توجيه الطبقة 7 والطبقة 4 من خلال بوابة التطبيق نفس تكوين IP الأمامي. بهذه الطريقة، يمكنك توجيه جميع العملاء إلى عنوان IP واحد (عام أو خاص) وسيقوم نفس مورد البوابة بتوجيههم استنادا إلى بروتوكولات وحدة الاستماع المكونة والمنافذ.

بينما يمكن تقديم حركة مرور HTTP(S) من خلال بروتوكولات وكيل L4 أيضا، لا نوصي بالقيام بذلك. يوفر حل وكيل L7 ل Application Gateway تحكما وأمانا أكبر على بروتوكولات HTTP (S) من خلال ميزات متقدمة مثل إعادة الكتابة وترابط الجلسة وإعادة التوجيه وWebSockets وWAF والمزيد.

تختلف خصائص المورد لميزات الطبقة 4 عن خصائص الطبقة 7. وفقا لذلك، عند استخدام واجهة برمجة تطبيقات REST أو CLI، يجب استخدام الخصائص التالية.

• واجهة برمجة التطبيقات REST
• المبادره القطريه

‏‏لا. لا يمكنك ربط خصائص الطبقة 4 والطبقة 7. لذلك، ستسمح لك قاعدة التوجيه فقط بربط وحدة استماع من نوع الطبقة 4 بإعداد الواجهة الخلفية من نوع الطبقة 4.

لا يمكنك استخدام نفس الاسم ل L7 (httpListeners) وL4 (وحدات الاستماع). ينطبق هذا على خصائص L4 الأخرى مثل backendSettingsCollection وroutingRules أيضا.

مطلقًا. على غرار وكيل الطبقة 7، يمكنك إضافة نقطة نهاية خاصة إلى تجمع الواجهة الخلفية لبوابة التطبيق الخاص بك. يجب نشر نقطة النهاية الخاصة هذه في شبكة فرعية مجاورة لنفس الشبكة الظاهرية لبوابة التطبيق.

لا يستخدم Keepalive للاتصالات الخلفية. لكل طلب وارد على اتصال وحدة الاستماع الأمامية، تبدأ بوابة التطبيق اتصال خلفية جديدة لتلبية هذا الطلب.

يرى الخادم الخلفي عنوان IP لبوابة التطبيق. حاليا، نحن لا ندعم "الاحتفاظ ب IP للعميل" الذي يمكن من خلاله جعل تطبيق الواجهة الخلفية على علم بعنوان IP الخاص بالعميل الأصلي.

ينطبق نفس تكوين نهج TLS/SSL على كل من الطبقة 7 (HTTPS) وكذلك الطبقة 4 (TLS). يمكنك الآن استخدام ملف تعريف SSL (لنهج TLS الخاص بوحدة الاستماع والمصادقة المتبادلة) لمستمعي TLS. ومع ذلك، يمكن حاليا إقران ملف تعريف SSL بمستمع TLS من خلال CLI أو PowerShell أو REST API فقط.

‏‏لا. لا يتم دعم توجيه عميل إلى نفس الخادم الخلفي في الوقت الحالي. سيتم توزيع الاتصالات بطريقة الترتيب الدوري على الخوادم في تجمع الخلفية.

نعم، ستعمل ميزة التحجيم التلقائي للارتفاعات والتخفيضات في نسبة استخدام الشبكة لبروتوكول TLS أو بروتوكول TCP أيضا.

لن تعمل قدرات جدار حماية تطبيق الويب (WAF) لاستخدام الطبقة 4.

‏‏لا. لا يتوفر دعم UDP في الوقت الحالي.

تنطبق نفس قائمة نطاق المنفذ المسموح به والاستثناءات على وكيل الطبقة 4 أيضا.

استخدام منفذ شائع لمستمعي TLS/TCP غير مدعوم حاليا.

يسمح Kubernetes بإنشاء deployment والموارد service لكشف مجموعة من pods داخليا في نظام المجموعة. لعرض نفس الخدمة خارجيا Ingress ، يتم تعريف مورد، والذي يوفر موازنة التحميل وإنهاء TLS والاستضافة الظاهرية المستندة إلى الاسم. لتلبية هذا Ingress المورد، يلزم وجود وحدة تحكم دخول، والتي تستمع لأي تغييرات على Ingress الموارد وتكوين نهج موازن التحميل.

تسمح وحدة تحكم دخول بوابة التطبيق (AGIC) باستخدام Application Gateway كدخل لخدمة Azure Kubernetes، والمعروفة أيضا باسم مجموعة AKS.

حاليا، يمكن ربط مثيل واحد لوحدة تحكم الدخول ببوابة تطبيق واحدة فقط.

تحاول AGIC إقران مورد جدول التوجيه تلقائيا بالشبكة الفرعية لبوابة التطبيق ولكنها قد تفشل في القيام بذلك بسبب عدم وجود أذونات من AGIC. إذا تعذر على AGIC إقران جدول التوجيه بالشبكة الفرعية لبوابة التطبيق، يظهر خطأ في سجلات AGIC. في هذه الحالة، يجب عليك إقران جدول التوجيه الذي تم إنشاؤه بواسطة نظام مجموعة AKS بالشبكة الفرعية لبوابة التطبيق يدويا. لمزيد من المعلومات، راجع المسارات المدعومة المعرفة من قبل المستخدم.

نعم، طالما أن الشبكات الافتراضية يتم نظيرها وليس لديها مساحات عناوين متداخلة. إذا كنت تقوم بتشغيل AKS مع kubenet، فتأكد من إقران جدول التوجيه الذي تم إنشاؤه بواسطة AKS بالشبكة الفرعية لبوابة التطبيق.

للحصول على الاختلافات بين AGIC المنشورة من خلال Helm مقابل نشرها كوظيفة AKS إضافية، راجع الفرق بين نشر Helm والوظيفة الإضافية AKS.

للحصول على الاختلافات بين AGIC المنشورة من خلال Helm مقابل نشرها كوظيفة AKS إضافية، راجع الفرق بين نشر Helm والوظيفة الإضافية AKS، خاصة الجداول التي توثق السيناريوهات التي يدعمها AGIC الموزعة من خلال Helm بدلا من الوظيفة الإضافية AKS. بشكل عام، يتيح لك النشر من خلال Helm اختبار ميزات بيتا وإصدار المرشحين قبل إصدار رسمي.

‏‏لا. الوظيفة الإضافية AGIC هي خدمة مدارة، ما يعني أن Microsoft تقوم تلقائيا بتحديث الوظيفة الإضافية إلى أحدث إصدار مستقر.

المصادقة المتبادلة هي مصادقة ثنائية الاتجاه بين عميل وخادم. تسمح المصادقة المتبادلة مع Application Gateway حاليًا للبوابة بالتحقق من العميل مرسل الطلب، وهو مصادقة العميل. عادة ما يكون العميل هو الوحيد الذي يصادق على بوابة التطبيق. نظرًا لأنه يمكن الآن أيضًا مصادقة العميل من قِبل Application Gateway، فتصبح المصادقة متبادلة حيث إن Application Gateway والعميل يصادقان على بعضهما البعض.

لا، المصادقة المتبادلة حاليا فقط بين عميل الواجهة الأمامية وبوابة التطبيق. المصادقة المتبادلة الخلفية غير مدعومة حاليا.

توفر Application Gateway ثلاثة سجلات:

• ApplicationGatewayAccessLog: يحتوي سجل الوصول على كل طلب مقدم إلى الواجهة الأمامية لبوابة التطبيقات. تتضمن البيانات IP الخاص بالمتصل، وعنوان URL المطلوب، وزمن الاستجابة، ورمز الإرجاع، ووحدات بايت الدخول والخروج. ويحتوي على سجل واحد لكل بوابة تطبيقات.
• ApplicationGatewayPerformanceLog: يلتقط سجل الأداء معلومات الأداء لكل بوابة تطبيقات. تتضمن المعلومات معدل النقل بالبايت، وإجمالي الطلبات التي تم تقديمها، وعدد الطلبات الفاشلة، وعدد مثيلات الخلفية السليمة وغير السليمة.
• ApplicationGatewayFirewallLog: لبوابات التطبيقات التي تقوم بتكوينها باستخدام WAF، يحتوي سجل جدار الحماية على الطلبات التي تم تسجيلها إما من خلال وضع الكشف وإما وضع الوقاية.

يتم جمع جميع السجلات كل 60 ثانية. لمزيد من المعلومات، راجع الصحة الخلفية وسجلات التشخيص والمقاييس لبوابة التطبيق.

تحقق من السلامة باستخدام PowerShell cmdlet Get-AzApplicationGatewayBackendHealth أو المدخل. لمزيد من المعلومات، راجع عمليات التشخيص في Application Gateway.

تتدفق سجلات التشخيص إلى حساب تخزين العميل. يمكن للعملاء تعيين نهج الاستبقاء وفقًا لتفضيلاتهم. يمكن أيضا إرسال سجلات التشخيص إلى مركز أحداث أو سجلات Azure Monitor. لمزيد من المعلومات، راجع عمليات التشخيص في Application Gateway.

في المدخل، في جزء القائمة لبوابة تطبيق، حدد سجل النشاط للوصول إلى سجل التدقيق.

نعم. في Application Gateway، يتم تكوين التنبيهات على المقاييس. لمزيد من المعلومات، راجع مقاييس Application Gateway وتلقَّ إعلامات التنبيه.

يمكنك عرض سجلات الوصول وتحليلها بعدة طرق. استخدم سجلات Azure Monitor وExcel وPower BI وما إلى ذلك.

يمكنك أيضًا استخدام قالب Resource Manager الذي يقوم بتثبيت محلل السجلات الشائع GoAccess وتشغيله بالنسبة لسجلات الوصول في Application Gateway. يوفر GoAccess إحصاءات استخدام شبكة HTTP قيِّمة، مثل الزوار الفريدين والملفات المطلوبة والمضيفين وأنظمة التشغيل والمتصفحات ورموز حالة HTTP. لمزيد من المعلومات، في GitHub، راجع الملف Readme في مجلد قالب Resource Manager.

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

بسبب قيود النظام الأساسي الحالية، إذا كان لديك NSG على الشبكة الفرعية Application Gateway v2 (Standard_v2، WAF_v2)، وإذا قمت بتمكين سجلات تدفق NSG عليها، فسترى سلوكا غير محدد. هذا السيناريو غير معتمد حاليا.

لا تنقل بوابة التطبيق بيانات العملاء أو تخزنها خارج المنطقة التي يتم نشرها فيها.

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

• لمعرفة المزيد حول بوابة التطبيق، راجع ما هي بوابة تطبيق Azure.
• للتعرف على إنهاء TLS وTLS من طرف إلى طرف باستخدام بوابة التطبيق، راجع تمكين TLS من طرف إلى طرف على بوابة تطبيق Azure.