استكشاف أخطاء البوابة غير الصالحة وإصلاحها في بوابة التطبيق

تعرّف على كيفية استكشاف أخطاء البوابة غير الصالحة (502) التي يتم تلقيها عند استخدام Azure Application Gateway.

إشعار

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

نظرة عامة

بعد تكوين بوابة تطبيق، أحد الأخطاء التي قد تراها هو خطأ الخادم: 502 - تلقى خادم ويب استجابة غير صالحة أثناء العمل كبوابة أو خادم وكيل. قد يحدث هذا الخطأ للأسباب الرئيسية التالية:

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

مجموعة أمان الشبكة، أو توجيه معرف من المستخدم، أو مشكلة DNS مخصصة.

السبب

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

يمكن أن يكون NSG/UDR موجودًا إما في الشبكة الفرعية لبوابة التطبيق أو الشبكة الفرعية، التي يتم فيها توزيع الأجهزة الظاهرية للتطبيق.

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

حل

التحقق من صحة تكوين NSG وUDR وDNS من خلال الانتقال خلال الخطوات التالية:

1. تحقق من NSGs المقترنة مع الشبكة الفرعية لبوابة التطبيق. تأكد من عدم حظر الاتصال بالخلفية. للحصول على مزيٍد من المعلومات، راجع مجموعة أمان الشبكة.

2. تحقق من UDR المقترن مع الشبكة الفرعية لبوابة التطبيق. تأكد من أن UDR لا يوجه نسبة استخدام الشبكة بعيدًا عن الشبكة الفرعية الخلفية. على سبيل المثال، تحقق من التوجيه إلى الأجهزة الظاهرية للشبكة أو عمليات التوجيه الافتراضية التي يتم الإعلان عنها إلى الشبكة الفرعية لبوابة التطبيق عبر ExpressRoute/VPN.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. تحقق من فعالية NSG والمسار مع الجهاز الظاهري في الخلفية.

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. تحقق من وجود DNS مخصص في الشبكة الظاهرية. يمكن التحقق من DNS من خلال النظر في تفاصيل خصائص الشبكة الظاهرية في الإخراج.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. في حالة وجود خادم DNS، تأكد من أنه يمكنه أن يحل FQDN لعضو تجمع الخلفية بشكل صحيح.

مشاكل في اختبار فحص الصحة الافتراضي

السبب

يمكن أن تكون أخطاء 502 أيضا مؤشرات متكررة على أن فحص السلامة الافتراضي لا يمكن أن يصل إلى الأجهزة الظاهرية الخلفية.

عند تزويد مثيل بوابة تطبيق، فإنه يعمل تلقائيًا على تكوين اختبار فحص صحة افتراضي إلى كل BackendAddressPool باستخدام خصائص في BackendHttpSetting. لا يلزم إدخال مستخدم لتعيين اختبار الفحص هذا. وبوجه خاص، عند تكوين قاعدة موازنة التحميل، يتم إجراء اقتران بين BackendHttpSetting وBackendAddressPool. يتم تكوين اختبار فحص افتراضي لكل اقتران من هذه الاقترانات، وستبدأ بوابة التطبيق اتصال اختبار فحص صحة دوري لكل مثيل في BackendAddressPool في المنفذ المحدد في العنصر BackendHttpSetting.

يسرد الجدول التالي القيم المقترنة باختبار فحص الصحة الافتراضي:

خاصية الفحص	قيمة	‏‏الوصف
التحقق من عنوان URL	http://127.0.0.1/	مسار URL
الفاصل الزمني	30	الفاصل الزمني لاختبار فحص الصحة الافتراضي محسوبًا بالثواني
المهلة	30	مهلة اختبار فحص الصحة الافتراضي محسوبة بالثواني
حد غير سليم	3	الفحص في إعادة المحاولة. يتم وضع علامة على الخادم الخلفي لأسفل بعد أن يصل عدد فشل التحقيق المتتالي إلى الحد غير السليم.

حل

