إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تمكنك إعدادات الواجهة الخلفية من إدارة التكوينات لاتصالات الواجهة الخلفية التي تم إنشاؤها من مورد بوابة تطبيق إلى خادم في تجمع الخلفية. يمكن إقران تكوين إعدادات الواجهة الخلفية بقواعد توجيه واحدة أو أكثر.
أنواع إعدادات الواجهة الخلفية في بوابة التطبيق
بينما يرى مستخدمو Portal خيار "إعدادات الخلفية" فقط، فإن مستخدمي API لديهم إمكانية الوصول إلى نوعين من الإعدادات. يجب استخدام التكوين الصحيح، وفقا للبروتوكول.
- إعدادات HTTP الخلفية - إنها لتكوينات وكيل الطبقة 7 التي تدعم بروتوكولات HTTP وHTTPS.
- إعدادات الواجهة الخلفية - إنها لتكوينات وكيل الطبقة 4 (معاينة) التي تدعم بروتوكولات TLS وTCP.
التقارب المستند إلى ملفات تعريف الارتباط
يستخدم Azure Application Gateway ملفات تعريف الارتباط المدارة بواسطة البوابة للحفاظ على جلسات المستخدم. عندما يرسل المستخدم الطلب الأول إلى Application Gateway، فإنه يعين ملف تعريف ارتباط ترابط في الاستجابة بقيمة تجزئة تحتوي على تفاصيل جلسة العمل. تتيح هذه العملية توجيه الطلبات اللاحقة التي تحمل ملف تعريف ارتباط الترابط إلى نفس الخادم الخلفي، وبالتالي الحفاظ على الثبات.
هذه الميزة مفيدة عندما تريد الاحتفاظ بجلسة مستخدم على نفس الخادم وعندما يتم حفظ حالة الجلسة محليًا على الخادم لجلسة المستخدم. إذا لم يتمكن التطبيق من معالجة التقارب القائم إلى ملفات تعريف الارتباط، فلا يمكنك استخدام هذه الميزة. لكي يمكنك استخدامها، تأكد من أن العملاء دعم ملفات تعريف الارتباط.
Note
بعض فحوصات الثغرات يمكنها الإشارة إلى ملف تعريف الارتباط الخاص ببوابة التطبيق لأن علامات Secure أو HttpOnly غير مضبوطة. لا تأخذ عمليات الفحص هذه في الاعتبار أن البيانات الموجودة في ملف تعريف الارتباط يتم إنشاؤها باستخدام تجزئة أحادية الاتجاه. لا يحتوي ملف تعريف الارتباط على أي معلومات مستخدم ويستخدم فقط للتوجيه.
جلب تحديث متصفح Chromiumv80 تفويضا حيث يجب التعامل مع ملفات تعريف ارتباط HTTP بدون سمة SameSite على أنها SameSite = Lax. بالنسبة لطلبات CORS (مشاركة الموارد عبر المنشأ) ، إذا كان يجب إرسال ملف تعريف الارتباط في سياق طرف ثالث ، فيجب عليه استخدام SameSite = None. سمات آمنة ويجب إرسالها عبر HTTPS فقط. وإلا، في سيناريو HTTP فقط، لا يرسل المستعرض ملفات تعريف الارتباط في سياق الجهة الخارجية. الهدف من هذا التحديث من Chrome هو تعزيز الأمان وتجنب هجمات التزوير عبر الموقع (CSRF).
لدعم هذا التغيير، بدءا من 17 فبراير 2020، ستقوم Application Gateway (جميع أنواع SKU) بحقن ملف تعريف ارتباط آخر يسمى ApplicationGatewayAffinityCORS بالإضافة إلى ملف تعريف ارتباط ApplicationGatewayAffinity الحالي. يحتوي ملف تعريف الارتباط ApplicationGatewayAffinityCORS على سمتين أخريين تمت إضافتهما إليه ("SameSite=None; آمن") بحيث يتم الاحتفاظ بالجلسات اللاصقة حتى للطلبات عبر الأصل.
اسم ملف تعريف ارتباط التقارب الافتراضي هو ApplicationGatewayAffinity ويمكنك تغييره. إذا كنت في تخطيط الشبكة الخاص بك، يمكنك نشر بوابات تطبيق متعددة في سطر، يجب تعيين أسماء ملفات تعريف الارتباط الفريدة لكل مورد. إذا كنت تستخدم اسم كوكي مخصص للآراء، يضاف كوكيز آخر كلاحقة CORS . على سبيل المثال: CustomCookieNameCORS.
Note
إذا تم تعيين السمة SameSite=None ، فمن الضروري أن يحتوي ملف تعريف الارتباط أيضا على علامة Secure ، ويجب إرساله عبر HTTPS. إذا كان تقارب الجلسة مطلوبًا عبر CORS، فيجب عليك ترحيل عبء العمل إلى HTTPS. راجع تفريغ TLS ووثائق TLS من طرف إلى طرف لبوابة التطبيق. راجع نظرة عامة على طبقة المقابس الآمنة، وتكوين بوابة تطبيق باستخدام إنهاء طبقة النقل الآمنة، وتكوين طبقة النقل الآمنة من طرف إلى طرف.
استنزاف الاتصال
يساعدك استنزاف الاتصال على إزالة أعضاء مجموعة الخلفية بشكل أنيق أثناء تحديثات الخدمة المخطط لها، أو النشر المستمر، أو أحداث التوسع، أو تحديثات تكوين البوابة. استخدم استنزاف الاتصال لتقليل أخطاء 502 المتقطعة وفقدان الاتصال عند إزالة نسخ الخلفية بشكل صريح من مجموعة الخلفية.
يمكنك تطبيق هذا الإعداد على جميع أعضاء تجمع الخلفية عن طريق تمكين استنزاف الاتصال في إعداد الواجهة الخلفية. يضمن أن جميع مثيلات إلغاء التسجيل في تجمع الخلفية لا تتلقى أي طلبات/اتصالات جديدة مع الحفاظ على الاتصالات الموجودة حتى قيمة المهلة المكونة. هذه العملية صحيحة أيضا لاتصالات WebSocket.
| نوع التكوين | Value |
|---|---|
| القيمة الافتراضية عند عدم تمكين "استنزاف الاتصال" في إعداد الواجهة الخلفية | 30 ثانية |
| القيمة المعرفة من قبل المستخدم عند تمكين استنزاف الاتصال في إعداد الواجهة الخلفية | من 1 إلى 3,600 ثانية |
الاستثناء الوحيد لهذه العملية هو الطلبات المرتبطة بإزالة تسجيل المثيلات بسبب ترابط الجلسة المدارة بواسطة البوابة. ولا تزال هذه الطلبات تحال إلى مثيلات إلغاء التسجيل.
Note
هناك قيود حيث سينهي تحديث التكوين الاتصالات المستمرة بعد انتهاء مهلة استنزاف الاتصال. لمعالجة هذا القيد، يجب عليك زيادة مهلة استنزاف الاتصال في إعدادات الخلفية إلى قيمة أعلى من الحد الأقصى المتوقع لتحميل العميل.
لتحديث مهلة استنزاف الاتصال باستخدام Azure CLI، شغل az network application-gateway http-settings update وقم بتعيين --connection-draining-timeout في إعدادات HTTP الخلفية. قيمة 0 تعطل استنزاف الاتصال، وقيم من 1 إلى 3,600 ثانية تفعل ذلك.
Note
إذا لاحظت أخطاء 502 متقطعة أثناء النشر، أو التحديثات المتدفقة، أو أحداث التوسع، فقد يكون مهلة استنزاف الاتصال قصيرة جدا. ارفع --connection-draining-timeout إلى قيمة أكبر من الحد الأقصى المتوقع لوقت نقل العملاء.
Protocol
تدعم بوابة التطبيق كلا من HTTP وHTTPS لتوجيه الطلبات إلى خوادم الواجهة الخلفية. إذا اخترت HTTP، فإن نسبة استخدام الشبكة إلى الخوادم الخلفية غير مشفرة. إذا لم يكن الاتصال غير المشفر مقبولًا، قم باختيار HTTPS.
يدعم هذا الإعداد جنبا إلى جنب مع HTTPS في المستمع طبقة النقل الآمنة الشاملة. يتيح لك ذلك نقل البيانات الحساسة المشفرة إلى النهاية الخلفية بأمان. يجب تكوين كل خادم خلفي في تجمع الواجهة الخلفية الذي تم تمكين TLS من طرف إلى طرف بشهادة للسماح بالاتصال الآمن.
Port
يحدد هذا الإعداد المنفذ حيث تستمع خوادم الواجهة الخلفية إلى نسبة استخدام الشبكة من بوابة التطبيق. يمكنك تكوين منافذ تتراوح من 1 إلى 65535.
شهادة الجذر الموثوق بها
عند اختيار بروتوكول HTTPS في إعدادات الخلفية، يستخدم مورد بوابة التطبيق مخزن شهادات CA الجذر الموثوق الافتراضي للتحقق من سلسلة وأصالة الشهادة المقدمة من الخادم الخلفي.
بشكل افتراضي، يتضمن مورد Application Gateway شهادات CA شائعة، ما يسمح باتصالات TLS الخلفية السلسة عند إصدار شهادة الخادم الخلفي من قبل المرجع المصدق العام. ومع ذلك، إذا كنت تنوي استخدام مرجع مصدق خاص أو شهادة تم إنشاؤها ذاتيا مع التحقق من صحة TLS الكامل، فيجب عليك توفير شهادة المرجع المصدق الجذر (.cer) المقابلة في تكوين إعدادات الواجهة الخلفية.
إعدادات التحقق من صحة HTTPS الخلفية
عند اختيار HTTPS في إعدادات الخلفية ل Azure Application Gateway، تقوم البوابة بالتحقق الكامل من التحقق من TPS مع إنشاء اتصال آمن مع خوادم الخلفية. تشمل عمليات التحقق هذه ما يلي:
- التحقق من سلسلة الشهادات لضمان الوثوق بالشهادة.
- التحقق من اسم موضوع الشهادة مقابل إشارة اسم الخادم (SNI) التي تم إرسالها بواسطة بوابة التطبيق.
- التحقق من انتهاء صلاحية الشهادة لتأكيد ما إذا كانت الشهادة لا تزال صالحة.
تضمن إعدادات التحقق الافتراضية اتصال TLS الآمن بين خدمات البوابة والواجهة الخلفية. في بعض السيناريوهات، قد يكون من الضروري تعديل واحد أو أكثر من هذه الإعدادات. لاستيعاب متطلبات العملاء المتنوعة، توفر Application Gateway الخيارات القابلة للتكوين التالية. يمكنك استخدام أي من الخيارين أو كليهما حسب الحاجة.
| الخصائص | Values |
|---|---|
| validateCertChainAndExpiry | النوع: منطقي (صواب أو خطأ). الإعداد الافتراضي هو true. يؤدي هذا إلى التحقق من كل من سلسلة الشهادات والتحقق من انتهاء الصلاحية أو تخطيها. |
| validateSNI | النوع: منطقي (صواب أو خطأ). الإعداد الافتراضي هو true. يتحقق مما إذا كان الاسم الشائع للشهادة التي يوفرها خادم الواجهة الخلفية يتطابق مع قيمة إشارة اسم الخادم (SNI) التي تم إرسالها بواسطة بوابة التطبيق. |
| sniName | النوع: سلسلة. هذه الخاصية مطلوبة فقط عند تعيين validateSNI على أنها صحيحة. يمكنك تحديد قيمة SNI لمطابقة الاسم الشائع للشهادة على الواجهة الخلفية. بشكل افتراضي، تستخدم بوابة التطبيق رأس مضيف الطلب الوارد باعتباره SNI. |
Note
- نوصي بتمكين جميع عمليات التحقق من الصحة لبيئات الإنتاج. يقترح تعطيل بعض عمليات التحقق من الصحة أو جميعها فقط لأغراض الاختبار والتطوير، مثل استخدام الشهادات الموقعة ذاتيا.
- لا تنطبق هذه الإعدادات على وظيفة فحص الاختبار عند إضافة فحص صحي مخصص. وبالتالي، يمكنك ملاحظة اختلافات في النتائج عند المقارنة مع الفحوصات الصحية الدورية.
- حاليا، غير مدعوم لوكيل TLS.
- سيتم دعم PowerShell وCLI قريبا.
مهلة الطلب
هذا الإعداد هو عدد الثوابت التي تنتظرها بوابة التطبيق لتلقي استجابة من الخادم الخلفي. القيمة الافتراضية هي 20 ثانية. ومع ذلك، يمكنك تعديل هذا الإعداد حسب احتياجات طلبك. تتراوح القيم المقبولة من ثانية إلى 86400 ثانية (24 ساعة).
تجاوز مسار الواجهة الخلفية
يتيح لك هذا الإعداد تكوين مسار إعادة توجيه مخصص اختياري لاستخدامه عندما يتم إعادة توجيه الطلب إلى النهاية الخلفية. يتم نسخ أي جزء من المسار الوارد الذي يطابق المسار المخصص في الحقل مسار الواجهة الخلفية للتجاوز إلى المسار المعاد توجيهه. يوضح الجدول الآتي كيفية عمل هذه الميزة:
عند إرفاق إعداد HTTP بقاعدة التحويل الطلب الأساسية:
الطلب الأصلي تجاوز مسار الواجهة الخلفية أطلب إعادة توجيهه إلى النهاية الخلفية /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ عند إرفاق إعداد HTTP إلى قاعدة التحويل الطلب القائمة إلى المسار:
الطلب الأصلي قاعدة المسار تجاوز مسار الواجهة الخلفية أطلب إعادة توجيهه إلى النهاية الخلفية /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
استخدم التحقيق المخصص
يربط هذا الإعداد مسبارا مخصصا بإعداد HTTP. يمكنك إقران تحقيق مخصص واحد فقط بإعداد HTTP. إذا لم تقم بإقران فحص مخصص بشكل صريح، استخدام الفحص الافتراضي لمراقبة صحة الواجهة الخلفية. نوصي بإنشاء تحقيق مخصص لمزيد من التحكم في مراقبة صحة النهايات الخلفية.
Note
لا يراقب الفحص المخصص صحة تجمع الواجهة الخلفية ما لم يكن إعداد HTTP المقابل مقترنا بشكل صريح بمستمع.
تكوين اسم المضيف
تسمح Application Gateway للاتصال الذي تم إنشاؤه بالواجهة الخلفية باستخدام اسم مضيف مختلف عن الاسم الذي يستخدمه العميل للاتصال ب Application Gateway. في حين أن هذا التكوين يمكن أن يكون مفيدا في بعض الحالات، يجب توخي الحذر عند تجاوز اسم المضيف بحيث يختلف بين بوابة التطبيق والعميل مقارنة بهدف الواجهة الخلفية.
في بيئات الإنتاج، من أفضل الممارسات استخدام نفس اسم المضيف للعميل لاتصال بوابة التطبيق وبوابة التطبيق للاتصال الهدف الخلفي. تتجنب هذه الممارسة المشكلات المحتملة مع عناوين URL المطلقة وعناوين URL لإعادة التوجيه وملفات تعريف الارتباط المرتبطة بالمضيف.
قبل إعداد Application Gateway الذي ينحرف عن ذلك، راجع الآثار المترتبة على هذا التكوين كما تمت مناقشته بمزيد من التفصيل في Architecture Center: الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به
هناك جانبان من إعداد HTTP يؤثران على Host عنوان HTTP الذي تستخدمه بوابة التطبيق للاتصال بالواجهة الخلفية:
- "اختر اسم المضيف من عنوان الواجهة الخلفية"
- "تجاوز اسم المضيف"
اختيار اسم المضيف من عنوان الواجهة الخلفية
تقوم هذه الإمكانية بتعيين رأس المضيف في الطلب ديناميكيا إلى اسم المضيف لتجمع الواجهة الخلفية. يستخدم عنوان IP أو FQDN.
تساعد هذه الميزة عندما يختلف اسم المجال للنهاية الخلفية عن اسم DNS لبوابة التطبيق، ويعتمد النهاية الخلفية على عنوان مضيف معين لحله إلى نقطة النهاية الصحيحة.
مثال على ذلك هو الخدمات متعددة المستأجرين كواجهة خلفية. خدمة التطبيق هي خدمة متعددة المستأجرين تستخدم مساحة مشتركة بعنوان IP واحد. لذلك، لا يمكن الوصول إلى خدمة التطبيق إلا من خلال أسماء المضيفين التي تم تكوينها في إعدادات المجال المخصصة.
بشكل افتراضي، يكون اسم المجال المخصص example.azurewebsites.net. للوصول إلى خدمة التطبيق باستخدام بوابة تطبيق من خلال اسم مضيف غير مسجل بشكل صريح في خدمة التطبيق أو من خلال FQDN الخاص ببوابة التطبيق، يمكنك تجاوز اسم المضيف في الطلب الأصلي إلى اسم مضيف خدمة التطبيق. للقيام بذلك، قم بتمكين اختيار اسم المضيف من إعداد عنوان الخلفية.
بالنسبة لمجال مخصص تم تعيين اسم DNS المخصص الموجود له إلى خدمة التطبيق، فإن التكوين الموصى به ليس لتمكين اختيار اسم المضيف من عنوان الواجهة الخلفية.
Note
هذا الإعداد غير مطلوب ل App Service Environment، وهو نشر مخصص.
تجاوز اسم مضيف
تستبدل هذه الإمكانية رأس المضيف في الطلب الوارد على بوابة التطبيق باسم المضيف الذي تحدده.
على سبيل المثال، إذا www.contoso.com تم تحديده في إعداد اسم المضيف ، يتم تغيير الطلب الأصلي *https://appgw.eastus.cloudapp.azure.com/path1 إلى *https://www.contoso.com/path1 عند إعادة توجيه الطلب إلى خادم الواجهة الخلفية.
اتصال خلفي مخصص
Azure Application Gateway، بشكل افتراضي، يعيد استخدام الاتصالات الخلفية الخاملة لتحسين استخدام موارد اتصالات TCP لكل من بوابة التطبيق والخادم الخلفي. لدعم وظائف الأمان في مسارات بيانات العملاء التي تتطلب اتصالات خلفية فريدة لكل عميل، يوفر Azure Application Gateway V2 اتصالات مخصصة لخوادم الخلفية.
تعمل هذه الإمكانية على إنشاء تعيين مباشر فردي بين اتصالات الواجهة الأمامية والخلفية، مما يضمن الاتصال المستمر لكل عميل على حدة.
Important
راجع الاعتبارات التالية قبل تفعيل الاتصال المخصص للواجهة الخلفية على بوابة التطبيق:
- دعم NTLM/Kerberos: يتطلب مصادقة NTLM وKerberos تمريرا توازنا واحدا لواحد بين اتصالات الواجهة الأمامية والخلفية للحفاظ على سلامة الجلسة. قم بتفعيل الاتصال الخلفي المخصص لدعم هذه البروتوكولات.
- العملاء القديمون: العملاء القديمون مثل MSIE6 أو التطبيقات التي تستخدم توقيعات User-Agent القديمة لا يمكنهم دعم ميزات HTTP الحديثة وسلوكيات إدارة الاتصال بشكل كامل. لتحسين الموثوقية والمساعدة في منع مشاكل مثل الاستجابات غير المكتملة أو التالفة، تطبق Azure Application Gateway معالجة توافق إضافية بشكل افتراضي. عند تفعيل ميزة الاتصال الخلفي المخصص، يمكن أن يؤدي هذا التعامل مع التوافق إلى اختلافات في سلوك الاتصال للعملاء القدامى الذين لديهم NTLM، مما قد يؤدي إلى عدم اتساق الاتصال. للحصول على أفضل موثوقية وسلوك متوقع، ينصح باستخدام عملاء حديثين ومتوافقين مع المعايير أو ترقية العملاء القديمين حيثما أمكن.
- تخطيط السعة: يؤدي الاتصال الخلفي المخصص إلى زيادة عدد الاتصالات الخلفية، وبالتالي قد يتطلب موارد أكثر لدعم الاتصالات المتزامنة المتزايدة على بوابة التطبيقات والخوادم الخلفية. في Application Gateway، قم بزيادة عدد العينات أو تمكين التدرج التلقائي لاستيعاب الحمل.
- استهلاك منفذ SNAT: عندما يكون الخلف خادما بعيدا، يستهلك كل اتصال عميل منفذ SNAT مخصص، مما يزيد من خطر استنفاد منفذ SNAT. للحصول على الإرشاد، راجع أفضل الممارسات المعمارية.
- دعم البروتوكول: الاتصال المخصص للواجهة الخلفية غير مدعوم مع HTTP/2.
استكشاف أخطاء 4xx باستخدام اتصالات خلفية مخصصة
عندما يتم تفعيل Dedicated Backend Connections لإعداد خلفية، ويعيد تطبيق الواجهة الخلفية رموز حالة 4xx، استخدم الإرشادات التالية لتشخيص المشكلة وحلها.
التحقق من اسم الشركة الرئيسية (SPN) تتطلب آليات التوثيق-التوثيق مثل NTLM وKerberos أسماء رئيسية الخدمة المسجلة بشكل صحيح. تأكد من أن شبكات SPN مهيأة بشكل صحيح وفريدة في الدليل للسماح بالمصادقة الناجحة. لمزيد من المعلومات، راجع وثائق كيربيروس.
مراجعة سجلات خادم الواجهة الخلفية لرموز الحالة الفرعية - بوابة التطبيقات تظهر فقط حالة HTTP الأساسية (على سبيل المثال، 401 غير مصرح به). لتحديد السبب الأساسي، راجع سجلات الخادم الخلفي للحصول على معلومات أكثر تفصيلا عن الحالة الفرعية. للإرشاد، يرجى الرجوع إلى تكوين المصادقة Windows.