مشاركة عبر

تكوين إعدادات الواجهة الخلفية لبوابة التطبيق

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

أنواع إعدادات الواجهة الخلفية في بوابة التطبيق

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

  • إعدادات HTTP الخلفية - إنها لتكوينات وكيل الطبقة 7 التي تدعم بروتوكولات HTTP وHTTPS.
  • إعدادات الواجهة الخلفية - إنها لتكوينات وكيل الطبقة 4 (معاينة) التي تدعم بروتوكولات TLS وTCP.

تستخدم بوابة التطبيق Azure ملفات تعريف الارتباط المدارة عبر البوابة للحفاظ على جلسات المستخدم. عندما يرسل المستخدم الطلب الأول إلى 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 من طرف إلى طرف لبوابة التطبيق. راجع نظرة عامة على طبقة المقابس الآمنة، وتكوين بوابة تطبيق باستخدام إنهاء طبقة النقل الآمنة، وتكوين طبقة النقل الآمنة من طرف إلى طرف.

استنزاف الاتصال

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

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

نوع التكوين Value
القيمة الافتراضية عند عدم تمكين "استنزاف الاتصال" في إعداد الواجهة الخلفية 30 ثانية
القيمة المعرفة من قبل المستخدم عند تمكين استنزاف الاتصال في إعداد الواجهة الخلفية من 1 إلى 3600 ثانية

الاستثناء الوحيد لهذه العملية هو الطلبات المرتبطة بإزالة تسجيل المثيلات بسبب ترابط الجلسة المدارة بواسطة البوابة. ولا تزال هذه الطلبات تحال إلى مثيلات إلغاء التسجيل.

Note

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

Protocol

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

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

Port

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

شهادة الجذر الموثوق بها

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

بشكل افتراضي، يتضمن مورد Application Gateway شهادات CA شائعة، ما يسمح باتصالات TLS الخلفية السلسة عند إصدار شهادة الخادم الخلفي من قبل المرجع المصدق العام. ومع ذلك، إذا كنت تنوي استخدام مرجع مصدق خاص أو شهادة تم إنشاؤها ذاتيا مع التحقق من صحة TLS الكامل، فيجب عليك توفير شهادة المرجع المصدق الجذر (.cer) المقابلة في تكوين إعدادات الواجهة الخلفية.

إعدادات التحقق من صحة HTTPS الخلفية

عند تحديد HTTPS في إعدادات الواجهة الخلفية لبوابة تطبيق Azure، تقوم البوابة بإجراء التحقق الكامل من صحة مصافحة TLS أثناء إنشاء اتصال آمن مع خوادم الواجهة الخلفية. تشمل عمليات التحقق هذه ما يلي:

  1. التحقق من سلسلة الشهادات لضمان الوثوق بالشهادة.
  2. التحقق من اسم موضوع الشهادة مقابل إشارة اسم الخادم (SNI) التي تم إرسالها بواسطة بوابة التطبيق.
  3. التحقق من انتهاء صلاحية الشهادة لتأكيد ما إذا كانت الشهادة لا تزال صالحة.

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

رسم تخطيطي يوضح طريقة عرض المدخل لعناصر تحكم التحقق من صحة TLS المتوفرة للعملاء.

الخصائص 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 لكل من Application Gateway وخادم الواجهة الخلفية. لدعم وظائف الأمان في مسارات بيانات العملاء التي تتطلب اتصالات خلفية فريدة لكل عميل، يوفر Azure Application Gateway V2 اتصالات مخصصة لخوادم الواجهة الخلفية.

لقطة شاشة لتدفقات الشبكة من خلال وكيل Application Gateway من الطبقة 7.

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

Note

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

Important

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

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

اتصال الواجهة الخلفية المخصص غير مدعوم مع HTTP/2.

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

  • Last updated on