مشاركة عبر


المشكلات والقيود المعروفة لجدار حماية Azure

تسرد هذه المقالة المشكلات المعروفة لجدار حماية Azure ويتم تحديثها عند حلها.

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

هام

قيود السعة

تواجه المناطق التالية حاليا قيود على السعة لكل من وحدات SKU القياسية والمتميزة:

المناطق القيود التوصية
- المنطقة المادية 2 في المنطقة المادية 3 في شمال أوروبا
-
في جنوب شرق آسيا
- لا يمكنك نشر جدار حماية Azure جديد إلى المنطقة 3 في جنوب شرق آسيا أو المنطقة 2 في شمال أوروبا.

- إذا أوقفت جدار حماية Azure الموجود الذي تم نشره في هذه المنطقة، فلا يمكن إعادة تشغيله.

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

معيار جدار الحماية Azure

يواجه Azure Firewall Premium المشكلات المعروفة التالية:

المشكلة ‏‏الوصف التخفيف
يقتصر دعم DNAT لعناوين IP الخاصة على الإصدارات القياسية والمميزة دعم DNAT على عنوان IP الخاص لجدار حماية Azure مخصص للمؤسسات، لذلك يقتصر على إصدارات جدار الحماية القياسي والمميز. بلا
لا تعمل قواعد تصفية الشبكات الخاصة ببروتوكولات غير TCP/UDP (بروتوكول ICMP على سبيل المثال) مع نسبة استخدام شبكة محددة بالإنترنت لا تعمل قواعد تصفية الشبكات الخاصة ببروتوكولات غير TCP/UDP مع الترجمة من نوع SNAT على عنوان IP العام. يُدعم استخدام بروتوكولات غير TCP/UDP بين الشبكات الفرعية في النظام المحوري وشبكات VNet. تستخدم خدمة Azure Firewall موازن التحميل القياسي الذي لا يدعم الترجمة من نوع SNAT لبروتوكولات IP في الوقت الحالي. نعمل على استكشاف خيارات لدعم هذا السيناريو في أي إصدار مستقبلي.
فقدان دعم تقنية PowerShell وواجهة CLI مع بروتوكول ICMP لا تدعم بيئة Azure PowerShell وواجهة CLI بروتوكول ICMP باعتباره بروتوكولاً صالحاً في قواعد الشبكة. لا يزال من الممكن استخدام ICMP كبروتوكول عبر المدخل وواجهة برمجة تطبيقات REST. نحن نعمل على إضافة بروتوكول ICMP في تقنية PowerShell وواجهة CLI قريباً.
تتطلب علامات FQDN استخدام بروتوكول: من المقرر تعيين المنفذ تتطلب قواعد التطبيق المزودة بعلامات FQDN منفذًا: تعريف البروتوكول. يمكنك استخدام https كمنفذ: قيمة البروتوكول. نعمل على جعل هذا الحقل اختياريًا عند استخدام علامات FQDN.
نقل جدار حماية إلى مجموعة موارد أخرى أو اشتراك آخر غير مدعوم نقل جدار حماية إلى مجموعة موارد أخرى أو اشتراك آخر غير مدعوم. دعم هذه الوظيفة موجود على خارطة الطريق لدينا. لنقل جدار حماية إلى مجموعة موارد أخرى أو اشتراك آخر، يجب حذف المثيل الحالي وإعادة إنشاؤه في مجموعة الموارد الجديدة أو الاشتراك الجديد.
قد يتم إخفاء تنبيهات التحليل الذكي للمخاطر إن قواعد الشبكة المزودة بالوجهة 80/443 فيما يتعلق بتصفية الصادرات تُخفي تنبيهات التحليل الذكي للمخاطر عند تكوينها على وضع "التنبيه فقط". إنشاء تصفية للصادرة بالنسبة للوجهة 80/443 باستخدام قواعد التطبيق. أو تغيير وضع التحليل الذكي للمخاطر إلى تنبيه ورفض.
مع المراكز الظاهرية الآمنة، يمكن تكوين مناطق التوفر فقط أثناء النشر. لا يمكنك تكوين مناطق التوفر بعد نشر جدار حماية مع مراكز ظاهرية آمنة. وهو كذلك بسبب طبيعة تصميمه.
خدمة الترجمة SNAT على الاتصالات الواردة تخضع الاتصالات المقامة عبر عنوان IP العام في جدار الحماية (الواردة) إلى الترجمة من نوع SNAT التي تُطبق على أحد عناوين IP الخاصة في جدار الحماية، بالإضافة إلى نوع DNAT. يهدف هذا المطلب حاليًا (بالنسبة لأدوات NVA النشطة/النشطة أيضًا) إلى ضمان التوجيه المتماثل. للاحتفاظ بالمصدر الأصلي لبروتوكول HTTP/S، خذ بعين الاعتبار استخدام رؤوس XFF. على سبيل المثال، استخدم خدمة مثل AzureAzure Front Door أو Azure Application Gateway أمام جدار الحماية. يمكنك أيضًا إضافة ميزة WAF كجزء من خدمة Azure Front Door وتكوين سلسلة بها في جدار الحماية.
تصفية SQL FQDN مدعومة فقط في وضع الوكيل (المنفذ 1433) بالنسبة إلى قاعدة بيانات Azure SQL Database وخدمة Azure Synapse Analytics وخدمة Azure SQL Managed Instance:

