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

نظرة عامة

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

كيفية التحقق من صحة الخلفية

للتحقق من صحة تجمع الخلفية، يمكنك استخدام صفحة "صحة الخلفية" الموجودة على مدخل Microsoft Azure. أو يمكنك استخدام Azure PowerShellأو واجهة سطر الأوامرأو واجهة برمجة تطبيقات REST.

يمكن أن تكون الحالة التي تم استردادها بواسطة أي من هذه الأساليب أي من الحالات التالية:

• سليمة
• غير سليمة
• ‏‏غير معروف

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

إشعار

إذا لم يكن لدى المستخدم الإذن لرؤية حالات صحة الخلفية، يتم عرض الإخراج No results. .

الحالة الصحية للخلفية: «غير صحية»

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

في حالة استخدام استعلام Azure PowerShell أو CLI أو Azure REST API، تحصل على استجابة تشبه المثال التالي:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

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

توفر الرسالة المعروضة في عمود التفاصيل رؤى أكثر تفصيلا حول المشكلة، واستنادا إلى هذه التفاصيل، يمكنك البدء في استكشاف المشكلة وإصلاحها.

إشعار

يتم إرسال طلب الفحص الافتراضي بتنسيق <البروتوكول>://127.0.0.1:<port>. على سبيل المثال، http://127.0.0.1:80 لمجس HTTP على المنفذ 80. تعتبر التعليمات البرمجية لحالة HTTP من 200 إلى 399 فقط صحية. يتم توريث البروتوكول ومنفذ الوجهة من إعدادات HTTP. إذا كنت تريد بوابة تطبيق للتحقيق في بروتوكول أو اسم مضيف أو مسار مختلف وتحديد تعليمة برمجية لحالة مختلفة على أنها صحية، فكوّن فحصًا مخصصًا واربطه بإعدادات HTTP.

رسائل خطأ

مهلة الخادم الخلفي

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

السبب: بعد إرسال بوابة التطبيق طلب فحص HTTP(S) إلى الخادم الخلفي، فإنه ينتظر استجابة من الخادم الخلفي للفترة التي تم تكوينها. إذا لم يستجب الخادم الخلفي خلال هذه الفترة (قيمة المهلة)، يتم وضع علامة عليه على أنه غير صحي حتى يستجيب خلال فترة المهلة المكونة مرة أخرى.

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

لزيادة قيمة المهلة، اتبع الخطوات التالية:

1. الوصول إلى الخادم الخلفي مباشرةً والتحقق من الوقت المستغرق للخادم للاستجابة إلى تلك الصفحة. يمكنك استخدام أي أداة للوصول إلى الخادم الخلفي، بما في ذلك متصفح باستخدام أدوات المطور.
2. بعد معرفة الوقت المستغرق للتطبيق للاستجابة، حدد علامة التبويب Health Probes ، ثم حدد الفحص المقترن بإعدادات HTTP الخاصة بك.
3. أدِخل أي قيمة مهلة أكبر من وقت استجابة التطبيق بالثواني.
4. احفظ إعدادات الفحص المخصصة وتحقق مما إذا كانت صحة الخلفية تظهر على أنها «صحية» الآن.

خطأ في تحليل DNS

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

السبب: إذا كان تجمع الواجهة الخلفية من نوع عنوان IP أو FQDN (اسم مجال مؤهل بالكامل) أو App Service، فإن Application Gateway تحل إلى عنوان IP الخاص ب FQDN الذي تم إدخاله من خلال DNS (مخصص أو افتراضي Azure). ثم تحاول بوابة التطبيق الاتصال بالخادم على منفذ TCP المذكور في إعدادات HTTP. ولكن إذا عُرضت هذه الرسالة، فهذا يشير إلى أن بوابة التطبيق لم تتمكن من حل عنوان IP الخاص بـ FQDN الذي تم إدخاله بنجاح.

التحليل:

