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

إشعار

نوصي باستخدام الوحدة النمطية Azure Az PowerShell للتفاعل مع Azure. للبدء، راجع تثبيت Azure PowerShell. لمعرفة كيفية الترحيل إلى الوحدة النمطية Az PowerShell، راجع ترحيل Azure PowerShell من AzureRM إلى Az.

يتم طرح الأسئلة الشائعة التالية حول Azure Application Gateway.

عام

ما هي Application Gateway؟

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

ما الميزات التي تدعمها Application Gateway؟

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

كيف تختلف Application Gateway عن Azure Load Balancer؟

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

ما البروتوكولات التي تدعمها Application Gateway؟

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

كيف تقوم Application Gateway بدعم HTTP/2؟

راجع دعم HTTP/2.

ما الموارد المدعومة كجزء من تجمع الواجهة الخلفية؟

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

في أي المناطق تتوفر Application Gateway؟

تطبيق 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 إعادة توجيه HTTP إلى HTTPS؟

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

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

أين يمكنني العثور على IP وDNS لـ Application Gateway؟

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

ما إعدادات مهلة الاتصال المستمر ومهلة خمول TCP؟

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 الذي تم إنشاؤه باستخدام خادم الواجهة الخلفية؟

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

هل يمكنني إعادة تسمية مصدر بوابة التطبيق الخاص بي؟

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

هل هناك طريقة لاستعادة مورد Application Gateway وعنوان IP العام الخاص به إذا تم حذفه؟

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

هل يتغير اسم IP أو DNS على مدى عمر Application Gateway؟

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

هل تدعم Application Gateway عنوان IP الثابت؟

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

هل تدعم Application Gateway عناوين IP عامة عديدة على البوابة؟

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

ما حجم الشبكة الفرعية الذي ينبغي تطبيقه لبوابة التطبيقات؟

هل يمكنني نشر أكثر من مورد Application Gateway إلى شبكة فرعية واحدة؟

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

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

هل يدعم Application Gateway v2 المسارات المعرفة من قبل المستخدم؟

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

هل تدعم Application Gateway رؤوس x-forwarded-for؟

كم من الوقت يستغرق نشر مثيل Application Gateway؟ هل ستعمل بوابة التطبيق أثناء تحديثها؟

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

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

كيف تتعامل بوابة التطبيق مع الصيانة الروتينية؟

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

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

هل يمكنني استخدام Exchange Server كواجهة خلفية مع Application Gateway؟

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

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

هل هناك إرشادات متاحة تتعلق بالترحيل من V1 SKU إلى V2 SKU؟

هل Application Gateway v1 SKU مدعوم؟

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

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

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

لماذا لا تكون بعض قيم العنوان موجودة عند إعادة توجيه الطلبات إلى تطبيقي؟

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

هل يدعم ملف تعريف ارتباط ترابط بوابة التطبيق السمة SameSite؟

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

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

ما الذي يعتبر وحدة استماع نشطة مقابل وحدة استماع غير نشطة؟

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

الأداء

كيف تدعم Application Gateway التوفر العالي وقابلية التوسع؟

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

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

كيف أعمل تحقيق سيناريو التعافي من الكوارث عبر مراكز البيانات باستخدام Application Gateway؟

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

هل تدعم Application Gateway استنفاد الاتصال؟

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

هل تدعم Application Gateway التحجيم التلقائي؟

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

هل يؤدي توسيع الحجم أو تقليل الحجم يدويًا أو تلقائيًا إلى وقت تعطُّل؟

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

هل يمكنني التغيير من Standard إلى WAF SKU دون تعطيل؟

نعم.

هل يمكنني تغيير حجم المثيل من متوسط إلى كبير دون تعطيل؟

نعم.

التكوين

هل يتم نشر Application Gateway دائمًا في شبكة ظاهرية؟

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

هل يمكن لـ Application Gateway التواصل مع مثيلات خارج شبكتها الظاهرية أو خارج اشتراكها؟

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

كيف يتم تحديث عنوان IP لخادم الخلفية المستند إلى FQDN؟

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

لماذا أرى 502 خطأ أو خوادم خلفية غير صحية بعد تغيير خوادم 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؟

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

ما هي حدود Application Gateway؟ هل يمكنني زيادة هذه الحدود؟

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

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

هل تدعم Application Gateway تناظر الشبكة الظاهرية؟

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

هل يمكنني التحدث إلى الخوادم المحلية عند توصيلها بواسطة أنفاق Azure ExpressRoute أو VPN؟

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

هل يمكن لتجمع واجهات خلفية واحد أن يخدم العديد من التطبيقات على منافذ مختلفة؟

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

هل تدعم الفحوصات المخصصة أحرف البدل أو regex على بيانات الاستجابة؟

‏‏لا.

كيف تتم معالجة قواعد التوجيه في Application Gateway؟

بالنسبة للفحوصات المخصصة، ما الذي يدل عليه حقل **Host**؟

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