يتم دعم تصفية SQL FQDN في وضع الوكيل فقط (المنفذ 1433).

بالنسبة إلى خدمة Azure SQL IaaS:

إذا كنت تستخدم منافذ غير قياسية، يمكنك تحديد هذه المنافذ في قواعد التطبيق.
بالنسبة للغة SQL في وضع إعادة التوجيه (يعد ذلك هو الوضع الافتراضي إذا كان الاتصال من داخل منصة Azure)، يمكنك بدلاً من ذلك تصفية الوصول باستخدام علامة الخدمة SQL كجزء من قواعد الشبكة في خدمة Azure Firewall.
تم حظر نسبة استخدام الشبكة الصادر على بروتوكول SMTP من منفذ TCP رقم 25 يحظر النظام الأساسي Azure رسائل البريد الإلكتروني الصادرة المرسلة مباشرة إلى المجالات الخارجية (مثل outlook.com و gmail.com) على منفذ TCP 25. يُعد هذا هو سلوك النظام الأساسي الافتراضي في منصة Azure. لا يقدم جدار حماية Azure أي قيود أكثر تحديدا. استخدم خدمات ترحيل بواسطة بروتوكول SMTP مصدّق عليه، والتي عادة ما تتصل من خلال منفذ TCP رقم 587، لكنها تدعم منافذ أخرى أيضًا. للحصول على مزيد من المعلومات، راجع قسم استكشاف أخطاء مشكلات الاتصال الوارد بواسطة بروتوكول SMTP وإصلاحها في منصة Azure.

