Azure Firewall FAQ

شائع

ما هو Azure Firewall؟

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

ما هي القدرات التي يدعمها Azure Firewall؟

للحصول على قائمة مفصلة بالميزات Azure Firewall، راجع Azure Firewall features.

ما هو نموذج النشر النموذجي ل Azure Firewall؟

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

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

كيف يمكنني نشر Azure Firewall؟

يمكن نشر Azure Firewall باستخدام بوابة Azure أو PowerShell أو واجهة برمجة تطبيقات REST أو القوالب. للحصول على تعليمات خطوة بخطوة، راجع Tutorial: نشر وتكوين Azure Firewall باستخدام Azure portal.

ما هي بعض المفاهيم الرئيسية ل Azure Firewall؟

يستخدم Azure Firewall القواعد ومجموعات القواعد. مجموعة القواعد هي مجموعة من القواعد بنفس الترتيب والأولوية. يتم تنفيذ مجموعات القواعد بترتيب الأولوية. تتمتع مجموعات قواعد DNAT بأولوية أعلى من مجموعات قواعد الشبكة، والتي بدورها لها أولوية أعلى من مجموعات قواعد التطبيق. يتم إنهاء جميع القواعد.

هناك ثلاثة أنواع من مجموعات القواعد:

• قواعد التطبيق: تكوين أسماء النطاقات المؤهلة بالكامل (FQDNs) التي يمكن الوصول إليها من شبكة افتراضية.
• قواعد الشبكة: تكوين القواعد باستخدام عناوين المصدر، والبروتوكولات، ومنافذ الوجهة، وعناوين الوجهة.
• قواعد NAT: قم بتكوين قواعد DNAT للسماح باتصالات الإنترنت أو الإنترانت الواردة (المعاينة).

لمزيد من المعلومات، راجع تكوين قواعد Azure Firewall.

أي خدمات تسجيل وتحليلات يدعمها Azure Firewall؟

Azure Firewall يتكامل مع Azure Monitor لعرض وتحليل السجلات. يمكن إرسال السجلات إلى Log Analytics أو تخزين Azure أو Event Hubs وتحليلها باستخدام أدوات مثل Log Analytics أو Excel أو Power BI. لمزيد من المعلومات، راجع Tutorial: مراقبة سجلات Azure Firewall.

كيف يختلف Azure Firewall عن أنظمة NVA الموجودة في السوق؟

Azure Firewall هو خدمة أمن شبكات مدارة قائمة على السحابة تحمي موارد الشبكة الافتراضية. تتسم هذه الخدمة بأنها جدار حماية ذي حالة خاصة بالكامل ذي قابلية وصول عالية مضمنة وقابلية توسع سحابة غير مقيدة. يتم إعداده مسبقا مع موفري الأمان كخدمة (SECaaS) التابعين لجهة خارجية لتحسين الأمان للشبكة الظاهرية واتصالات الإنترنت الفرعية. لمزيد من المعلومات، راجع Azure أمن الشبكات.

ما الفرق بين Application Gateway WAF و Azure Firewall؟

يوفر Application Gateway WAF حماية واردة مركزية لتطبيقات الويب ضد الاستغلالات والثغرات الأمنية الشائعة. يوفر Azure Firewall حماية واردة للبروتوكولات غير التابعة ل HTTP/S (مثل RDP وSSH وFTP)، وحماية على مستوى الشبكة الصادرة لجميع المنافذ والبروتوكولات، وحماية على مستوى التطبيق لبروتوكولات HTTP/S الصادرة.

ما الفرق بين مجموعات أمن الشبكات (NSGs) وAzure Firewall؟

يكمل Azure Firewall عناصر NSG لتوفير أمان شبكة "دفاعي معمق" أفضل. تقدم مجموعات أمان الشبكة تصفية حركة مرور طبقة الشبكة الموزعة للحد من نسبة استخدام الشبكة داخل الشبكات الظاهرية في كل اشتراك. يوفر Azure Firewall حماية مركزية وكاملة الحالة على مستوى الشبكة والتطبيق عبر الاشتراكات والشبكات الافتراضية.

هل مجموعات أمان الشبكة (NSGs) معتمدة على AzureFirewallSubnet؟

Azure Firewall هو خدمة مدارة مع طبقات حماية متعددة، بما في ذلك حماية المنصة باستخدام NSGs على مستوى شبكة الشبكة (غير قابلة للعرض). NSGs على مستوى الشبكة الفرعية غير مطلوبة على AzureFirewallSubnet ويتم تعطيلها لمنع انقطاع الخدمة.

ما هي القيمة المضافة ل Azure Firewall مع نقاط النهاية الخاصة؟

النقاط النهائية الخاصة هي مكون من تقنية Private Link، وهي تقنية تتيح التفاعل مع خدمات Azure PaaS باستخدام عناوين IP الخاصة بدلا من العناوين العامة. يمكن استخدام Azure Firewall لمنع الوصول إلى عناوين IP العامة، وبالتالي تجنب تسريب البيانات إلى خدمات Azure التي لا تستخدم Private Link، وكذلك لتنفيذ سياسات الثقة الصفرية من خلال تحديد من في مؤسستك يحتاج للوصول إلى خدمات Azure PaaS تلك، منذ Private Link بشكل افتراضي يفتح الوصول إلى الشبكة لشبكة الشركة بأكملها.

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

ما هي القيمة المضافة ل Azure Firewall مع نقاط نهاية خدمة الشبكة الافتراضية؟

نقاط نهاية خدمة Virtual Network هي بديل ل Private Link للتحكم في الوصول إلى الشبكة إلى خدمات Azure PaaS. حتى إذا كان العميل لا يزال يستخدم عناوين IP العامة للوصول إلى خدمة PaaS، يتم جعل الشبكة الفرعية المصدر مرئية بحيث يمكن لخدمة PaaS الوجهة تنفيذ قواعد التصفية وتقييد الوصول على أساس كل شبكة فرعية. يمكنك العثور على مقارنة مفصلة بين الآليين في مقارنة نقاط النهاية الخاصة ونقاط نهاية الخدمة.

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

ما هو سعر Azure Firewall؟

لتفاصيل الأسعار، راجع Azure Firewall السعر.

ما هي حدود الخدمة المعروفة ل Azure Firewall؟

لحدود الخدمة، انظر Azure حدود الاشتراك والخدمات، الحصص، والقيود.

أين يخزن Azure Firewall بيانات العملاء؟

Azure Firewall لا ينقل أو يخزن بيانات العملاء خارج المنطقة التي تم نشرها فيها.

هل يدعم Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) في قطر؟

لا، Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) غير مدعوم حاليا في قطر.