1. تحقق من صحة FQDN الذي تم إدخاله في تجمع الواجهة الخلفية وأنه مجال عام، ثم حاول حله من جهازك المحلي.
2. إذا تمكنت من حل عنوان IP، فقد يكون هناك خطأ ما في تكوين DNS في الشبكة الظاهرية.
3. تحقق مما إذا كانت الشبكة الظاهرية قد تم تكوينها باستخدام خادم DNS مخصص. إذا كان الأمر كذلك، فتحقق من خادم DNS لمعرفة سبب عدم تمكنه من حل عنوان IP الخاص بـ FQDN المحدد.
4. إذا كنت تستخدم DNS الافتراضي ل Azure، فتحقق مع جهة تسجيل أسماء المجالات من اكتمال تعيين سجل A أو سجل CNAME المناسب.
5. إذا كان المجال خاصًا أو داخليًا، فحاول حله من جهاز ظاهري في الشبكة الظاهرية نفسها. إذا كان يمكنك حلها، فأعد تشغيل "بوابة التطبيق" ونفّذ الفحص مرة أخرى. لإعادة تشغيل بوابة التطبيق، ستحتاج إلى الإيقافوالبدء باستخدام أوامر PowerShell الموضحة في هذه الموارد المرتبطة.

خطأ في اتصال TCP

رسالة: تعذّر على بوابة التطبيق الاتصال بالخلفية. تحقق من استجابة الخلفية على المنفذ المستخدم للتحقيق. تحقق أيضا مما إذا كان أي NSG/UDR/Firewall يمنع الوصول إلى Ip ومنفذ هذه الخلفية.

السبب: بعد مرحلة تحليل DNS، تحاول بوابة التطبيق الاتصال بالخادم الخلفي على منفذ TCP الذي تم تكوينه في إعدادات HTTP. إذا تعذّر على بوابة التطبيق إنشاء جلسة عمل TCP على المنفذ المحدد، يتم وضع علامة على الفحص على أنه "غير صحيح" مع هذه الرسالة.

الحل: إذا تلقيت هذا الخطأ، فاتبع الخطوات التالية:

1. تحقق ما إذا كان يمكنك الاتصال بالخادم الخلفي على المنفذ المذكور في إعدادات HTTP باستخدام متصفح أو PowerShell. على سبيل المثال، قم بتشغيل الأمر التالي: Test-NetConnection -ComputerName www.bing.com -Port 443.

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

3. إذا لم تتمكن من الاتصال بالمنفذ من جهازك المحلي أيضًا، فنفّذ ما يلي:

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

   ب. تحقق ما إذا كانت إعدادات NSG للشبكة الفرعية لبوابة التطبيق تسمح بنسبة استخدام الشبكة العامة والخاصة الصادرة، بحيث يمكن إجراء اتصال. تحقق من صفحة المستند المقدمة في الخطوة «3 أ» لمعرفة المزيد حول كيفية إنشاء قواعد NSG.

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

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

   د. للتحقق من المسارات والقواعد الفعالة لمحوّل الشبكة، يمكنك استخدام أوامر PowerShell التالية:

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

4. إذا لم تجد أي مشكلات مع NSG أو UDR، فتحقق من الخادم الخلفي الخاص بك بحثًا عن المشكلات المتعلقة بالتطبيقات التي تمنع العملاء من إنشاء جلسة TCP على المنافذ التي تم تكوينها. إليك بعض الأشياء للتحقق منها:

   أ. افتح موجه الأوامر (Win+R -> cmd)، وأدخل netstat، وحدد Enter.

   ب. تحقق مما إذا كان الخادم يستمع إلى المنفذ الذي تم تكوينه. على سبيل المثال:

           Proto Local Address Foreign Address State PID
           TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
   

   جـ. إذا لم يكن يستمع إلى المنفذ الذي تم تكوينه، فتحقق من إعدادات خادم الويب. على سبيل المثال: روابط الموقع في IIS، كتلة الخادم في NGINX والمضيف الظاهري في Apache.

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

التعليمة البرمجية لحالة HTTP غير متطابق

الرسالة: رمز الحالة لاستجابة HTTP الخلفية لم يتطابق مع إعداد الفحص. متوقع: {HTTPStatusCode0} مستلم: {HTTPStatusCode1}.

السبب: بعد تأسيس اتصال TCP ويتم تأكيد اتصال TLS (إذا تم تمكين TLS)، ترسل بوابة التطبيق التحقيق كطلب HTTP GET إلى الخادم الخلفي. كما هو موضح سابقا، يتم تعيين الفحص الافتراضي إلى <protocol>://127.0.0.1:<port>/، وينظر إلى رموز حالة الاستجابة في النطاق من 200 إلى 399 على أنه صحي. إذا أرجع الخادم أي رمز حالة آخر، يتم وضع علامة عليه على أنه غير صحي بهذه الرسالة.

