الأسئلة المتداولة حول جدار حماية Azure

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

للتعرف على ميزات خدمة Azure Firewall، راجع قسم ميزات خدمة Azure Firewall.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

راجع تسعير جدار حماية Azure Firewall.

يمكنك استخدام أساليب إلغاء التخصيصووتخصيص في Azure PowerShell. يختلف الإجراء قليلًا بالنسبة لجدار حماية تم تكوينه للتوجيه القسري.

على سبيل المثال، جدار حماية لم يتم تكوينه للتوجيه القسري:

# Stop an existing 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

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

# Stop an existing 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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

بالنسبة لجدار الحماية في بنية المركز الظاهري الآمن، يكون الإيقاف هو نفسه ولكن يجب أن يستخدم البدء معرف المركز الظاهري:

# Stop and existing firewall

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

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

عند التخصيص وإلغاء التخصيص، تتوقف فوترة جدار الحماية وتبدأ وفقًا لذلك.

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

• يتم نشر جدار الحماية في VNet. وهو غير مدعوم بجدران الحماية الموزعة في مركز ظاهري آمن.
• تدعم منطقة جدار الحماية مناطق التوفر.
• يتم نشر جميع عناوين IP العامة المرفقة مع مناطق التوفر. في صفحة الخصائص لكل عنوان IP عام، تأكد من وجود حقل مناطق التوفر وتكوينه بنفس المناطق التي قمت بتكوينها لجدار الحماية.

لا يمكن إعادة تكوين مناطق التوفر إلا عند إعادة تشغيل جدار الحماية. بعد تخصيص جدار الحماية، وقبل بدء جدار الحماية مباشرة ب Set-AzFirewall، استخدم Azure PowerShell التالية لتعديل خاصية مناطق جدار الحماية:

$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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

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

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

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

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

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

يتم دعم التوجيه القسري عند إنشاء جدار حماية جديد. لا يمكنك تكوين جدار حماية موجود للتوجيه القسري. لمزيد من المعلومات، راجع توجيه Azure Firewall المفروض.

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

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

نعم. يجب أن يكون جدار الحماية وVNet وعنوان IP العام في نفس مجموعة الموارد.

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

أمثلة:

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

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

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

نعم. هناك 50 حرفًا كحد لاسم جدار حماية.

يجب أن يوفر جدار حماية Azure Firewall مثيلات الجهاز الظاهري أكثر أثناء قياسه. تضمن مساحة العنوان /26 أن جدار الحماية يحتوي على عناوين IP كافية متاحة لاستيعاب القياس.

‏‏لا. لا يحتاج جدار حماية Azure Firewall إلى شبكة فرعية أكبر من /26.

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

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

يستغرق التوسع من خمس إلى سبع دقائق.

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

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

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

‏‏لا. جدار حماية 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 والحصص النسبية والقيود

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

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

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

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

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

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

لا، جدار حماية Azure حاليا في المراكز الظاهرية الآمنة (vWAN) غير مدعوم في قطر.

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

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

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

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

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

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