القدرات والميزات المدعومة

هل يدعم Azure Firewall تصفية حركة المرور الواردة؟

نعم، يدعم Azure Firewall كل من تصفية الحركة الواردة والصادرة. عادة ما تستخدم التصفية الواردة للبروتوكولات غير HTTP مثل RDP وSSH وFTP. بالنسبة لحركة مرور HTTP وHTTPS الواردة، فكر في استخدام جدار حماية تطبيقات ويب مثل Azure Web Application Firewall (WAF) أو ميزات تفريغ TLS وفحص الحزم العميق في Azure Firewall Premium.

هل يدعم Azure Firewall Basic النفق القسري؟

نعم، Azure Firewall Basic يدعم النفق القسري.

لماذا يبدو أن اختبار اتصال TCP أو أداة مشابهة للاتصال ب FQDN هدف حتى عندما لا تسمح أي قاعدة بنسبة استخدام الشبكة؟

لا يتصل اختبار اتصال TCP فعليا ب FQDN الهدف. Azure Firewall يمنع الاتصالات بأي عنوان IP مستهدف أو FQDN ما لم يسمح بذلك صراحة قاعدة معينة.

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

هل يدعم Azure Firewall الارتباط ب BGP؟

لا، Azure Firewall لا يدعم بشكل أصلي الارتباط ب BGP. ومع ذلك، فإن ميزة طرق SNAT للتعلم التلقائي تستخدم بشكل غير مباشر BGP عبر Azure Route Server.

هل يمكن ل Azure Firewall تمرير حزم ESP (IPSec VPN)؟

Azure Firewall لا يدعم ESP (تغليف حمولة الأمان)، لكن يمكنك السماح بحركة ESP عن طريق تكوين قاعدة شبكة كما يلي:

تكوين Azure Firewall (قاعدة الشبكة):

• البروتوكول: أي
• المصدر المنفذي: * (أي إصدار)
• منفذ الوجهة: * (أي منفذ)
• المصدر/الوجهة: حدد عناوين IP حسب الحاجة

يسمح هذا التكوين لحزم ESP (رقم بروتوكول IP 50) وحركة المرور غير TCP/UDP الأخرى بمطابقة القاعدة. ومع ذلك، لاحظ أن Azure Firewall لا يفحص حمولات ESP الخاصة ب ESP.

مرجع: إذا استخدمت مجموعة أمن الشبكة (NSG) بدلا من Azure Firewall: لا توفر NSG خيارا مباشرا لتحديد بروتوكول ESP (رقم بروتوكول IP 50)، لكن يمكن السماح بحزم ESP باستخدام الإعدادات التالية:

• البروتوكول: أي
• النقل: * (أي إصدار)
• المصدر/الوجهة: حدد عناوين IP حسب الحاجة

التوصيات

• بالنسبة لإعدادات IPsec VPN، ينصح باستخدام Azure VPN Gateway.
• فكر في استخدام نمط NVA (جهاز افتراضي شبكي) حسب متطلباتك.

الإدارة والتكوين

كيف يمكنني إيقاف وتشغيل Azure Firewall؟

يمكنك استخدام Azure PowerShell لتخصيص وتوزيع Azure Firewall. تختلف العملية اعتمادا على التكوين.

بالنسبة لجدار حماية بدون بطاقة تحكم إدارية:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

بالنسبة لجدار حماية مع بطاقة شبكة إدارة:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

بالنسبة لجدار حماية في مركز افتراضي آمن:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

إشعار

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

كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟

يوصى بتكوين مناطق التوفر أثناء النشر الأولي. ومع ذلك، يمكنك إعادة تكوينها بعد التوزيع إذا:

• يتم نشر جدار الحماية في شبكة ظاهرية (غير مدعوم في المراكز الظاهرية الآمنة).
• تدعم المنطقة مناطق التوفر.
• يتم تكوين جميع عناوين IP العامة المرفقة بنفس المناطق.

لإعادة تكوين مناطق التوفر:

1. إلغاء تخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. تحديث تكوين المنطقة وتخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

هل هناك أي قيود على مجموعات موارد جدار الحماية في Azure؟

نعم:

• يجب أن يكون Azure Firewall والشبكة الافتراضية في نفس مجموعة الموارد.
• يمكن أن يكون عنوان IP العام في مجموعة موارد مختلفة.
• يجب أن تكون جميع الموارد (جدار الحماية Azure، الشبكة الافتراضية، عنوان IP العام) ضمن نفس الاشتراك.

ماذا تعني حالة التوفير **Failed** ؟

حالة فشل التوفير تشير إلى فشل تحديث التكوين في حالة واحدة أو أكثر من مثيلات الخلفية. يبقى Azure Firewall يعمل، لكن التكوين قد يكون غير متسق. أعد محاولة التحديث حتى تتغير حالة التوفير إلى ناجح.

كيف يتعامل Azure Firewall مع الصيانة المخططة والأعطال غير المخططة؟

يستخدم Azure Firewall تكوين نشط-نشط مع عدة عقد خلفية. أثناء الصيانة المخطط لها، يضمن استنزاف الاتصال تحديثات رشيقة. بالنسبة لحالات الفشل غير المخطط لها، تحل عقدة جديدة محل العقدة الفاشلة، وعادة ما تتم استعادة الاتصال في غضون 10 ثوان.

هل هناك حد للأحرف المخصصة لاسم جدار حماية؟

نعم، تقتصر أسماء جدار الحماية على 50 حرفا.

لماذا يحتاج Azure Firewall إلى حجم شبكة فرعية /26؟

تضمن شبكة /26 الفرعية عناوين IP كافية للتكبير حيث يوفر Azure Firewall المزيد من نسخ الآلة الافتراضية.

هل يحتاج حجم الشبكة الفرعية لجدار الحماية إلى تغيير كحجم الخدمة؟

لا، الشبكة الفرعية /26 كافية لجميع سيناريوهات التحجيم.

كيف يمكنني زيادة معدل نقل جدار الحماية؟

Azure Firewall يتدرج تلقائيا بناء على استخدام وحدة المعالجة المركزية، ومعدل النقل، وعدد الاتصالات. تتراوح سعة معدل النقل من 2.5 إلى 3 جيجابت في الثانية في البداية إلى 30 جيجابت في الثانية (SKU قياسي) أو 100 جيجابت في الثانية (Premium SKU).

هل هناك حدود لعدد عناوين IP المعتمدة من قبل مجموعات IP؟

نعم. للتفاصيل، انظر Azure حدود الاشتراك والخدمات، الحصص، والقيود.

هل يمكنني نقل مجموعة IP إلى مجموعة موارد أخرى؟

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