الحل: اعتمادًا على التعليمة البرمجية لاستجابة خادم الواجهة الخلفية يمكنك اتخاذ الخطوات التالية. يتم سرد بعض التعليمات البرمجية للحالة هنا:

خطأ	إجراءات
عدم تطابق التعليمة البرمجية لحالة الفحص: تم تلقي 401	تحقق ما إذا كان الخادم الخلفي يتطلب المصادقة. لا يمكن لفحوص بوابة التطبيق تمرير بيانات الاعتماد للمصادقة. إما السماح ب "HTTP 401" في تطابق رمز حالة الفحص أو الفحص إلى مسار حيث لا يتطلب الخادم المصادقة.
عدم تطابق التعليمة البرمجية لحالة الفحص: تم تلقي 403	الوصول ممنوع. تحقق ما إذا كان الوصول إلى المسار مسموح به على الخادم الخلفي.
عدم تطابق التعليمة البرمجية لحالة الفحص : تم تلقي 404	لم يتم العثور على الصفحة. تحقق ما إذا كان مسار اسم المضيف يمكن الوصول إليه من الخادم الخلفي. غيّر اسم المضيف أو معلمة المسار إلى قيمة يمكن الوصول إليها.
عدم تطابق التعليمة البرمجية لحالة الفحص : تم تلقي 405	تستخدم طلبات الفحص الخاصة ببوابة التطبيق أسلوب HTTP GET. تحقق ما إذا كان الخادم يسمح بهذا الأسلوب.
عدم تطابق التعليمة البرمجية لحالة الفحص : تم تلقي 500	خطأ خادم داخلي. تحقق من صحة خادم الواجهة الخلفية وما إذا كانت الخدمات قيد التشغيل.
عدم تطابق التعليمة البرمجية لحالة الفحص : تم تلقي 503	الخدمة غير متوفرة. تحقق من صحة خادم الواجهة الخلفية وما إذا كانت الخدمات قيد التشغيل.

أو، إذا كنت تعتقد أن الاستجابة مشروعة وتريد أن تقبل بوابة التطبيق التعليمات البرمجية للحالة أخرى على أنها «صحية»، فإنه يمكنك إنشاء فحص مخصص. يُعد هذا النهج مفيدًا في الحالات التي يحتاج فيها موقع الخلفية إلى مصادقة. نظرا لأن طلبات الفحص لا تحمل أي بيانات اعتماد مستخدم، فإنها ستفشل، ويتم إرجاع رمز حالة HTTP 401 بواسطة خادم الواجهة الخلفية.

لإنشاء فحص مخصص، فاتبع هذه الخطوات.

عدم تطابق نص استجابة HTTP

الرسالة: نص استجابة HTTP الخلفية لم يتطابق مع إعداد الفحص. لا يحتوي نص الاستجابة المستلم على {string}.

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

الحل: لحل هذه المشكلة، اتبع الخطوات التالية:

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

تعرف على المزيد حول مطابقة فحص بوابة التطبيق.

إشعار

بالنسبة إلى جميع رسائل الخطأ المتعلقة بـ TLS، لمعرفة المزيد حول سلوك SNI والاختلافات بين v1 و v2 SKU، ألقِ نظرة على من صفحة نظرة عامة على TLS.

الاسم الشائع (CN) غير متطابق

الرسالة: (بالنسبة إلى V2) لا يتطابق الاسم الشائع للشهادة الطرفية المقدمة من الخادم الخلفي مع اسم مضيف Probe أو Backend Setting لبوابة التطبيق.
(للإصدار 1) الاسم الشائع (CN) لشهادة الواجهة الخلفية غير متطابق.

السبب: (بالنسبة إلى V2) يحدث هذا عند تحديد بروتوكول HTTPS في إعداد الواجهة الخلفية، ولا يتطابق اسم مضيف الإعداد المخصص أو إعداد الخلفية (بهذا الترتيب) مع الاسم الشائع (CN) لشهادة الخادم الخلفي.
(للإصدار 1) لا يتطابق FQDN لهدف تجمع الخلفية مع الاسم الشائع (CN) لشهادة الخادم الخلفي.

الحل: معلومات اسم المضيف مهمة لاتصال HTTPS الخلفي نظرا لاستخدام هذه القيمة لتعيين إشارة اسم الخادم (SNI) أثناء تأكيد اتصال TLS. يمكنك إصلاح هذه المشكلة بالطرق التالية استنادا إلى تكوين البوابة.