• تم تعيين قيمة مضيف الطلب إلى 127.0.0.1. تأكد من تكوين موقع افتراضي وأنه ينصت في 127.0.0.1.
• يتم تحديد بروتوكول الطلب بواسطة بروتوكول BackendHttpSetting.
• تم تعيين مسار URI إلى /.
• إذا كان BackendHttpSetting يعين منفذًا آخر غير 80، فينبغي تكوين الموقع الافتراضي للإنصات في ذلك المنفذ.
• ينبغي أن ترجع المكالمة إلى protocol://127.0.0.1:port التعليمة البرمجية لنتيجة HTTP بقيمة 200. يجب إرجاع هذه التعليمة البرمجية خلال فترة المهلة البالغة 30 ثانية.
• تأكد من أن المنفذ الذي تم تكوينه مفتوح ولا توجد قواعد جدار حماية أو مجموعات أمان شبكة Azure تمنع نسبة استخدام الشبكة الواردة أو الصادرة على المنفذ الذي تم تكوينه.
• إذا تم استخدام أجهزة Azure الظاهرية الكلاسيكية أو خدمة السحابة مع FQDN أو IP عام، فتأكد من فتح نقطة النهاية المقابلة.
• إذا تم تكوين جهاز ظاهري عبر Azure Resource Manager وكان خارج شبكة ظاهرية، يتم خلالها توزيع بوابة التطبيق، يجب تكوين مجموعة أمان شبكة للسماح بالوصول في المنفذ المطلوب.

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

مشاكل مع اختبار فحص الصحة الافتراضي المخصص

السبب

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

يتم إضافة الخصائص الإضافية التالية:

خاصية الفحص	‏‏الوصف
الاسم	اسم الفحص. يستخدم هذا الاسم للإشارة إلى الفحص في إعدادات HTTP الخلفية.
البروتوكول	البروتوكول المستخدم لإرسال الفحص. يستخدم الفحص البروتوكول المحدد في إعدادات HTTP الخلفية
المضيف	اسم المضيف لإرسال اختبار فحص الصحة الافتراضي. قابل للتطبيق فقط عندما يتم تكوين موقع متعدد على بوابة التطبيق. يختلف هذا عن اسم مضيف الجهاز الظاهري.
المسار	المسار النسبي للفحص. يبدأ المسار الصالح من '/'. يتم إرسال التحقيق إلى <البروتوكول>://<host>:<port><path>
الفاصل الزمني	فاصل الفحص الزمني بالثواني. هذا هو الفاصل الزمني بين اثنين من اختبارات فحص الصحة الافتراضية المتتالية.
المهلة	مهلة الفحص بالثواني. إذا لم يتم تلقي استجابة صالحة في غضون فترة المهلة، فسيتم وضع علامة على اختبار فحص الصحة الافتراضي على أنه قد فشل.
حد غير سليم	الفحص في إعادة المحاولة. يتم وضع علامة على الخادم الخلفي لأسفل بعد أن يصل عدد فشل التحقيق المتتالي إلى الحد غير السليم.

حل

تحقق من تكوين Custom Health Probe بشكل صحيح، كما هو موضح في الجدول السابق. بالإضافة إلى الخطوات السابقة لاستكشاف الأخطاء وإصلاحها، تأكد أيضًا مما يلي:

• تأكد من تحديد اختبار فحص الصحة الافتراضي بشكل صحيح وفق الإرشاد.
• إذا تم تكوين بوابة التطبيق لموقع واحد، فينبغي بشكل افتراضي تحديد اسم المضيف على أنه 127.0.0.1، ما لم يتم تكوينه بطريقة أخرى في اختبار فحص الصحة الافتراضي المخصص.
• تأكد من أن استدعاء http://< host>:<port><path> يرجع رمز نتيجة HTTP 200.
• تأكد من أن الفاصل الزمني والمهلة والمهلة غير السليمة تقع ضمن النطاقات المقبولة.
• إذا كنت تستخدم اختبار فحص HTTPS، فتأكد من أن خادم الواجهة الخلفية لا يتطلب SNI عن طريق تكوين شهادة احتياطية على الخادم الخلفي نفسه.

طلب مهلة

السبب

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

حل

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

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

BackendAddressPool فارغ

السبب

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

حل

تأكد من أن تجمع عناوين الواجهة الخلفية غير فارغ. يمكن القيام بذلك إما عبر PowerShell أو CLI أو مدخل.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