ما هو وقت TCP Idle Timeout ل Azure Firewall؟

السلوك القياسي لجدار حماية شبكة الاتصال هو التأكد من استمرار نشاط اتصالات TCP وإغلاقها على الفور إذا لم يكن هناك أي نشاط. Azure Firewall TCP Idle Timeout هو أربع دقائق. هذا الإعداد غير قابل للتخصيص من قبل المستخدم، لكن يمكنك التواصل مع دعم Azure لزيادة مهلة الخمول للاتصالات الواردة والصادرة حتى 15 دقيقة. لا يمكن تغيير مهلة الخمول لنسبة استخدام الشبكة بين الشرق والغرب.

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

هل يمكنني نشر Azure Firewall بدون عنوان IP عام؟

نعم، ولكن يجب تكوين جدار الحماية في وضع الاتصال النفقي القسري. هذا التكوين ينشئ واجهة إدارة بعنوان IP عام يستخدمه Azure Firewall لعملياته. يعتبر عنوان IP العام هذا لإدارة نسبة استخدام الشبكة. يستخدم حصريا من قبل منصة Azure ولا يمكن استخدامه لأي غرض آخر. يمكن تكوين شبكة مسار بيانات المستأجر دون عنوان IP عام، ويمكن فرض نقل بيانات الإنترنت نفقيا إلى جدار حماية آخر أو حظرها تماما.

هل هناك طريقة لعمل نسخة احتياطية تلقائيا من Azure Firewall والسياسات؟

نعم. لمزيد من المعلومات، راجع نسخة احتياطية Azure Firewall وسياسة Azure Firewall مع تطبيقات منطقية.

الاتصال والتوجيه

كيف يمكنني إعداد Azure Firewall مع نقاط نهاية الخدمة الخاصة بي؟

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

هل يمكن ل Azure Firewall في مركز إعادة توجيه وتصفية حركة المرور الافتراضية بين عدة شبكات افتراضية متنوعة؟

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

هل يمكن ل Azure Firewall توجيه وتصفية حركة المرور الشبكية بين الشبكات الفرعية في نفس الشبكة الافتراضية أو الشبكات الافتراضية المترابطة؟

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

هل يقوم Azure Firewall بتطبيق SNAT الصادر بين الشبكات الخاصة؟

لا Azure Firewall يحدث SNAT عندما يكون عنوان IP الوجهة هو نطاق IP خاص حسب IANA RFC 1918 أو IANA RFC 6598 للشبكات الخاصة. إذا كانت مؤسستك تستخدم نطاق عناوين IP عام للشبكات الخاصة، فإن Azure Firewall يقوم بإرسال حركة المرور إلى أحد عناوين IP الخاصة بجدار الحماية في AzureFirewallSubnet. يمكنك تكوين Azure Firewall ليكون not SNAT في نطاق عنوان IP العام الخاص بك. لمزيد من المعلومات، راجع Azure Firewall نطاقات عناوين IP الخاصة SNAT.

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

هل التوجيه/التسلسل القسري لجهاز ظاهري للشبكة مدعوم؟

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

يجب أن يكون Azure Firewall متصلة مباشرة بالإنترنت. إذا تعلم AzureFirewallSubnet مساراً افتراضياً لشبكة الاتصال المحلية عبر BGP، فيجب تجاوز هذا باستخدام 0.0.0.0/0 UDR مع تعيين قيمة NextHopTypeInternet للحفاظ على اتصال إنترنت مباشر.

إذا تطلب التكوين الخاص بك توجيهًا قسريًّا إلى شبكة محلية ويمكنك تحديد بادئات IP الهدف لوجهات إنترنت الخاصة بك، يمكنك تكوين هذه النطاقات مع شبكة الاتصال المحلية كالقفزة التالية عبر توجيه محدد من قبل مستخدم على AzureFirewallSubnet. أو يمكنك استخدام BGP لتعريف هذه التوجيهات.

كيف تعمل أحرف البدل في عناوين URL المستهدفة وتستهدف FQDNs في قواعد التطبيق؟

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

أمثلة:

نوع	‏‏قاعدة	مدعوم؟	أمثلة إيجابية
TargetURL	www.contoso.com	‏‏نعم‬	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	‏‏نعم‬	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	‏‏نعم‬	example.anycontoso.com sub1.example.contoso.com contoso.com تحذير: هذا الاستخدام للوايلدكارد يسمح أيضا بتغييرات غير مرغوبة أو محفوفة بالمخاطر مثل th3re4lcontoso.com - الاستخدام بحذر.
TargetURL	www.contoso.com/test	‏‏نعم‬	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	‏‏نعم‬	www.contoso.com/test/anything ملاحظة: www.contoso.com/testلا تتطابق (آخر ضربة)
TargetURL	www.contoso.*/test/*	لا
TargetURL	www.contoso.com/test?example=1	لا
TargetURL	www.contoso.*	لا
TargetURL	www.*contoso.com	لا
TargetURL	www.contoso.com:8080	لا
TargetURL	*.contoso.*	لا
TargetFQDN	www.contoso.com	‏‏نعم‬	www.contoso.com
TargetFQDN	*.contoso.com	‏‏نعم‬	any.contoso.com ملاحظة: إذا كنت تريد السماح contoso.comبشكل محدد، يجب أن تدرج contoso.com في القاعدة. وإلا، يتم إسقاط الاتصال بشكل افتراضي لأن الطلب لا يتطابق مع أي قاعدة.
TargetFQDN	*contoso.com	‏‏نعم‬	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	لا
TargetFQDN	*.contoso.*	لا

هل يسمح Azure Firewall بالوصول إلى Active Directory بشكل افتراضي؟

‏‏لا. Azure Firewall يمنع الوصول إلى Active Directory بشكل افتراضي. للسماح بالوصول، قم بتكوين علامة خدمة AzureActiveDirectory. لمزيد من المعلومات، راجع Azure Firewall وسوم الخدمة.

هل يمكنني استبعاد FQDN أو عنوان IP من تصفية Azure Firewall Threat Intelligence؟

نعم، يمكنك استخدام Azure PowerShell للقيام بذلك:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

لماذا يمكن لنظام TCP ping وأدوات مشابهة الاتصال بنجاح بشبكة FQDN مستهدفة حتى عندما لا تسمح أي قاعدة على Azure Firewall بهذه الحركة؟

اختبار اتصال TCP لا يؤدي بالفعل إلى الاتصال بـ FQDN الهدف. Azure Firewall لا يسمح بالاتصال بأي عنوان IP مستهدف/FQDN إلا إذا كان هناك قاعدة صريحة تسمح بذلك.

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

لماذا تتصل أدوات TCP ping وأدوات مشابهة بنجاح إلى عنوان FQDN/IP المستهدف على المنافذ 80 و443 و1433 لكنها لا تلاحظ في سجلات Azure Firewall؟

يعمل Azure Firewall كمستمع سلبي للمنافذ 80 و443 و1433. Azure Firewall لا يسجل حزم TCP SYN على هذه المنافذ إلا إذا كان هناك حركة مرور تطبيقات. طلب HTTP GET وTLS client Hello مسجلان في Azure Firewall.

هل هناك حدود لعدد عناوين IP المعتمدة من قبل مجموعات IP؟

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

هل يمكنني نقل مجموعة IP إلى مجموعة موارد أخرى؟

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

ما هو وقت TCP Idle Timeout ل Azure Firewall؟

السلوك القياسي لجدار حماية شبكة الاتصال هو التأكد من استمرار نشاط اتصالات TCP وإغلاقها على الفور إذا لم يكن هناك أي نشاط. Azure Firewall TCP Idle Timeout هو أربع دقائق. هذا الإعداد غير قابل للتخصيص من قبل المستخدم، لكن يمكنك التواصل مع دعم Azure لزيادة مهلة الخمول للاتصالات الواردة والصادرة حتى 15 دقيقة. لا يمكن تغيير مهلة الخمول لنسبة استخدام الشبكة بين الشرق والغرب.

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

هل يمكنني نشر Azure Firewall بدون عنوان IP عام؟

نعم، ولكن يجب تكوين جدار الحماية في وضع الاتصال النفقي القسري. هذا التكوين ينشئ واجهة إدارة بعنوان IP عام يستخدمه Azure Firewall لعملياته. يعتبر عنوان IP العام هذا لإدارة نسبة استخدام الشبكة. يستخدم حصريا من قبل منصة Azure ولا يمكن استخدامه لأي غرض آخر. يمكن تكوين شبكة مسار بيانات المستأجر دون عنوان IP عام، ويمكن فرض نقل بيانات الإنترنت نفقيا إلى جدار حماية آخر أو حظرها تماما.

أين يخزن Azure Firewall بيانات العملاء؟

Azure Firewall لا ينقل أو يخزن بيانات العملاء خارج المنطقة التي تم نشرها فيها.

هل هناك طريقة لعمل نسخة احتياطية تلقائيا من Azure Firewall والسياسات؟

نعم. لمزيد من المعلومات، راجع نسخة احتياطية Azure Firewall وسياسة Azure Firewall مع تطبيقات منطقية.

هل يدعم Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) في قطر؟

لا، حاليا Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) غير مدعوم في قطر.

كم عدد الاتصالات المتوازية التي يمكن أن يدعمها Azure Firewall؟

Azure Firewall يستخدم Azure Virtual Machines تحتها تحتوي على حد hard-limit لعدد الاتصالات. العدد الإجمالي للاتصالات النشطة لكل جهاز ظاهري هو 250 ألف.

الحد الإجمالي لكل جدار حماية هو حد اتصال الجهاز الظاهري (250 ألف) × عدد الأجهزة الظاهرية في تجمع الواجهة الخلفية لجدار الحماية. يبدأ Azure Firewall بجهازين افتراضيين ويتوسع حسب استخدام وحدة المعالجة المركزية ومعدل الإنتاجية.

ما هو سلوك إعادة استخدام منفذ SNAT TCP/UDP في Azure Firewall؟

يستخدم Azure Firewall حاليا منافذ المصدر TCP/UDP لحركة المرور الخارجة من SNAT، دون وقت انتظار خمول. عند إغلاق اتصال TCP/UDP، ينظر إلى منفذ TCP المستخدم على الفور على أنه متاح للاتصالات القادمة.

كحل بديل لبعض البنى، يمكنك النشر والتوسع باستخدام NAT Gateway مع Azure Firewall لتوفير مجموعة أوسع من منافذ SNAT للتنوع والتوافر.

كيف أحل مشكلة استنزاف منافذ SNAT؟

لديك خياران. أضف عدة عناوين IP عامة إلى جدار الحماية الخاص بك لحل أقل تكلفة، أو استخدم بوابة Azure NAT لحل أكثر قابلية للتوسع والمتانة. للمقارنة بين الخيارين، راجع أفضل الممارسات لأداء Azure Firewall.

ما هي سلوكيات NAT في Azure Firewall؟

تعتمد سلوكيات NAT المحددة على تكوين جدار الحماية ونوع NAT الذي تم تكوينه. على سبيل المثال، يحتوي جدار الحماية على قواعد DNAT لنسبة استخدام الشبكة الواردة وقواعد الشبكة وقواعد التطبيق لحركة المرور الصادرة من خلال جدار الحماية.

لمزيد من المعلومات، راجع Azure Firewall سلوكيات NAT .

المهلات والتحجيم

كيف يعمل استنزاف الاتصال؟

لأي عملية صيانة المخطط لها، يقوم منطق استنزاف الاتصال بتحديث العقد الخلفية بأمان. ينتظر Azure Firewall 90 ثانية حتى تغلق الاتصالات الموجودة. في أول 45 ثانية، لا تقبل عقدة الخلفية الاتصالات الجديدة، وفي الوقت المتبقي تستجيب لجميع RST الحزم الواردة. إذا لزم الأمر، يمكن للعملاء تلقائيًّا إعادة تأسيس الاتصال إلى عقدة خلفية أخرى.

كيف يتعامل Azure Firewall مع إيقاف تشغيل نسخ الأجهزة الافتراضية أثناء توسع مجموعة مقياس الآلة الافتراضية (تصغير التطوير) أو ترقيات برامج الأسطول؟

قد يحدث إيقاف تشغيل نسخة Azure Firewall VM أثناء تكبير مجموعة مقياس الآلة الافتراضية (تصغير) أو أثناء ترقية برمجيات الأسطول. في هذه الحالات، يتم تحميل الاتصالات الواردة الجديدة متوازنة إلى مثيلات جدار الحماية المتبقية ولا تتم إعادة توجيهها إلى مثيل جدار الحماية لأسفل. بعد 45 ثانية، يبدأ جدار الحماية في رفض الاتصالات الموجودة عن طريق إرسال حزم TCP RST. بعد 45 ثانية أخرى يتم إيقاف تشغيل جدار الحماية VM. لمزيد من المعلومات، راجع Load Balancer إعادة تعيين TCP ومهلة الخمول.

كم يستغرق الأمر حتى يتطور Azure Firewall؟

Azure Firewall يتدرج تدريجيا عندما يكون متوسط معدل النقل أو استهلاك المعالج عند 60%، أو عند استخدام عدد الاتصالات عند 80%. على سبيل المثال، يبدأ في التوسع عندما يصل إلى 60٪ من الحد الأقصى لمعدل النقل الخاص به. تختلف أرقام الحد الأقصى لمعدل النقل بناء على وحدة تعريف Azure Firewall والميزات المفعلة. لمزيد من المعلومات، راجع Azure Firewall performance.

يستغرق التوسع من خمس إلى سبع دقائق. عند اختبار الأداء، تأكد من الاختبار لمدة لا تقل عن 10 إلى 15 دقيقة، وابدأ اتصالات جديدة للاستفادة من عقد Azure Firewall التي تم إنشاؤها حديثا.

كيف يتعامل Azure Firewall مع مهلات الخمول؟

عندما يحصل الاتصال على مهلة توقف (أربع دقائق بدون نشاط)، يقوم Azure Firewall بإنهاء الاتصال برشاقة عن طريق إرسال حزمة RST من TCP.

الصيانة التي يتحكم فيها العميل

ما نوع الصيانة التي يدعمها العملاء؟

تخضع خدمات Azure لتحديثات صيانة منتظمة لتعزيز الوظائف والموثوقية والأداء والأمان. مع فترة صيانة مكونة، يتم إجراء صيانة نظام التشغيل الضيف وصيانة الخدمة أثناء تلك النافذة. ومع ذلك، لا تتضمن الصيانة التي يتحكم فيها العميل تحديثات المضيف أو تحديثات الأمان الهامة.

هل يمكنني الحصول على إعلام متقدم بحدث الصيانة؟

الإشعارات المتقدمة لصيانة Azure Firewall غير متوفرة.

هل يمكنني تكوين نافذة صيانة أقصر من خمس ساعات؟

لا، مطلوب نافذة صيانة مدتها خمس ساعات كحد أدنى.

هل يمكنني تكوين نافذة صيانة غير الجدول الزمني اليومي؟

لا، يتم حاليا تكوين نوافذ الصيانة للتكتم يوميا.

هل هناك حالات لا يمكنني فيها التحكم في تحديثات معينة؟

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

هل يجب أن تكون موارد تكوين الصيانة في نفس المنطقة التي تكون فيها Azure Firewall؟

نعم.

هل يمكننا إنشاء أكثر من تكوين صيانة واحد لجهاز Azure Firewall واحد؟

‏‏لا. حاليا، يمكن ربط تكوين صيانة واحد فقط بجدار Azure Firewall.

أي وحدات تخزين Azure Firewall يمكنني إعدادها لاستخدام الصيانة التي يتحكم بها العميل؟

جميع وحدات Azure Firewall - الأساسية، القياسية، والمميزة تدعم الصيانة التي يتحكم بها العملاء.

كم من الوقت يستغرق سياسة إعداد الصيانة لتصبح فعالة بعد تعيينها على Azure Firewall؟

قد يستغرق الأمر حتى 24 ساعة حتى يتبع Azure Firewall جدول الصيانة بعد ربط سياسة الصيانة.

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

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

كيف يمكنني معرفة المزيد عن الصيانة التي يتحكم بها العملاء على Azure Firewall؟

لمزيد من المعلومات، راجع إعداد الصيانة التي يتحكم بها العميل.

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

للحصول على قائمة مفصلة بالميزات Azure Firewall، راجع Azure Firewall features.

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

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

يمكن نشر Azure Firewall باستخدام بوابة Azure أو PowerShell أو واجهة برمجة تطبيقات REST أو القوالب. للحصول على تعليمات خطوة بخطوة، راجع Tutorial: نشر وتكوين Azure Firewall باستخدام Azure portal.

يستخدم Azure Firewall القواعد ومجموعات القواعد. مجموعة القواعد هي مجموعة من القواعد بنفس الترتيب والأولوية. يتم تنفيذ مجموعات القواعد بترتيب الأولوية. تتمتع مجموعات قواعد DNAT بأولوية أعلى من مجموعات قواعد الشبكة، والتي بدورها لها أولوية أعلى من مجموعات قواعد التطبيق. يتم إنهاء جميع القواعد.

هناك ثلاثة أنواع من مجموعات القواعد:

• قواعد التطبيق: تكوين أسماء النطاقات المؤهلة بالكامل (FQDNs) التي يمكن الوصول إليها من شبكة افتراضية.
• قواعد الشبكة: تكوين القواعد باستخدام عناوين المصدر، والبروتوكولات، ومنافذ الوجهة، وعناوين الوجهة.
• قواعد NAT: قم بتكوين قواعد DNAT للسماح باتصالات الإنترنت أو الإنترانت الواردة (المعاينة).

لمزيد من المعلومات، راجع تكوين قواعد Azure Firewall.

Azure Firewall يتكامل مع Azure Monitor لعرض وتحليل السجلات. يمكن إرسال السجلات إلى Log Analytics أو تخزين Azure أو Event Hubs وتحليلها باستخدام أدوات مثل Log Analytics أو Excel أو Power BI. لمزيد من المعلومات، راجع Tutorial: مراقبة سجلات Azure Firewall.

Azure Firewall هو خدمة أمن شبكات مدارة قائمة على السحابة تحمي موارد الشبكة الافتراضية. تتسم هذه الخدمة بأنها جدار حماية ذي حالة خاصة بالكامل ذي قابلية وصول عالية مضمنة وقابلية توسع سحابة غير مقيدة. يتم إعداده مسبقا مع موفري الأمان كخدمة (SECaaS) التابعين لجهة خارجية لتحسين الأمان للشبكة الظاهرية واتصالات الإنترنت الفرعية. لمزيد من المعلومات، راجع Azure أمن الشبكات.

يوفر Application Gateway WAF حماية واردة مركزية لتطبيقات الويب ضد الاستغلالات والثغرات الأمنية الشائعة. يوفر Azure Firewall حماية واردة للبروتوكولات غير التابعة ل HTTP/S (مثل RDP وSSH وFTP)، وحماية على مستوى الشبكة الصادرة لجميع المنافذ والبروتوكولات، وحماية على مستوى التطبيق لبروتوكولات HTTP/S الصادرة.

يكمل Azure Firewall عناصر NSG لتوفير أمان شبكة "دفاعي معمق" أفضل. تقدم مجموعات أمان الشبكة تصفية حركة مرور طبقة الشبكة الموزعة للحد من نسبة استخدام الشبكة داخل الشبكات الظاهرية في كل اشتراك. يوفر Azure Firewall حماية مركزية وكاملة الحالة على مستوى الشبكة والتطبيق عبر الاشتراكات والشبكات الافتراضية.

Azure Firewall هو خدمة مدارة مع طبقات حماية متعددة، بما في ذلك حماية المنصة باستخدام NSGs على مستوى شبكة الشبكة (غير قابلة للعرض). NSGs على مستوى الشبكة الفرعية غير مطلوبة على AzureFirewallSubnet ويتم تعطيلها لمنع انقطاع الخدمة.

النقاط النهائية الخاصة هي مكون من تقنية Private Link، وهي تقنية تتيح التفاعل مع خدمات Azure PaaS باستخدام عناوين IP الخاصة بدلا من العناوين العامة. يمكن استخدام Azure Firewall لمنع الوصول إلى عناوين IP العامة، وبالتالي تجنب تسريب البيانات إلى خدمات Azure التي لا تستخدم Private Link، وكذلك لتنفيذ سياسات الثقة الصفرية من خلال تحديد من في مؤسستك يحتاج للوصول إلى خدمات Azure PaaS تلك، منذ Private Link بشكل افتراضي يفتح الوصول إلى الشبكة لشبكة الشركة بأكملها.

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

نقاط نهاية خدمة Virtual Network هي بديل ل Private Link للتحكم في الوصول إلى الشبكة إلى خدمات Azure PaaS. حتى إذا كان العميل لا يزال يستخدم عناوين IP العامة للوصول إلى خدمة PaaS، يتم جعل الشبكة الفرعية المصدر مرئية بحيث يمكن لخدمة PaaS الوجهة تنفيذ قواعد التصفية وتقييد الوصول على أساس كل شبكة فرعية. يمكنك العثور على مقارنة مفصلة بين الآليين في مقارنة نقاط النهاية الخاصة ونقاط نهاية الخدمة.

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

لتفاصيل الأسعار، راجع Azure Firewall السعر.

لحدود الخدمة، انظر Azure حدود الاشتراك والخدمات، الحصص، والقيود.

Azure Firewall لا ينقل أو يخزن بيانات العملاء خارج المنطقة التي تم نشرها فيها.

لا، Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) غير مدعوم حاليا في قطر.

نعم، يدعم Azure Firewall كل من تصفية الحركة الواردة والصادرة. عادة ما تستخدم التصفية الواردة للبروتوكولات غير HTTP مثل RDP وSSH وFTP. بالنسبة لحركة مرور HTTP وHTTPS الواردة، فكر في استخدام جدار حماية تطبيقات ويب مثل Azure Web Application Firewall (WAF) أو ميزات تفريغ TLS وفحص الحزم العميق في Azure Firewall Premium.

نعم، Azure Firewall Basic يدعم النفق القسري.

لا يتصل اختبار اتصال TCP فعليا ب FQDN الهدف. Azure Firewall يمنع الاتصالات بأي عنوان IP مستهدف أو FQDN ما لم يسمح بذلك صراحة قاعدة معينة.

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

لا، Azure Firewall لا يدعم بشكل أصلي الارتباط ب BGP. ومع ذلك، فإن ميزة طرق SNAT للتعلم التلقائي تستخدم بشكل غير مباشر BGP عبر Azure Route Server.

Azure Firewall لا يدعم ESP (تغليف حمولة الأمان)، لكن يمكنك السماح بحركة ESP عن طريق تكوين قاعدة شبكة كما يلي:

تكوين Azure Firewall (قاعدة الشبكة):

• البروتوكول: أي
• المصدر المنفذي: * (أي إصدار)
• منفذ الوجهة: * (أي منفذ)
• المصدر/الوجهة: حدد عناوين IP حسب الحاجة

يسمح هذا التكوين لحزم ESP (رقم بروتوكول IP 50) وحركة المرور غير TCP/UDP الأخرى بمطابقة القاعدة. ومع ذلك، لاحظ أن Azure Firewall لا يفحص حمولات ESP الخاصة ب ESP.

مرجع: إذا استخدمت مجموعة أمن الشبكة (NSG) بدلا من Azure Firewall: لا توفر NSG خيارا مباشرا لتحديد بروتوكول ESP (رقم بروتوكول IP 50)، لكن يمكن السماح بحزم ESP باستخدام الإعدادات التالية:

• البروتوكول: أي
• النقل: * (أي إصدار)
• المصدر/الوجهة: حدد عناوين IP حسب الحاجة

التوصيات

• بالنسبة لإعدادات IPsec VPN، ينصح باستخدام Azure VPN Gateway.
• فكر في استخدام نمط NVA (جهاز افتراضي شبكي) حسب متطلباتك.

يمكنك استخدام Azure PowerShell لتخصيص وتوزيع Azure Firewall. تختلف العملية اعتمادا على التكوين.

بالنسبة لجدار حماية بدون بطاقة تحكم إدارية:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

بالنسبة لجدار حماية مع بطاقة شبكة إدارة:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

بالنسبة لجدار حماية في مركز افتراضي آمن:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

إشعار

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

يوصى بتكوين مناطق التوفر أثناء النشر الأولي. ومع ذلك، يمكنك إعادة تكوينها بعد التوزيع إذا:

• يتم نشر جدار الحماية في شبكة ظاهرية (غير مدعوم في المراكز الظاهرية الآمنة).
• تدعم المنطقة مناطق التوفر.
• يتم تكوين جميع عناوين IP العامة المرفقة بنفس المناطق.

لإعادة تكوين مناطق التوفر:

1. إلغاء تخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. تحديث تكوين المنطقة وتخصيص جدار الحماية:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

نعم:

• يجب أن يكون Azure Firewall والشبكة الافتراضية في نفس مجموعة الموارد.
• يمكن أن يكون عنوان IP العام في مجموعة موارد مختلفة.
• يجب أن تكون جميع الموارد (جدار الحماية Azure، الشبكة الافتراضية، عنوان IP العام) ضمن نفس الاشتراك.

حالة فشل التوفير تشير إلى فشل تحديث التكوين في حالة واحدة أو أكثر من مثيلات الخلفية. يبقى Azure Firewall يعمل، لكن التكوين قد يكون غير متسق. أعد محاولة التحديث حتى تتغير حالة التوفير إلى ناجح.

يستخدم Azure Firewall تكوين نشط-نشط مع عدة عقد خلفية. أثناء الصيانة المخطط لها، يضمن استنزاف الاتصال تحديثات رشيقة. بالنسبة لحالات الفشل غير المخطط لها، تحل عقدة جديدة محل العقدة الفاشلة، وعادة ما تتم استعادة الاتصال في غضون 10 ثوان.

نعم، تقتصر أسماء جدار الحماية على 50 حرفا.

تضمن شبكة /26 الفرعية عناوين IP كافية للتكبير حيث يوفر Azure Firewall المزيد من نسخ الآلة الافتراضية.

لا، الشبكة الفرعية /26 كافية لجميع سيناريوهات التحجيم.

Azure Firewall يتدرج تلقائيا بناء على استخدام وحدة المعالجة المركزية، ومعدل النقل، وعدد الاتصالات. تتراوح سعة معدل النقل من 2.5 إلى 3 جيجابت في الثانية في البداية إلى 30 جيجابت في الثانية (SKU قياسي) أو 100 جيجابت في الثانية (Premium SKU).

نعم. للتفاصيل، انظر Azure حدود الاشتراك والخدمات، الحصص، والقيود.

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

السلوك القياسي لجدار حماية شبكة الاتصال هو التأكد من استمرار نشاط اتصالات TCP وإغلاقها على الفور إذا لم يكن هناك أي نشاط. Azure Firewall TCP Idle Timeout هو أربع دقائق. هذا الإعداد غير قابل للتخصيص من قبل المستخدم، لكن يمكنك التواصل مع دعم Azure لزيادة مهلة الخمول للاتصالات الواردة والصادرة حتى 15 دقيقة. لا يمكن تغيير مهلة الخمول لنسبة استخدام الشبكة بين الشرق والغرب.

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

نعم، ولكن يجب تكوين جدار الحماية في وضع الاتصال النفقي القسري. هذا التكوين ينشئ واجهة إدارة بعنوان IP عام يستخدمه Azure Firewall لعملياته. يعتبر عنوان IP العام هذا لإدارة نسبة استخدام الشبكة. يستخدم حصريا من قبل منصة Azure ولا يمكن استخدامه لأي غرض آخر. يمكن تكوين شبكة مسار بيانات المستأجر دون عنوان IP عام، ويمكن فرض نقل بيانات الإنترنت نفقيا إلى جدار حماية آخر أو حظرها تماما.

نعم. لمزيد من المعلومات، راجع نسخة احتياطية Azure Firewall وسياسة Azure Firewall مع تطبيقات منطقية.

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

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

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

لا Azure Firewall يحدث SNAT عندما يكون عنوان IP الوجهة هو نطاق IP خاص حسب IANA RFC 1918 أو IANA RFC 6598 للشبكات الخاصة. إذا كانت مؤسستك تستخدم نطاق عناوين IP عام للشبكات الخاصة، فإن Azure Firewall يقوم بإرسال حركة المرور إلى أحد عناوين IP الخاصة بجدار الحماية في AzureFirewallSubnet. يمكنك تكوين Azure Firewall ليكون not SNAT في نطاق عنوان IP العام الخاص بك. لمزيد من المعلومات، راجع Azure Firewall نطاقات عناوين IP الخاصة SNAT.

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

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

يجب أن يكون Azure Firewall متصلة مباشرة بالإنترنت. إذا تعلم AzureFirewallSubnet مساراً افتراضياً لشبكة الاتصال المحلية عبر BGP، فيجب تجاوز هذا باستخدام 0.0.0.0/0 UDR مع تعيين قيمة NextHopTypeInternet للحفاظ على اتصال إنترنت مباشر.

إذا تطلب التكوين الخاص بك توجيهًا قسريًّا إلى شبكة محلية ويمكنك تحديد بادئات IP الهدف لوجهات إنترنت الخاصة بك، يمكنك تكوين هذه النطاقات مع شبكة الاتصال المحلية كالقفزة التالية عبر توجيه محدد من قبل مستخدم على AzureFirewallSubnet. أو يمكنك استخدام BGP لتعريف هذه التوجيهات.

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

أمثلة:

نوع	‏‏قاعدة	مدعوم؟	أمثلة إيجابية
TargetURL	www.contoso.com	‏‏نعم‬	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	‏‏نعم‬	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	‏‏نعم‬	example.anycontoso.com sub1.example.contoso.com contoso.com تحذير: هذا الاستخدام للوايلدكارد يسمح أيضا بتغييرات غير مرغوبة أو محفوفة بالمخاطر مثل th3re4lcontoso.com - الاستخدام بحذر.
TargetURL	www.contoso.com/test	‏‏نعم‬	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	‏‏نعم‬	www.contoso.com/test/anything ملاحظة: www.contoso.com/testلا تتطابق (آخر ضربة)
TargetURL	www.contoso.*/test/*	لا
TargetURL	www.contoso.com/test?example=1	لا
TargetURL	www.contoso.*	لا
TargetURL	www.*contoso.com	لا
TargetURL	www.contoso.com:8080	لا
TargetURL	*.contoso.*	لا
TargetFQDN	www.contoso.com	‏‏نعم‬	www.contoso.com
TargetFQDN	*.contoso.com	‏‏نعم‬	any.contoso.com ملاحظة: إذا كنت تريد السماح contoso.comبشكل محدد، يجب أن تدرج contoso.com في القاعدة. وإلا، يتم إسقاط الاتصال بشكل افتراضي لأن الطلب لا يتطابق مع أي قاعدة.
TargetFQDN	*contoso.com	‏‏نعم‬	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	لا
TargetFQDN	*.contoso.*	لا

‏‏لا. Azure Firewall يمنع الوصول إلى Active Directory بشكل افتراضي. للسماح بالوصول، قم بتكوين علامة خدمة AzureActiveDirectory. لمزيد من المعلومات، راجع Azure Firewall وسوم الخدمة.

نعم، يمكنك استخدام Azure PowerShell للقيام بذلك:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

اختبار اتصال TCP لا يؤدي بالفعل إلى الاتصال بـ FQDN الهدف. Azure Firewall لا يسمح بالاتصال بأي عنوان IP مستهدف/FQDN إلا إذا كان هناك قاعدة صريحة تسمح بذلك.

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

يعمل Azure Firewall كمستمع سلبي للمنافذ 80 و443 و1433. Azure Firewall لا يسجل حزم TCP SYN على هذه المنافذ إلا إذا كان هناك حركة مرور تطبيقات. طلب HTTP GET وTLS client Hello مسجلان في Azure Firewall.

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

لا، نقل مجموعة IP إلى مجموعة موارد أخرى غير معتمد حاليًّا.

السلوك القياسي لجدار حماية شبكة الاتصال هو التأكد من استمرار نشاط اتصالات TCP وإغلاقها على الفور إذا لم يكن هناك أي نشاط. Azure Firewall TCP Idle Timeout هو أربع دقائق. هذا الإعداد غير قابل للتخصيص من قبل المستخدم، لكن يمكنك التواصل مع دعم Azure لزيادة مهلة الخمول للاتصالات الواردة والصادرة حتى 15 دقيقة. لا يمكن تغيير مهلة الخمول لنسبة استخدام الشبكة بين الشرق والغرب.

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

نعم، ولكن يجب تكوين جدار الحماية في وضع الاتصال النفقي القسري. هذا التكوين ينشئ واجهة إدارة بعنوان IP عام يستخدمه Azure Firewall لعملياته. يعتبر عنوان IP العام هذا لإدارة نسبة استخدام الشبكة. يستخدم حصريا من قبل منصة Azure ولا يمكن استخدامه لأي غرض آخر. يمكن تكوين شبكة مسار بيانات المستأجر دون عنوان IP عام، ويمكن فرض نقل بيانات الإنترنت نفقيا إلى جدار حماية آخر أو حظرها تماما.

Azure Firewall لا ينقل أو يخزن بيانات العملاء خارج المنطقة التي تم نشرها فيها.

نعم. لمزيد من المعلومات، راجع نسخة احتياطية Azure Firewall وسياسة Azure Firewall مع تطبيقات منطقية.

لا، حاليا Azure Firewall في المراكز الافتراضية المؤمنة (vWAN) غير مدعوم في قطر.

Azure Firewall يستخدم Azure Virtual Machines تحتها تحتوي على حد hard-limit لعدد الاتصالات. العدد الإجمالي للاتصالات النشطة لكل جهاز ظاهري هو 250 ألف.

الحد الإجمالي لكل جدار حماية هو حد اتصال الجهاز الظاهري (250 ألف) × عدد الأجهزة الظاهرية في تجمع الواجهة الخلفية لجدار الحماية. يبدأ Azure Firewall بجهازين افتراضيين ويتوسع حسب استخدام وحدة المعالجة المركزية ومعدل الإنتاجية.

يستخدم Azure Firewall حاليا منافذ المصدر TCP/UDP لحركة المرور الخارجة من SNAT، دون وقت انتظار خمول. عند إغلاق اتصال TCP/UDP، ينظر إلى منفذ TCP المستخدم على الفور على أنه متاح للاتصالات القادمة.

كحل بديل لبعض البنى، يمكنك النشر والتوسع باستخدام NAT Gateway مع Azure Firewall لتوفير مجموعة أوسع من منافذ SNAT للتنوع والتوافر.

لديك خياران. أضف عدة عناوين IP عامة إلى جدار الحماية الخاص بك لحل أقل تكلفة، أو استخدم بوابة Azure NAT لحل أكثر قابلية للتوسع والمتانة. للمقارنة بين الخيارين، راجع أفضل الممارسات لأداء Azure Firewall.

تعتمد سلوكيات NAT المحددة على تكوين جدار الحماية ونوع NAT الذي تم تكوينه. على سبيل المثال، يحتوي جدار الحماية على قواعد DNAT لنسبة استخدام الشبكة الواردة وقواعد الشبكة وقواعد التطبيق لحركة المرور الصادرة من خلال جدار الحماية.

لمزيد من المعلومات، راجع Azure Firewall سلوكيات NAT .

لأي عملية صيانة المخطط لها، يقوم منطق استنزاف الاتصال بتحديث العقد الخلفية بأمان. ينتظر Azure Firewall 90 ثانية حتى تغلق الاتصالات الموجودة. في أول 45 ثانية، لا تقبل عقدة الخلفية الاتصالات الجديدة، وفي الوقت المتبقي تستجيب لجميع RST الحزم الواردة. إذا لزم الأمر، يمكن للعملاء تلقائيًّا إعادة تأسيس الاتصال إلى عقدة خلفية أخرى.

قد يحدث إيقاف تشغيل نسخة Azure Firewall VM أثناء تكبير مجموعة مقياس الآلة الافتراضية (تصغير) أو أثناء ترقية برمجيات الأسطول. في هذه الحالات، يتم تحميل الاتصالات الواردة الجديدة متوازنة إلى مثيلات جدار الحماية المتبقية ولا تتم إعادة توجيهها إلى مثيل جدار الحماية لأسفل. بعد 45 ثانية، يبدأ جدار الحماية في رفض الاتصالات الموجودة عن طريق إرسال حزم TCP RST. بعد 45 ثانية أخرى يتم إيقاف تشغيل جدار الحماية VM. لمزيد من المعلومات، راجع Load Balancer إعادة تعيين TCP ومهلة الخمول.

Azure Firewall يتدرج تدريجيا عندما يكون متوسط معدل النقل أو استهلاك المعالج عند 60%، أو عند استخدام عدد الاتصالات عند 80%. على سبيل المثال، يبدأ في التوسع عندما يصل إلى 60٪ من الحد الأقصى لمعدل النقل الخاص به. تختلف أرقام الحد الأقصى لمعدل النقل بناء على وحدة تعريف Azure Firewall والميزات المفعلة. لمزيد من المعلومات، راجع Azure Firewall performance.

يستغرق التوسع من خمس إلى سبع دقائق. عند اختبار الأداء، تأكد من الاختبار لمدة لا تقل عن 10 إلى 15 دقيقة، وابدأ اتصالات جديدة للاستفادة من عقد Azure Firewall التي تم إنشاؤها حديثا.

عندما يحصل الاتصال على مهلة توقف (أربع دقائق بدون نشاط)، يقوم Azure Firewall بإنهاء الاتصال برشاقة عن طريق إرسال حزمة RST من TCP.

تخضع خدمات Azure لتحديثات صيانة منتظمة لتعزيز الوظائف والموثوقية والأداء والأمان. مع فترة صيانة مكونة، يتم إجراء صيانة نظام التشغيل الضيف وصيانة الخدمة أثناء تلك النافذة. ومع ذلك، لا تتضمن الصيانة التي يتحكم فيها العميل تحديثات المضيف أو تحديثات الأمان الهامة.

الإشعارات المتقدمة لصيانة Azure Firewall غير متوفرة.

لا، مطلوب نافذة صيانة مدتها خمس ساعات كحد أدنى.

لا، يتم حاليا تكوين نوافذ الصيانة للتكتم يوميا.

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

نعم.

‏‏لا. حاليا، يمكن ربط تكوين صيانة واحد فقط بجدار Azure Firewall.

جميع وحدات Azure Firewall - الأساسية، القياسية، والمميزة تدعم الصيانة التي يتحكم بها العملاء.

قد يستغرق الأمر حتى 24 ساعة حتى يتبع Azure Firewall جدول الصيانة بعد ربط سياسة الصيانة.

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

لمزيد من المعلومات، راجع إعداد الصيانة التي يتحكم بها العميل.