بالنسبة إلى الإصدار 2،

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

بالنسبة إلى V1، تحقق من أن FQDN الخاص بتجمع الواجهة الخلفية هو نفس الاسم العام (CN).

تلميحات: لتحديد الاسم الشائع (CN) لشهادة الخادم الخلفي، يمكنك استخدام أي من هذه الطرق. لاحظ أيضا أنه وفقا ل RFC 6125 إذا كانت SAN موجودة، يتم التحقق من SNI فقط مقابل هذا الحقل. يتم مطابقة حقل الاسم الشائع إذا لم يكن هناك SAN في الشهادة.

• باستخدام المستعرض أو أي عميل: قم بالوصول إلى الخادم الخلفي مباشرة (وليس من خلال بوابة التطبيق) وانقر على قفل الشهادة في شريط العناوين لعرض تفاصيل الشهادة. يمكنك العثور عليه ضمن قسم "الصادرة إلى".

• عن طريق تسجيل الدخول إلى الخادم الخلفي (Windows):

  1. سجل الدخول إلى الجهاز حيث تتم استضافة التطبيق الخاص بك.
  2. حدد Win+R وانقر بزر الماوس الأيمن فوق زر البدء، وحدد تشغيل.
  3. أدخل certlm.msc وحدد Enter. يمكنك أيضًا البحث عن مدير الشهادات في قائمة البدء.
  4. حدد موقع الشهادة (عادة في Certificates - Local Computer\Personal\Certificates)، وافتح الشهادة.
  5. في علامة التبويب "التفاصيل"، تحقق من موضوع الشهادة.

• عن طريق تسجيل الدخول إلى الخادم الخلفي (Linux): قم بتشغيل أمر OpenSSL هذا عن طريق تحديد اسم ملف الشهادة الصحيح openssl x509 -in certificate.crt -subject -noout

انتهت صلاحية شهادة الواجهة الخلفية

الرسالة: شهادة الخلفية غير صالحة. التاريخ الحالي ليس ضمن نطاق التاريخ "صالح من" و"صالح إلى" في الشهادة.

السبب: تعتبر الشهادة منتهية الصلاحية غير آمنة وبالتالي فإن بوابة التطبيق تشير إلى الخادم الخلفي بشهادة منتهية الصلاحية على أنها غير سليمة.

الحل: يعتمد الحل على أي جزء من سلسلة الشهادات انتهت صلاحيته على الخادم الخلفي.

بالنسبة إلى V2 SKU،

• شهادة طرفية منتهية الصلاحية (تعرف أيضا باسم المجال أو الخادم) - قم بتجديد شهادة الخادم مع موفر الشهادة وقم بتثبيت الشهادة الجديدة على الخادم الخلفي. تأكد من تثبيت سلسلة الشهادات الكاملة المكونة من Leaf (topmost) > Intermediate(s) > Root. استنادا إلى نوع المرجع المصدق (CA)، يمكنك اتخاذ الإجراءات التالية على البوابة الخاصة بك.

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

• شهادة متوسطة أو الجذر منتهية الصلاحية - عادة ما تكون لهذه الشهادات فترات صلاحية ممتدة نسبيا (عقد أو عقدين). عند انتهاء صلاحية الشهادة الجذر/المتوسطة، نوصيك بالتحقق من موفر الشهادة الخاص بك بحثا عن ملفات الشهادات المجددة. تأكد من تثبيت سلسلة الشهادات المحدثة والكاملة Leaf (topmost) > Intermediate(s) > Root التي تتكون على الخادم الخلفي.

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

بالنسبة إلى V1 SKU،

• تجديد شهادة طرفية منتهية الصلاحية (المعروفة أيضا باسم المجال أو الخادم) مع المرجع المصدق وتحميل نفس الشهادة الطرفية (. CER) إلى إعداد الواجهة الخلفية المقترنة لبوابة التطبيق الخاصة بك.

لم يتم العثور على الشهادة المتوسطة

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

السبب: الشهادة الوسيطة (الشهادات) غير مثبتة في سلسلة الشهادات على الخادم الخلفي.

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

إشعار

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

تظهر هذه الصور الفرق بين الشهادات الموقعة ذاتيا.

لم يتم العثور على شهادة الكائن الطرفي أو الخادم

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