هل يمكنني السماح لـ Application Gateway بالوصول إلى عدد قليل من عناوين IP المصدر فقط؟

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

هل يمكنني استخدام نفس المنفذ للمستمعين العامين والواجهات الخاصة؟

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

هل Application Gateway تدعم IPv6؟

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

هل تدعم بوابة التطبيق FIPS؟

يمكن تشغيل وحدات 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 خاص للواجهة الأمامية فقط؟

يدعم 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 فقط: تكوين Application Gateway v2 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

التكوين: TLS

ما الشهادات التي تدعمها Application Gateway؟

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

ما مجموعات التشفير التي تدعمها Application Gateway؟

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

  • 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.

هل تدعم Application Gateway إعادة تشفير استخدام الشبكة إلى الخلفية؟

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

هل يمكنني تكوين نهج 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 لإدارة الخلفية.

كم عدد شهادات TLS/SSL التي تدعمها Application Gateway؟

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

هل يوجد دعم لدي بوابة التطبيق ل OCSP staplingوOCSP ؟

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

كم عدد شهادات المصادقة في إعادة تشفير الخلفية التي تدعمها Application Gateway؟

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

هل تتكامل Application Gateway مع خدمة Azure Key Vault في الأساس؟

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

كيف يمكنني تكوين وحدات استماع HTTPS لمواقع .com و.net؟

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

هل يمكنني استخدام أحرف خاصة في كلمة مرور ملف .pfx؟

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

يتم إصدار شهادة EV الخاصة بي بواسطة DigiCert وتم إلغاء شهادتي المتوسطة. كيف يمكنني تجديد شهادتي على Application Gateway؟

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

وفقا لمتطلبات الامتثال لهذه الصناعة، بدأ موردو 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 يستخدم "شهادات الجذر الموثوق بها"، ولا يلزم اتخاذ أي إجراء هنا.

التكوين - وكيل TLS/TCP

هل تستخدم الطبقة 7 والطبقة 4 لبوابة التطبيق نفس عناوين IP الأمامية؟

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

هل يمكنني استخدام وكيل TCP أو TLS لحركة مرور HTTP(S)؟

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

ما هي أسماء الخصائص لوكيل الطبقة 4؟

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

الخاصية الغرض
المستمع للمستمعين المستندين إلى TLS أو TCP
routingRule لربط وحدة استماع الطبقة 4 بإعداد خلفية الطبقة 4
backendSettingsCollection لإعدادات الواجهة الخلفية المستندة إلى TLS أو TCP

إشعار

لا يمكنك استخدام أي خصائص من الطبقة 4 لإعدادات بروتوكول HTTP أو HTTPS.

هل يمكنني تعيين مستمع بروتوكول TCP/TLS مع إعداد الواجهة الخلفية لبروتوكول HTTP(S)؟

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

هل يمكن أن يكون لخصائص L7 وL4 نفس الأسماء؟

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

هل يمكنني إضافة نقطة نهاية خاصة إلى تجمع الخلفية عند استخدام الطبقة 4 (بروتوكولات TCP أو TLS)؟

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

هل تستخدم بوابة التطبيق اتصالا حافظا لخوادم الواجهة الخلفية؟

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

ما هو عنوان IP الذي يراه الخادم الخلفي عند إنشاء اتصال مع Application Gateway؟

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

كيف يمكنني تعيين نهج TLS لمستمعي TLS؟

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

هل تدعم Application Gateway ترابط جلسة العمل لتوجيه الطبقة 4؟

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

هل تعمل ميزة التحجيم التلقائي مع وكيل الطبقة 4؟

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

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

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

هل يدعم وكيل الطبقة 4 لبوابة التطبيق بروتوكول UDP؟

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

ما هي المنافذ المدعومة لمستمعي TLS/TCP؟

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

كيف يمكنني استخدام نفس رقم المنفذ لمستمعي وكيل TLS/TCP العام والخاص؟

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

التكوين - وحدة تحكم الدخول لـ AKS

ما هي وحدة تحكم الدخول؟

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

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

هل يمكن لمثيل وحدة تحكم دخول واحد إدارة بوابات تطبيق متعددة؟

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

لماذا لا تعمل مجموعة AKS الخاصة بي مع kubenet مع AGIC؟

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

هل يمكنني توصيل نظام مجموعة AKS وبوابة التطبيق في شبكات ظاهرية منفصلة؟

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

ما الميزات غير المدعومة في الوظيفة الإضافية AGIC؟

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

متى يجب استخدام الوظيفة الإضافية مقابل النشر عبر Helm؟

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

هل يمكنني التحكم في إصدار AGIC الذي يتم نشره باستخدام الوظيفة الإضافية؟

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

التكوين: المصادقة المتبادلة

ما المصادقة المتبادلة؟

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

نعم. في 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 مدعومة في NSGs المقترنة بالشبكة الفرعية لـ Application Gateway v2؟

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

أين تخزِّن Application Gateway بيانات العملاء؟

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

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