خيار آخر هو نشر Azure Firewall في اشتراك اتفاقية Enterprise القياسي (EA). يمكن لجدار حماية Azure في اشتراك EA الاتصال بعناوين IP العامة باستخدام منفذ TCP الصادر 25. قد يعمل في أنواع اشتراكات أخرى، ولكنه غير مضمون. بالنسبة لعناوين IP الخاصة مثل الشبكات الظاهرية والشبكات الظاهرية الخاصة وAzure ExpressRoute، يدعم جدار حماية Azure اتصالا صادرا على منفذ TCP 25.
استهلاك منفذ الترجمة من نوع SNAT يدعم Azure Firewall حاليا 2496 منفذا لكل عنوان IP عام لكل مثيل مجموعة مقياس الجهاز الظاهري الخلفية. بشكل افتراضي، هناك مثيلان لمجموعة مقياس الجهاز الظاهري. لذلك، هناك 4992 منفذا لكل تدفق (عنوان IP الوجهة ومنفذ الوجهة والبروتوكول (TCP أو UDP). يتدرج جدار الحماية إلى 20 مثيلاً كحد أقصى. هذا قيد على النظام الأساسي. يمكنك تجاوز الحدود من خلال تكوين عمليات نشر Azure Firewall باستخدام خمسة عناوين IP عامة كحد أدنى لعمليات النشر المعرضة لاستنفاد SNAT. وهذا يزيد من منافذ SNAT المتوفرة بمقدار خمس مرات. قم بالتخصيص بدءاً من بادئة عنوان IP لتبسيط أذونات انتقال البيانات من الخادم. للحصول على حل أ:ثر ديمومة، يمكنك نشر بوابة NAT للتغلب على حدود منفذ SNAT. يتم دعم هذا الأسلوب لنشر الشبكة الظاهرية.

لمزيدٍ من المعلومات، راجع قياس منافذ SNAT باستخدام بوابة Azure NAT.
الترجمة من نوع DNAT غير مدعومة عند تمكين الاتصال النفقي القسري إن جدران الحماية التي نُشرت أثناء تمكين الاتصال النفقي القسري لا يمكن أن تدعم الوصول الوارد من الإنترنت بسبب التوجيه غير المتماثل. وهذا يُحدد حسب التصميم بسبب التوجيه غير المتماثل. يمر مسار العودة المخصص للاتصالات الواردة عبر جدار الحماية الداخلي الذي لم يشهد على عملية إنشاء الاتصال.
قد لا يعمل بروتوكول نقل الملفات الخاملة الصادرة مع جدران الحماية ذات عناوين IP العامة المتعددة، اعتمادا على تكوين خادم FTP. يعمل بروتوكول FTP على إنشاء اتصالات مختلفة لقنوات التحكم والبيانات. عندما يُرسل جدار حماية مزود بعناوين IP عامة متعددة البيانات الصادرة، فإنه يحدد بشكل عشوائي عنواناً واحداً من عناوين IP العامة لديه لعنوان IP المصدر. قد تفشل FTP عندما تستخدم قنوات البيانات والتحكم عناوين IP مختلفة المصدر، اعتمادا على تكوين خادم FTP. يتم التخطيط لإجراء تكوين صريح للترجمة من نوع SNAT. في هذه الأثناء، يمكنك تكوين خادم FTP لديك ليقبل قنوات البيانات والتحكم من عناوين IP مصدر مختلفة (راجع مثال خدمة IIS). وبدلاً من ذلك، يمكنك الأخذ بعين الاعتبار استخدام عنوان IP واحد في هذه الحالة.
قد لا يعمل FTP السلبي الوارد استنادا إلى تكوين خادم FTP يعمل بروتوكول FTP على إنشاء اتصالات مختلفة لقنوات التحكم والبيانات. تخضع الاتصالات الواردة في خدمة Azure Firewall إلى الترجمة من نوع SNAT التي تُطبق على أحد عناوين IP الخاصة في جدار الحماية لضمان التوجيه المتماثل. قد تفشل FTP عندما تستخدم قنوات البيانات والتحكم عناوين IP مختلفة المصدر، اعتمادا على تكوين خادم FTP. ويجري التحقيق في الحفاظ على عنوان IP المصدر الأصلي. في هذه الأثناء، يمكنك تكوين خادم FTP لديك ليقبل قنوات البيانات والتحكم من عناوين IP مصدر مختلفة.
لا يعمل FTP النشط عندما يجب أن يصل عميل FTP إلى خادم FTP عبر الإنترنت. يستخدم بروتوكول نقل الملفات النشط أمر PORT من بروتوكول نقل ملفات كمبيوتر العميل لذي يوجه ملقم بروتوكول نقل الملفات عن كيفية استخدام IP وPORT لاستخدامها لقناة البيانات. يستخدم أمر PORT هذا عنوان IP الخاص للعميل الذي لا يمكن تغييره. نسبة استخدام الشبكة من جانب العميل التي تعبر جدار حماية Azure هي NATed للاتصالات المستندة إلى الإنترنت، ما يجعل الأمر PORT ينظر إليه على أنه غير صالح من قبل خادم FTP. هذا قيد عام على FTP النشط عند استخدامه مع NAT من جانب العميل.
هناك بُعد بروتوكولي مفقود في مقياس NetworkRuleHit يسمح مقياس ApplicationRuleHit باستخدام بروتوكول يستند إلى التصفية، لكن هذه الإمكانية مفقودة في مقياس NetworkRuleHit المُناظر. ويجري التحقيق في عملية الإصلاح.
قواعد NAT مع المنافذ التي تتراوح أرقامها بين 64000 و65535 غير مدعومة تسمح خدمة Azure Firewall باستخدام أي منفذ في نطاق 1-65535 في قواعد الشبكات والتطبيقات، لكن قواعد NAT تدعم المنافذ في نطاق 1-63999 فقط. يُعد هذا تقييداً حالياً.
قد تستغرق تحديثات التكوين خمس دقائق في المتوسط قد يستغرق تحديث تكوين خدمة Azure Firewall من ثلاث إلى خمس دقائق في المتوسط، كما أن التحديثات المتوازية غير مدعومة. ويجري التحقيق في عملية الإصلاح.
تستخدم خدمة Azure Firewall رؤوس بروتوكول TLS المزود بمؤشر SNI لتصفية نسبة استخدام الشبكة على بروتوكول HTTPS ونظام MSSQL إذا كان المستعرض أو برنامج الخادم لا يدعم ملحق مؤشر اسم الخادم (SNI)، فلا يمكنك الاتصال من خلال خدمة Azure Firewall. إذا كان المستعرض أو برنامج الخادم لا يدعم SNI، فقد تتمكن من التحكم في الاتصال باستخدام قاعدة شبكة بدلا من قاعدة تطبيق. راجع قسم الإشارة إلى اسم الخادم المخصص للبرنامج الذي يدعم مؤشر SNI.
لا يمكن إضافة علامات لنهج جدار الحماية باستخدام المدخل أو قوالب Azure Resource Manager (ARM) يحتوي نهج خدمة Azure Firewall على تقييد لدعم التصحيح يمنعك من إضافة أي علامة باستخدام مدخل Azure أو قوالب ARM. تم إنشاء الخطأ التالي: تعذر حفظ العلامات للمورد. ويجري التحقيق في عملية الإصلاح. أو يمكنك استخدام الأمر cmdlet Set-AzFirewallPolicy في بيئة Azure PowerShell لتحديث العلامات.
عنوان IPv6 غير مدعوم حالياً إذا أضفت عنوان IPv6 إلى أي قاعدة، فسيفشل عمل جدار الحماية. استخدم عناوين IPv4 فقط. ويجري التحقيق في دعم عناوين IPv6.
إزالة مجموعات RuleCollectionGroups باستخدام قوالب ARM غير مدعومة. إزالة RuleCollectionGroup باستخدام قوالب ARM غير مدعومة وتؤدي إلى فشل. هذه ليست عملية مدعومة.
ستؤدي قاعدة DNAT المنطوية على السماح باستخدام أي عنوان (*) إلى إجراء ترجمة من نوع SNAT لنسبة استخدام الشبكة. إذا كانت قاعدة DNAT تسمح بأي (*) كعنوان IP المصدر، فإن قاعدة الشبكة الضمنية تطابق نسبة استخدام الشبكة الظاهرية VNet وستتولى دائما SNAT نسبة استخدام الشبكة. يُعد هذا تقييداً حالياً.
إضافة قاعدة DNAT إلى مركز ظاهري آمن مع موفر أمان غير مدعوم. يؤدي هذا إلى إنشاء مسار غير متزامن فيما يتعلق بنسبة استخدام الشبكة العائدة في الترجمة من نوع DNAT، والتي تنتقل بدورها إلى موفر الأمان. ‏‏غير مدعومة.
حدث خطأ عند إنشاء أكثر من 2000 مجموعة قواعد. العدد الأقصى من مجموعات قواعد NAT/التطبيق أو مجموعات قواعد الشبكات هو 2000 (حد إدارة الموارد). يُعد هذا تقييداً حالياً.
عنوان XFF في HTTP/S تتم الكتابة فوق عناوين XFF بعنوان IP المصدر الأصلي كما يراه جدار الحماية. ينطبق هذا على حالات الاستخدام التالية:
طلبات HTTP
- طلبات HTTPS مع إنهاء TLS
ويجري التحقيق في عملية الإصلاح.
لا يمكن نشر جدار الحماية مع مناطق التوفر باستخدام عنوان IP عام تم إنشاؤه حديثاً عند نشر جدار حماية مع مناطق التوفر، لا يمكنك استخدام عنوان IP عام تم إنشاؤه حديثاً. قم أولاً بإنشاء عنوان IP عام مكرر لمنطقة جديدة، ثم قم بتعيين عنوان IP الذي تم إنشاؤه مسبقا أثناء نشر جدار الحماية.

Azure Firewall Premium

إشعار

تنطبق أي مشكلة تنطبق على Standard أيضاً على Premium.

يواجه Azure Firewall Premium المشكلات المعروفة التالية:

المشكلة ‏‏الوصف التخفيف
دعم ESNI لدقة FQDN في HTTPS لا يُدعم SNI المشفر في تأكيد اتصال HTTPS. وفي الوقت الحالي، متصفح Firefox فقط يدعم ESNI من خلال التكوين المخصص. ويكون الحل المقترح هو تعطيل هذه الميزة.
مصادقة شهادة العميل غير مدعومة تُستخدم شهادات العميل لإنشاء ثقة هوية متبادلة بين العميل والخادم. تُستخدم شهادات العميل أثناء تفاوض بروتوكول أمان طبقة النقل. يعيد Azure Firewall التفاوض بشأن الاتصال بالخادم وليس له حق الوصول إلى المفتاح الخاص لشهادات العميل. بلا
QUIC/HTTP3 إن QUIC هو الإصدار الرئيسي الجديد من HTTP. إنه بروتوكول يستند إلى UDP أكثر من 80 (PLAN) و443 (SSL). فحص FQDN/URL/TLS غير مدعوم. تكوين تمرير UDP 80/443 كقواعد للشبكة.
شهادات موقعة من عميل غير موثوق لا يثق جدار الحماية في الشهادات الموقعة من قبل العميل بمجرد تلقيها من خادم ويب قائم على الإنترانت. ويجري التحقيق في عملية الإصلاح.
إن عنوان IP للمصدر خاطئ في التنبيهات مع IDPS لـ HTTP (دون فحص TLS). عندما تكون حركة مرور HTTP بالنص العادي قيد الاستخدام، ويصدر IDPS تنبيهاً جديداً، والوجهة هي عنوان IP عام، يكون عنوان IP للمصدر المعروض خاطئاً (يتم عرض عنوان IP الداخلي بدلاً من عنوان IP الأصلي). ويجري التحقيق في عملية الإصلاح.
نشر الشهادة بعد تطبيق شهادة CA على جدار الحماية، قد يستغرق الأمر ما بين 5-10 دقائق حتى تصبح الشهادة سارية المفعول. ويجري التحقيق في عملية الإصلاح.
دعم TLS 1.3 يكون TLS 1.3 مدعوم جزئياً. يعتمد نفق TLS من العميل إلى جدار الحماية على TLS 1.2، ومن جدار الحماية إلى خادم الويب الخارجي يعتمد على TLS 1.3. يجري التحقيق في التحديثات.
انتهاء صلاحية شهادة المرجع المصدق الوسيط TLSi في بعض الحالات الفريدة، يمكن أن تنتهي صلاحية شهادة المرجع المصدق الوسيطة قبل شهرين من تاريخ انتهاء الصلاحية الأصلي. تجديد شهادة المرجع المصدق الوسيط قبل شهرين من تاريخ انتهاء الصلاحية الأصلي. ويجري التحقيق في عملية الإصلاح.

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