السبب: شهادة ورقة (المعروفة أيضا باسم المجال أو الخادم) مفقودة من سلسلة الشهادات على الخادم الخلفي.

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

لا يتم إصدار شهادة الخادم من قبل مرجع مصدق معروف بشكل عام

الرسالة: شهادة الخادم الخلفي غير موقعة من قبل مرجع مصدق معروف (CA). لاستخدام شهادات CA غير معروفة، يجب تحميل الشهادة الجذر الخاصة بها إلى إعداد الواجهة الخلفية لبوابة التطبيق.

السبب: لقد اخترت "شهادة CA معروفة" في إعداد الواجهة الخلفية، ولكن الشهادة الجذر التي يقدمها الخادم الخلفي غير معروفة بشكل عام.

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

الشهادة المتوسطة غير موقعة من قبل مرجع مصدق معروف بشكل عام.

الرسالة: الشهادة المتوسطة غير موقعة من قبل مرجع مصدق معروف (CA). تأكد من اكتمال سلسلة الشهادات وترتيبها بشكل صحيح على الخادم الخلفي.

السبب: لقد اخترت "شهادة CA معروفة" في إعداد الواجهة الخلفية، ولكن الشهادة المتوسطة التي يقدمها الخادم الخلفي لم يتم توقيعها من قبل أي مرجع مصدق معروف بشكل عام.

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

عدم تطابق شهادة الجذر الموثوق به (لا توجد شهادة الجذر على الخادم الخلفي)

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

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

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

عدم تطابق شهادة الجذر الموثوق به (تتوفر شهادة الجذر على الخادم الخلفي)

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

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

الحل: ينطبق هذا على شهادة الخادم الخلفي الصادرة عن مرجع مصدق خاص (CA) أو شهادة موقعة ذاتيا. تحديد وتحميل شهادة المرجع المصدق الجذر الصحيح إلى إعداد الخلفية المقترنة.

تلميحات: لتحديد شهادة الجذر وتنزيلها، يمكنك استخدام أي من هذه الطرق.

• استخدام مستعرض: الوصول إلى الخادم الخلفي مباشرة (وليس من خلال بوابة التطبيق) والنقر فوق قفل الشهادة في شريط العناوين لعرض تفاصيل الشهادة.

  1. اختر الشهادة الجذر في السلسلة وانقر فوق تصدير. بشكل افتراضي، هذا هو . ملف CRT.
  2. افتح ذلك . ملف CRT.
  3. انتقل إلى علامة التبويب تفاصيل وانقر فوق "نسخ إلى ملف"،
  4. في صفحة معالج تصدير الشهادة، انقر فوق التالي،
  5. حدد "Base-64 encoded X.509 (. CER) وانقر فوق التالي،
  6. أدخل اسم ملف جديدا وانقر فوق التالي،
  7. انقر فوق إنهاء للحصول على . ملف CER.
  8. تحميل شهادة الجذر هذه (. CER) من المرجع المصدق الخاص بك إلى إعداد الواجهة الخلفية لبوابة التطبيق.

• عن طريق تسجيل الدخول إلى الخادم الخلفي (Windows)

  1. سجل الدخول إلى الجهاز حيث تتم استضافة التطبيق الخاص بك.
  2. حدد Win+R وانقر بزر الماوس الأيمن فوق زر البدء، ثم حدد تشغيل.
  3. أدخل certlm.msc وحدد Enter. يمكنك أيضًا البحث عن مدير الشهادات في قائمة البدء.
  4. حدد موقع الشهادة، عادة في Certificates - Local Computer\Personal\Certificates، وافتحها.
  5. حدد شهادة الجذر وانقر فوق عرض الشهادة.
  6. في خصائص الشهادة، حدد علامة التبويب تفاصيل وانقر فوق "نسخ إلى ملف"،
  7. في صفحة معالج تصدير الشهادة، انقر فوق التالي،
  8. حدد "Base-64 encoded X.509 (. CER) وانقر فوق التالي،
  9. أدخل اسم ملف جديدا وانقر فوق التالي،
  10. انقر فوق إنهاء للحصول على . ملف CER.
  11. تحميل شهادة الجذر هذه (. CER) من المرجع المصدق الخاص بك إلى إعداد الواجهة الخلفية لبوابة التطبيق.

يجب أن تكون الورقة الطرفية في أعلى السلسلة.