يجب أن يحتوي الإخراج من cmdlet السابق على تجمع عناوين الواجهة الخلفية غير المترابطة. يوضح المثال التالي تجمعين تم إرجاعهما تم تكوينهما باستخدام FQDN أو عناوين IP للأجهزة الظاهرية الخلفية. يجب أن تكون حالة توفير BackendAddressPool «ناجحة».

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

مثيلات غير صحية في BackendAddressPool

السبب

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

حل

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

شهادة SSL المصدر غير متطابقة

السبب

لا تتطابق شهادة TLS المثبتة على خوادم الواجهة الخلفية مع اسم المضيف المستلم في عنوان طلب المضيف.

في السيناريوهات التي يتم فيها تمكين TLS من طرف إلى طرف، وهو تكوين يتم تحقيقه عن طريق تحرير "إعدادات HTTP الخلفية" المناسبة، وتغيير هناك تكوين إعداد "بروتوكول الواجهة الخلفية" إلى HTTPS، من الضروري التأكد من أن اسم DNS لشهادة TLS المثبتة على خوادم الواجهة الخلفية يطابق اسم المضيف القادم إلى الخلفية في طلب عنوان مضيف HTTP.

للتذكير، تأثير التمكين على "إعدادات HTTP الخلفية" خيار بروتوكول HTTPS بدلا من HTTP، هو أن الجزء الثاني من الاتصال الذي يحدث بين مثيلات بوابة التطبيق والخوادم الخلفية مشفرة باستخدام TLS.

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

على سبيل المثال:

تخيل أن لديك بوابة تطبيق لخدمة طلبات https للمجال www.contoso.com. يمكن أن يكون لديك المجال contoso.com مفوضا إلى منطقة Azure DNS العامة، وسجل DNS في تلك المنطقة يشير www.contoso.com إلى IP العام لبوابة التطبيق المحددة التي ستخدم الطلبات.

في بوابة التطبيق هذه، يجب أن يكون لديك وحدة استماع للمضيف www.contoso.com مع قاعدة تحتوي على "إعداد HTTP المدعوم" الذي يجبر على استخدام بروتوكول HTTPS (ضمان TLS من طرف إلى طرف). يمكن أن تكون نفس القاعدة قد كونت تجمع خلفية مع جهازين ظاهريين يشغلان IIS كخوادم ويب.

كما نعلم، فإن تمكين HTTPS في "إعداد HTTP المدعوم" للقاعدة يجعل الجزء الثاني من الاتصال الذي يحدث بين مثيلات بوابة التطبيق والخوادم في الواجهة الخلفية لاستخدام TLS.

إذا لم يكن لدى الخوادم الخلفية شهادة TLS صادرة ل DNS NAME www.contoso.com أو *.contoso.com، يفشل الطلب مع خطأ الخادم: 502 - تلقى خادم ويب استجابة غير صالحة أثناء العمل كبوابة أو خادم وكيل لأن شهادة SSL المصدر (الشهادة المثبتة على الخوادم الخلفية) لا تتطابق مع اسم المضيف في عنوان المضيف، ومن ثم فشلت مفاوضات TLS.

www.contoso.com --> عنوان IP للواجهة الأمامية ل APP GW --> وحدة استماع مع قاعدة تقوم بتكوين "إعدادات HTTP الخلفية" لاستخدام بروتوكول HTTPS بدلا من HTTP --> تجمع الواجهة الخلفية --> خادم الويب (يحتاج إلى تثبيت شهادة TLS ل www.contoso.com)

حل

من المطلوب أن يتطابق اسم DNS لشهادة TLS المثبتة على الخادم الخلفي مع اسم المضيف المكون في إعدادات الواجهة الخلفية HTTP، وإلا فإن الجزء الثاني من الاتصال من طرف إلى طرف الذي يحدث بين مثيلات Application Gateway والواجهة الخلفية، يفشل مع "شهادة SSL المصدر لا تتطابق"، ويعيد خطأ الخادم: 502 - تلقى خادم الويب استجابة غير صالحة أثناء العمل كبوابة أو خادم وكيل

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

إذا لم تحل الخطوات السابقة المشكلة، فافتح «support ticket».