الرسالة: شهادة طرفية ليست الشهادة الأعلى في السلسلة التي يقدمها الخادم الخلفي. تأكد من أن سلسلة الشهادات مرتبة بشكل صحيح على الخادم الخلفي.

السبب: لم يتم تثبيت شهادة الورقة الطرفية (المعروفة أيضا باسم المجال أو الخادم) بالترتيب الصحيح على الخادم الخلفي.

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

يعد المعطى مثالا على تثبيت شهادة الخادم مع شهادات المرجع المصدق المتوسطة والجذرية الخاصة به، ويدل على ذلك على أنه أعماق (0 و1 و2 وما إلى ذلك) في OpenSSL. يمكنك التحقق من نفس الشيء لشهادة الخادم الخلفي باستخدام أوامر OpenSSL التالية.
s_client -connect <FQDN>:443 -showcerts
أو
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

فشل التحقق من الشهادة

رسالة: لا يمكن التحقق من صحة شهادة الخلفية. لمعرفة السبب، تحقق من تشخيص OpenSSL للرسالة المقترنة برمز الخطأ {errorCode}

السبب: يحدث هذا الخطأ عندما يتعذّر على بوابة التطبيق التحقق من صلاحية الشهادة.

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

الحالة الصحية الخلفية: غير معروف

تحديثات إدخالات DNS الخاصة بتجمع الخلفية

رسالة: تعذّر استرداد الحالة الصحية الخلفية. يحدث هذا عندما يحظر NSG / UDR / جدار حماية على الشبكة الفرعية لبوابة التطبيق نسبة استخدام الشبكة على المنافذ 65503-65534 في حالة v1 SKU، والمنافذ 65200-65535 في حالة v2 SKU أو إذا كان FQDN الذي تم تكوينه في تجمع الخلفية لا يمكن حله إلى عنوان IP. لمعرفة المزيد بادِر بزيارة - https://aka.ms/UnknownBackendHealth.

السبب: بالنسبة إلى أهداف الواجهة الخلفية المستندة إلى FQDN (اسم المجال المؤهل بالكامل)، تقوم بوابة التطبيق بذاكرة التخزين المؤقت واستخدام آخر عنوان IP معروف جيدا إذا فشل في الحصول على استجابة للبحث عن DNS اللاحق. ستؤدي عملية PUT على بوابة في هذه الحالة إلى مسح ذاكرة التخزين المؤقت DNS الخاصة بها تماما. ونتيجة لذلك، لن يكون هناك أي عنوان وجهة يمكن للبوابة الوصول إليه.

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

أسباب أخرى

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

يمكن أن يحدث هذا السلوك لسبب واحد أو أكثر من الأسباب التالية:

1. يحظر NSG على الشبكة الفرعية لبوابة التطبيق الوصول الوارد إلى المنفذين 65503-65534 (v1 SKU) أو 65200-65535 (v2 SKU) من "الإنترنت".
2. يتم تعيين UDR على الشبكة الفرعية لبوابة التطبيق إلى المسار الافتراضي (0.0.0.0/0) ولم يتم تحديد الوثبة التالية على أنها "إنترنت".
3. يتم الإعلان عن المسار الافتراضي من قِبل اتصال ExpressRoute / VPN بشبكة ظاهرية عبر BGP.
4. تم تكوين خادم DNS المخصص على شبكة ظاهرية لا يمكنها حل أسماء المجال.
5. بوابة التطبيق في حالة «غير صحية».

الحل:

1. تحقق مما إذا كان NSG يمنع الوصول إلى المنفذين 65503-65534 (v1 SKU) أو 65200-65535 (v2 SKU) من الإنترنت:

   أ. في علامة التبويب نظرة عامة على بوابة التطبيق، حدد ارتباط الشبكة الظاهرية/الشبكة الفرعية. ب. في علامة التبويب الشبكات الفرعية للشبكة الظاهرية، حدد الشبكة الفرعية حيث يتم نشر بوابة التطبيق. جـ. تحقق مما إذا كان قد تم تكوين أي NSG. د. إذا تم تكوين NSG، فابحث عن مورد NSG هذا في علامة التبويب بحث أو ضمن كافة الموارد. هـ. في قسم القواعد الواردة، أضف قاعدة واردة للسماح بنطاق منفذ الوجهة 65503-65534 ل v1 SKU أو 65200-65535 v2 SKU مع تعيين المصدر كعلامة خدمة GatewayManager. و. حدد حفظ وتحقق من أنه يمكنك عرض صحة الخلفية «صحية». بدلاً من ذلك، يمكنك القيام بذلك من خلال PowerShell / واجهة سطر الأوامر.

2. تحقق مما إذا كان UDR الخاص بك لديه مسار افتراضي (0.0.0.0/0) مع الوثبة التالية غير المحددة على أنها إنترنت:

   أ. اتبع الخطوات 1 أ و1 ب لتحديد شبكتك الفرعية. ب. تحقق لمعرفة ما إذا تم تكوين UDR. إذا كان يوجد، فابحث عن المورد في شريط البحث أو ضمن كافة الموارد. جـ. تحقق لمعرفة ما إذا كانت هناك أي مسارات افتراضية (0.0.0.0/0) مع عدم تعيين الوثبة التالية كإنترنت. إذا كان الإعداد إما Virtual Appliance أو Virtual Network Gateway، فيجب عليك التأكد من أن الجهاز الظاهري الخاص بك، أو الجهاز المحلي، يمكنه توجيه الحزمة بشكل صحيح مرة أخرى إلى وجهة الإنترنت دون تعديل الحزمة. إذا تم توجيه الفحوصات عبر جهاز ظاهري وتعديلها، يعرض مورد الواجهة الخلفية رمز حالة 200 ويمكن عرض الحالة الصحية لبوابة التطبيق على أنها غير معروفة. لا يشير هذا إلى وجود خطأ. يجب أن تظل نسبة استخدام الشبكة في التوجيه عبر بوابة التطبيق دون مشكلة. د. خلافًا لذلك، غيّر الوثبة التالية إلى الإنترنت، وحدد حفظ، وتحقق من صحة الخلفية.

3. المسار الافتراضي المعلن عنه بواسطة اتصال ExpressRoute/VPN بالشبكة الظاهرية عبر BGP (بروتوكول بوابة الحدود):

   أ. إذا كان لديك اتصال ExpressRoute/VPN بالشبكة الظاهرية عبر BGP، وإذا كنت تعلن عن مسار افتراضي، فيجب عليك التأكد من توجيه الحزمة مرة أخرى إلى وجهة الإنترنت دون تعديلها. يمكنك التحقق باستخدام الخيار استكشاف أخطاء الاتصال وإصلاحها في مدخل بوابة التطبيق. ب. اختر الوجهة يدويًا كأي عنوان IP قابل للتوجيه عبر الإنترنت مثل 1.1.1.1. عيّن منفذ الوجهة على أنه «أي شيء» وتحقق من الاتصالية. جـ. إذا كانت الوثبة التالية هي بوابة الشبكة الظاهرية، فقد يكون هناك مسار افتراضي يتم الإعلان عنه عبر ExpressRoute أو VPN.

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

5. للتحقق من صحة Application Gateway وتشغيلها، انتقل إلى خيار Resource Health في المدخل، وتحقق من أن الحالة سليمة. إذا رأيت حالة غير صحية أو متدهورة، فاتصل بالدعم.

6. إذا كان الإنترنت وحركة المرور الخاصة يمران عبر جدار حماية Azure مستضاف في مركز ظاهري آمن (باستخدام Azure Virtual WAN Hub):

   أ. للتأكد من أن بوابة التطبيق يمكنها إرسال نسبة استخدام الشبكة مباشرة إلى الإنترنت، قم بتكوين المسار المحدد من قبل المستخدم التالي:

   بادئة العنوان: 0.0.0.0/0
   الوثب التالية: الإنترنت

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

   بادئة العنوان: الشبكة الفرعية لتجمع الخلفية
   الوثبة التالية: عنوان IP الخاص بجدار حماية Azure

إشعار

إذا لم تتمكن بوابة التطبيق من الوصول إلى نقاط نهاية CRL، فإنها تحدد الحالة الصحية للواجهة الخلفية على أنها "غير معروفة" وتتسبب في فشل التحديث السريع. لمنع هذه المشكلات، تحقق من أن الشبكة الفرعية لبوابة التطبيق الخاصة بك قادرة على الوصول إلى crl.microsoft.com و crl3.digicert.com. يمكن القيام بذلك عن طريق تكوين مجموعات أمان الشبكة لإرسال نسبة استخدام الشبكة إلى نقاط نهاية CRL.

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

تعرّف على المزيد عن تشخيصات بوابة التطبيق والتسجيل.