Azure Firewall常见问题解答

概况

什么是Azure Firewall？

Azure Firewall是一种托管的基于云的网络安全服务，可保护Azure Virtual Network资源。 它是一个服务形式的完全有状态防火墙，具有内置的高可用性和不受限制的云可伸缩性。 可以跨订阅和虚拟网络集中创建、实施和记录应用程序与网络连接策略。

Azure Firewall支持哪些功能？

有关Azure Firewall功能的详细列表，请参阅 Azure Firewall 功能。

Azure Firewall的典型部署模型是什么？

可以在任何虚拟网络上部署Azure Firewall。 但是，它通常部署在中心虚拟网络中，采用中心辐射型模型结构，其他虚拟网络与之对等连接。 对等互连的虚拟网络中的默认路由设置为指向此中心防火墙虚拟网络。 虽然支持全局虚拟网络对等互连，但由于跨区域的潜在性能和延迟问题，因此不建议这样做。 为了获得最佳性能，请为每个区域部署一个防火墙。

此模型允许对跨不同订阅的多个分支 VNet 进行集中控制，并通过避免在每个虚拟网络中部署防火墙来节省成本。 应根据流量模式对关联的对等互连成本评估成本节省额。

如何部署Azure Firewall？

可以使用 Azure 门户、PowerShell、REST API 或模板部署Azure Firewall。 有关分步说明，请参阅 Tutorial：使用 Azure 门户部署和配置Azure Firewall。

什么是一些关键Azure Firewall概念？

Azure Firewall使用规则和规则集合。 规则集合是一组具有相同顺序和优先级的规则。 规则集合按优先级顺序执行。 DNAT 规则集合的优先级高于网络规则集合，而网络规则集合的优先级又高于应用程序规则集合。 所有规则都已终止。

有三种类型的规则集合：

• 应用程序规则：配置可从虚拟网络访问的完全限定域名（FQDN）。
• 网络规则：使用源地址、协议、目标端口和目标地址配置规则。
• NAT 规则：配置 DNAT 规则以允许传入 Internet 或 Intranet（预览版）连接。

有关详细信息，请参阅 Configure Azure Firewall 规则。

Azure Firewall支持哪些日志记录和分析服务？

Azure Firewall与Azure Monitor集成，用于查看和分析日志。 日志可以发送到Log Analytics、Azure Storage或事件中心，并使用Log Analytics、Excel或Power BI等工具进行分析。 有关详细信息，请参阅 Tutorial：监视Azure Firewall日志。

Azure Firewall与市场中 NVA 有何不同？

Azure Firewall是一种托管的基于云的网络安全服务，用于保护虚拟网络资源。 它是一个服务形式的完全有状态防火墙，具有内置的高可用性和不受限制的云可伸缩性。 它预先与第三方安全即服务（SECaaS）提供商集成，以增强虚拟网络和分支 Internet 连接的安全性。 有关详细信息，请参阅 Azure网络安全。

应用程序网关 WAF 与Azure Firewall有何区别？

应用程序网关 WAF 为 Web 应用程序提供集中式入站保护，以防止常见的攻击和漏洞。 Azure Firewall为非 HTTP/S 协议（例如 RDP、SSH、FTP）、所有端口和协议的出站网络级别保护以及出站 HTTP/S 的应用程序级保护提供入站保护。

网络安全组（NSG）与Azure Firewall有何区别？

Azure Firewall 补充使用 NSG，以提供更好的“深度防御”网络安全。 NSG 提供分布式网络层流量筛选，以限制每个订阅中的虚拟网络中的流量。 Azure Firewall跨订阅和虚拟网络提供集中式、完全有状态的网络和应用程序级保护。

AzureFirewallSubnet 是否支持网络安全组 (NSG)？

Azure 防火墙是具有多个保护层的托管服务，这些层包括使用 NIC 级 NSG（不可查看）进行的平台保护。 AzureFirewallSubnet 上不需要子网级 NSG，并且已禁用以防止服务中断。

Azure Firewall 与专用终结点结合使用的附加值是什么？

专用终结点是Private Link的一种技术，它允许使用专用 IP 地址而不是公共 IP 地址与 Azure PaaS 服务进行交互。 Azure 防火墙可用于防止访问公共 IP 地址，以避免数据外泄到不使用 Private Link 的 Azure 服务。此外，它还可以通过定义组织中需要访问 Azure PaaS 服务的人员来实施零信任策略，因为默认情况下，Private Link 会为整个企业网络打开网络访问。

使用 Azure Firewall 检查发往专用终结点的流量的正确设计将取决于网络体系结构，可以在文章Azure Firewall方案中找到更多详细信息，以检查发往专用终结点的流量。

Azure Firewall与虚拟网络服务终结点结合后有什么附加价值？

虚拟网络服务终结点是专用链接的替代方案，用于控制对 Azure PaaS 服务的网络访问。 即使客户端仍使用公共 IP 地址访问 PaaS 服务，源子网也可见，以便目标 PaaS 服务可以实施筛选器规则并基于每个子网限制访问。 可以在 “比较专用终结点”和服务终结点“中找到这两种机制之间的详细比较。

Azure Firewall应用程序规则可用于确保未发生流氓服务的数据外泄，并实现粒度超出子网级别的访问策略。 通常，需要在连接到Azure服务的客户端子网中启用虚拟网络服务终结点。 但是，当使用 Azure 防火墙检查到服务终结点的流量时，你需要改为在 Azure 防火墙子网中启用相应的服务终结点，并在实际客户端的子网（通常是分支虚拟网络）中禁用它们。 这样，便可以在Azure Firewall中使用应用程序规则来控制Azure工作负荷将有权访问哪些Azure服务。

Azure Firewall的定价是什么？

有关定价详细信息，请参阅 Azure Firewall 定价。

Azure Firewall的已知服务限制是什么？

有关服务限制，请参阅Azure订阅和服务限制、配额和约束。

Azure Firewall存储客户数据的位置？

Azure Firewall不会在部署客户数据的区域之外移动或存储数据。

卡塔尔是否支持安全虚拟中心（vWAN）中的Azure Firewall？

否，卡塔尔目前不支持安全虚拟中心（vWAN）中的Azure Firewall。

支持的功能和特性

Azure Firewall是否支持入站流量筛选？

是的，Azure Firewall支持入站和出站流量筛选。 入站筛选通常用于非 HTTP 协议，例如 RDP、SSH 和 FTP。 对于入站 HTTP 和 HTTPS 流量，请考虑使用 web 应用程序防火墙（如 Azure Web Application Firewall （WAF）或 Azure Firewall Premium 的 TLS 卸载和深度数据包检查功能。

Azure Firewall基本是否支持强制隧道？

是的，Azure Firewall Basic 支持强制隧道。

为什么即使没有规则允许流量，TCP ping 或类似工具也会连接到目标 FQDN？

TCP ping 实际上不会连接到目标 FQDN。 Azure Firewall阻止与任何目标 IP 地址或 FQDN 的连接，除非规则明确允许。

对于 TCP ping，如果没有任何规则允许流量，防火墙本身将响应客户端的 TCP ping 请求。 此响应不会到达目标 IP 地址或 FQDN，并且未记录。 如果网络规则显式允许访问目标 IP 地址或 FQDN，ping 请求将到达目标服务器，并且其响应将中继回客户端。 此事件记录在网络规则日志中。

Azure 防火墙是否支持 BGP 对等互联？

否，Azure Firewall 不原生支持 BGP 对等。 但是，Autolearn SNAT 路由功能通过 Azure Route Server 间接使用 BGP。

Azure Firewall传递 ESP 数据包（IPSec VPN）吗？

Azure Firewall本身不支持 ESP（封装安全有效负载），但可以通过配置网络规则来允许 ESP 流量，如下所示：

Azure Firewall配置（网络规则）：

• 协议：任何
• 源端口：* （任何）
• 目标端口：* （任何）
• 源/目标：根据需要指定 IP 地址

此配置允许 ESP 数据包（IP 协议编号 50）和其他非 TCP/UDP 流量与规则匹配。 但是，请注意，Azure Firewall 不会检查 ESP 数据负载。

参考：如果使用 NSG（网络安全组）而不是 Azure 防火墙： NSG 没有直接指定 ESP（IP 协议编号 50）的选项，但可以通过以下设置允许 ESP 数据包：

• 协议：任何
• 端口：* （任何）
• 源/目标：根据需要指定 IP 地址

Recommendations:

• 对于 IPsec VPN 配置，建议使用 Azure VPN Gateway。
• 请考虑根据要求使用 NVA（网络虚拟设备）模式。

管理和配置

如何停止和启动Azure Firewall？

可以使用Azure PowerShell解除分配和分配Azure Firewall。 该过程因配置而异。

对于没有管理 NIC 的防火墙：

# 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

对于具有管理 NIC 的防火墙：

# 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）必须位于同一订阅中。

预配状态“失败”的含义是什么？

失败的预配状态表示配置更新在一个或多个后端实例上失败。 Azure Firewall仍可正常运行，但配置可能不一致。 重试更新，直到预配状态更改为 “成功”。

Azure Firewall如何处理计划内维护和计划外故障？

Azure Firewall对多个后端节点使用主动-主动配置。 在计划维护期间，连接排出可确保顺利更新。 对于计划外故障，新节点将替换失败的节点，连接通常在 10 秒内还原。

防火墙名称是否存在字符限制？

是的，防火墙名称限制为 50 个字符。

为什么Azure Firewall需要 /26 子网大小？

/26 子网可确保有足够的 IP 地址用于扩展，因为 Azure Firewall 会配置额外的虚拟机实例。

在服务缩放时，防火墙子网大小是否需要更改？

否，/26 子网足以满足所有缩放方案。

如何提高防火墙吞吐量？

Azure Firewall根据 CPU 使用率、吞吐量和连接计数自动缩放。 吞吐量容量从最初为 2.5–3 Gbps 到 30 Gbps（标准 SKU）或 100 Gbps（高级 SKU）。

IP 组支持的 IP 地址数量是否有限制？

是的。 有关详细信息，请参阅 Azure 订阅和服务限制、配额和约束。

能否将 IP 组移到其他资源组？

否，目前不支持将 IP 组移动到其他资源组。

Azure Firewall的 TCP 空闲超时是什么？

网络防火墙的标准行为是确保 TCP 连接保持活动状态，并在没有活动时迅速将其关闭。 Azure Firewall TCP 空闲超时为四分钟。 此设置不可配置，但你可以联系Azure支持人员，将入站和出站连接的空闲超时增加到最多 15 分钟。 无法更改东西向流量的空闲超时。

如果处于非活动状态的时间超过超时值，则不能保证维持 TCP 或 HTTP 会话。 常见的做法是使用 TCP 保持连接状态。 这种做法可以使连接状态保持更长时间。 有关详细信息，请参阅 .NET 示例。

是否可以在没有公共 IP 地址的情况下部署Azure Firewall？

是，但你必须在强制隧道模式下配置防火墙。 此配置创建一个管理接口，该接口具有Azure Firewall用于其操作的公共 IP 地址。 此公共 IP 地址用于管理流量。 它专用于Azure平台，不能用于任何其他目的。 可以在没有公共 IP 地址的情况下配置租户数据路径网络，并且 Internet 流量可以强制通过隧道连接到另一个防火墙或完全被阻止。

是否有办法自动备份Azure Firewall和策略？

是的。 有关详细信息，请参阅 使用逻辑应用备份 Azure 防火墙和 Azure 防火墙策略。

连接和路由

如何使用服务终结点设置Azure Firewall？

若要安全访问 PaaS 服务，我们建议使用服务终结点。 可以选择在 Azure 防火墙子网中启用服务终结点，并在连接的分支虚拟网络中禁用它们。 这样可以受益于以下两个功能：服务终结点安全性和针对所有流量的集中日志记录。

中心虚拟网络中的 Azure 防火墙是否可以转发和过滤多个发散虚拟网络之间的网络流量？

能，可以在中心虚拟网络中使用 Azure 防火墙来路由和筛选多个分支虚拟网络之间的流量。 每个分支虚拟网络中的子网必须具有指向 Azure 防火墙的 UDR，作为此方案生效所需的默认网关。

是否可以Azure Firewall在同一虚拟网络或对等互连虚拟网络中的子网之间转发和筛选网络流量？

是的。 但是，将 UDR 配置为在同一虚拟网络中的子网之间重定向流量时需要额外注意。 虽然将虚拟网络地址范围用作 UDR 的目标前缀已足够，但这也通过Azure Firewall实例将同一子网中的所有流量路由到同一子网中的另一台计算机。 为了避免这种情况，请在 UDR 中为子网包含一个路由，并将下一跃点类型设为虚拟网络。 管理这些路由可能很麻烦并且容易出错。 建议的内部网络分段方法是使用不需要 UDR 的网络安全组。

Azure Firewall是否在专用网络之间执行出站SNAT？

对于专用网络，当目标 IP 地址属于 IANA RFC 1918 或 IANA RFC 6598 规定的专用 IP 网段时，Azure 防火墙不会执行 SNAT。 如果组织对专用网络使用公共 IP 地址范围，Azure 防火墙会将流量通过 SNAT 转换为 AzureFirewallSubnet 中的某个防火墙专用 IP 地址。 可以将 Azure Firewall 配置为不对公共 IP 地址范围执行 SNAT。 有关详细信息，请参阅 Azure Firewall SNAT 专用 IP 地址范围。

此外，应用程序规则处理的流量始终经过 SNAT。 如果要在日志中查看 FQDN 流量的原始源 IP 地址，可将网络规则与目标 FQDN 结合使用。

是否支持强制隧道/链接到网络虚拟设备？

创建新防火墙时支持强制隧道，并且通过为强制隧道添加管理 NIC 来支持现有防火墙。 有关新部署的更多详细信息，请参阅 Azure Firewall 强制隧道传输。 有关现有防火墙，请参阅 Azure Firewall Management NIC。

Azure Firewall必须具有直接 Internet 连接。 如果 AzureFirewallSubnet 知道通过 BGP 的本地网络的默认路由，则必须将其替代为 0.0.0.0/0 UDR，将 NextHopType 值设置为 Internet 以保持 Internet 直接连接。

如果你的配置需要通过强制隧道连接到本地网络，并且可以确定 Internet 目标的目标 IP 前缀，则可以通过 AzureFirewallSubnet 上用户定义的路由将本地网络的这些范围配置为下一跃点。 或者，可以使用 BGP 来定义这些路由。

目标 URL 和目标 FQDN 中的通配符在应用程序规则中如何工作？

• URL - 在最右边或最左边时，星号起作用。 如果它位于左侧，则不能是 FQDN 的一部分。
• FQDN - 星号在放在最左侧时可用。
• 常规 - 最左侧的星号表示左侧的任何内容将逐字匹配，这意味着多个子域和/或可能不需要的域名变体将匹配 - 参见以下示例。

示例：

类型	规则	是否支持？	正样本
目标 URL	www.contoso.com	是	www.contoso.com www.contoso.com/
目标 URL	*.contoso.com	是	any.contoso.com/ sub1.any.contoso.com
目标 URL	*contoso.com	是	example.anycontoso.com sub1.example.contoso.com contoso.com 警告：此通配符的使用还允许可能不需要/有风险的变体，例如 th3re4lcontoso.com -请谨慎使用。
目标 URL	www.contoso.com/test	是	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
目标 URL	www.contoso.com/test/*	是	www.contoso.com/test/anything 注意： www.contoso.com/test不匹配 （最后斜杠）
目标 URL	www.contoso.*/test/*	否
目标 URL	www.contoso.com/test?example=1	否
目标 URL	www.contoso.*	否
目标 URL	www.*contoso.com	否
目标 URL	www.contoso.com:8080	否
目标 URL	*.contoso.*	否
目标FQDN	www.contoso.com	是	www.contoso.com
目标FQDN	*.contoso.com	是	any.contoso.com 注意：如果要专门允许 contoso.com，则必须在规则中包含 contoso.com。 否则，默认情况下将删除连接，因为请求将不匹配任何规则。
目标FQDN	*contoso.com	是	example.anycontoso.com contoso.com
目标FQDN	www.contoso.*	否
目标FQDN	*.contoso.*	否

默认情况下，Azure Firewall是否允许访问Active Directory？

不是。 默认情况下，Azure Firewall会阻止Active Directory访问。 若要允许访问，请配置 AzureActiveDirectory 服务标记。 有关详细信息，请参阅 Azure Firewall 服务标记。

是否可以从基于威胁情报的Azure Firewall筛选中排除 FQDN 或 IP 地址？

可以，可以使用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 工具和同样的工具即使在 Azure 防火墙上没有规则允许该流量时仍能成功连接到目标 FQDN?

TCP ping 实际上并不连接到目标 FQDN。 Azure 防火墙不允许连接到任何目标 IP 地址/FQDN，除非存在允许它的显式规则。

TCP ping 是一个独特的用例，其中如果没有允许的规则，防火墙本身也会响应客户端的 TCP ping 请求，即使 TCP ping 不到达目标 IP 地址/FQDN。 在这种情况下，不会记录事件。 如果存在允许访问目标 IP 地址/FQDN 的网络规则，则 ping 请求将到达目标服务器，并且其响应将中继回客户端。 此事件记录在网络规则日志中。

为什么 TCP ping 和类似的工具成功连接到端口 80、443 和 1433 上的目标 FQDN/IP 地址，但在Azure Firewall日志中未观察到？

Azure Firewall充当端口 80、443 和 1433 的被动侦听器。 除非存在应用程序流量，否则Azure Firewall不会记录这些端口上的 TCP SYN 数据包。 HTTP GET 请求和 TLS 客户端 Hello 记录在 Azure Firewall。

IP 组支持的 IP 地址数量是否有限制？

是的。 有关详细信息，请参阅 Azure 订阅和服务限制、配额和约束

能否将 IP 组移到其他资源组？

否，目前不支持将 IP 组移动到其他资源组。

Azure Firewall的 TCP 空闲超时是什么？

网络防火墙的标准行为是确保 TCP 连接保持活动状态，并在没有活动时迅速将其关闭。 Azure Firewall TCP 空闲超时为四分钟。 此设置不可配置，但你可以联系Azure支持人员，将入站和出站连接的空闲超时增加到最多 15 分钟。 无法更改东西向流量的空闲超时。

如果处于非活动状态的时间超过超时值，则不能保证维持 TCP 或 HTTP 会话。 常见的做法是使用 TCP 保持连接状态。 这种做法可以使连接状态保持更长时间。 有关详细信息，请参阅 .NET 示例。

是否可以在没有公共 IP 地址的情况下部署Azure Firewall？

是，但你必须在强制隧道模式下配置防火墙。 此配置创建一个管理接口，该接口具有Azure Firewall用于其操作的公共 IP 地址。 此公共 IP 地址用于管理流量。 它专用于Azure平台，不能用于任何其他目的。 可以在没有公共 IP 地址的情况下配置租户数据路径网络，并且 Internet 流量可以强制通过隧道连接到另一个防火墙或完全被阻止。

Azure Firewall存储客户数据的位置？

Azure Firewall不会将客户数据移出其部署的区域。

是否有办法自动备份Azure Firewall和策略？

是的。 有关详细信息，请参阅 使用逻辑应用备份 Azure 防火墙和 Azure 防火墙策略。

卡塔尔是否支持安全虚拟中心（vWAN）中的Azure Firewall？

卡塔尔的安全虚拟中心（vWAN）中当前不支持Azure Firewall。

Azure Firewall支持多少个并行连接？

Azure 防火墙使用具有硬限制连接数的 Azure 虚拟机。 每个虚拟机的活动连接总数为 25 万。

每个防火墙的总限制为虚拟机连接限制 (250k) x 防火墙后端池中的虚拟机数。 Azure Firewall从两个虚拟机开始，并根据 CPU 使用率和吞吐量横向扩展。

Azure Firewall中的 SNAT TCP/UDP 端口重用行为是什么？

Azure Firewall当前对出站 SNAT 流量使用 TCP/UDP 源端口，且没有空闲等待时间。 关闭 TCP/UDP 连接后，所使用的 TCP 端口立即被视为可供即将建立的连接使用。

作为某些体系结构的替代方案，可以使用 NAT 网关和 Azure 防火墙 进行部署和扩展，以提供更大的 SNAT 端口池，提高灵活性和可用性。

Azure Firewall中的 NAT 行为是什么？

特定 NAT 行为取决于防火墙的配置和所配置的 NAT 类型。 例如，防火墙具有面向入站流量的 DNAT 规则，以及面向通过防火墙的出站流量的网络规则和应用程序规则。

有关详细信息，请参阅 Azure Firewall NAT 行为。

超时和缩放

连接清空的工作原理

对于任何计划内维护，连接清空逻辑会正常更新后端节点。 Azure Firewall等待 90 秒才能关闭现有连接。 在前 45 秒中，后端节点不接受新连接，并在剩余时间内响应 RST 所有传入数据包。 如果需要，客户端可以自动重建到另一个后端节点的连接。

Azure 防火墙如何处理虚拟机规模集横向缩减（纵向缩减）或舰队软件升级过程中的 VM 实例关闭问题？

在虚拟机规模集横向缩减（纵向缩减）过程中，或者在舰队软件升级过程中，可能会发生 Azure 防火墙 VM 实例关闭的情况。 在这些情况下，新的传入连接会负载均衡到其余的防火墙实例，而不会转发到已关闭的防火墙实例。 在 45 秒后，防火墙会通过发送 TCP RST 数据包来开始拒绝现有的连接。 再过 45 秒后，防火墙 VM 会关闭。 有关详细信息，请参阅负载均衡器 TCP 重置和空闲超时。

横向扩展Azure Firewall需要多长时间？

当平均吞吐量或 CPU 消耗达到 60%，或者连接使用率达到 80% 时，Azure Firewall 会逐渐扩展。 例如，当它达到最大吞吐量的 60% 时，即会开始横向扩展。 最大吞吐量数因Azure Firewall SKU 和已启用的功能而异。 有关详细信息，请参阅 Azure Firewall 性能。

横向扩展需要 5 到 7 分钟。 在性能测试时，请确保至少测试 10 到 15 分钟，并启动新连接以利用新创建的Azure Firewall节点。

Azure 防火墙如何处理空闲超时？

如果连接存在空闲超时时间（四分钟无活动），Azure Firewall通过发送 TCP RST 数据包有序地终止连接。

客户自主维护

客户控制的维护支持哪种维护类型？

Azure服务定期进行维护更新，以提高功能、可靠性、性能和安全性。 在配置的维护期间，客户操作系统维护和服务维护将在该时段内执行。 但是，客户控制的维护不包括主机更新或关键安全更新。

是否可以获取维护事件的高级通知？

Azure 防火墙维护的高级通知不可用。

我是否可以配置少于 5 小时的维护时段？

否，至少需要五个小时的维护时段。

是否可以配置每日计划以外的维护时段？

否，维护窗口当前配置为每天重复。

是否存在无法控制某些更新的情况？

由客户控制的维护支持客户机操作系统和服务更新，这些更新涵盖了客户关注的大多数维护项目。 但是，某些更新（如主机更新）不在客户控制的维护范围内。 在极少数情况下，为了解决高严重性安全问题，我们可能会接管您对维护窗口的控制。

维护配置资源是否必须与Azure Firewall位于同一区域？

是的。

是否可以为单个Azure Firewall创建多个维护配置？

不是。 目前，只能将一个维护配置与Azure Firewall相关联。

可以配置哪些 Azure 防火墙 SKU 来使用客户控制的维护？

所有 Azure 防火墙产品 - 基本版、标准版和高级版，都支持客户控制的维护。

将维护配置策略分配到Azure Firewall后，需要多长时间才能生效？

关联维护策略后，Azure 防火墙可能需要长达 24 小时才能按照维护计划执行维护。

我已经为其中一个 Azure 防火墙资源安排了将来的维护时段。 在此日期之前，该资源的维护活动是否会暂停？

Azure Firewall上的维护活动不会在计划维护时段之前的时间段内暂停。 对于未纳入维护计划的日期，资源的常规维护操作将继续照常进行。

如何在Azure Firewall上了解有关客户控制的维护的详细信息？

有关详细信息，请参阅 配置由客户控制的维护。

Azure Firewall是一种托管的基于云的网络安全服务，可保护Azure Virtual Network资源。 它是一个服务形式的完全有状态防火墙，具有内置的高可用性和不受限制的云可伸缩性。 可以跨订阅和虚拟网络集中创建、实施和记录应用程序与网络连接策略。

有关Azure Firewall功能的详细列表，请参阅 Azure Firewall 功能。

可以在任何虚拟网络上部署Azure Firewall。 但是，它通常部署在中心虚拟网络中，采用中心辐射型模型结构，其他虚拟网络与之对等连接。 对等互连的虚拟网络中的默认路由设置为指向此中心防火墙虚拟网络。 虽然支持全局虚拟网络对等互连，但由于跨区域的潜在性能和延迟问题，因此不建议这样做。 为了获得最佳性能，请为每个区域部署一个防火墙。

此模型允许对跨不同订阅的多个分支 VNet 进行集中控制，并通过避免在每个虚拟网络中部署防火墙来节省成本。 应根据流量模式对关联的对等互连成本评估成本节省额。

可以使用 Azure 门户、PowerShell、REST API 或模板部署Azure Firewall。 有关分步说明，请参阅 Tutorial：使用 Azure 门户部署和配置Azure Firewall。

Azure Firewall使用规则和规则集合。 规则集合是一组具有相同顺序和优先级的规则。 规则集合按优先级顺序执行。 DNAT 规则集合的优先级高于网络规则集合，而网络规则集合的优先级又高于应用程序规则集合。 所有规则都已终止。

有三种类型的规则集合：

• 应用程序规则：配置可从虚拟网络访问的完全限定域名（FQDN）。
• 网络规则：使用源地址、协议、目标端口和目标地址配置规则。
• NAT 规则：配置 DNAT 规则以允许传入 Internet 或 Intranet（预览版）连接。

有关详细信息，请参阅 Configure Azure Firewall 规则。

Azure Firewall与Azure Monitor集成，用于查看和分析日志。 日志可以发送到Log Analytics、Azure Storage或事件中心，并使用Log Analytics、Excel或Power BI等工具进行分析。 有关详细信息，请参阅 Tutorial：监视Azure Firewall日志。

Azure Firewall是一种托管的基于云的网络安全服务，用于保护虚拟网络资源。 它是一个服务形式的完全有状态防火墙，具有内置的高可用性和不受限制的云可伸缩性。 它预先与第三方安全即服务（SECaaS）提供商集成，以增强虚拟网络和分支 Internet 连接的安全性。 有关详细信息，请参阅 Azure网络安全。

应用程序网关 WAF 为 Web 应用程序提供集中式入站保护，以防止常见的攻击和漏洞。 Azure Firewall为非 HTTP/S 协议（例如 RDP、SSH、FTP）、所有端口和协议的出站网络级别保护以及出站 HTTP/S 的应用程序级保护提供入站保护。

Azure Firewall 补充使用 NSG，以提供更好的“深度防御”网络安全。 NSG 提供分布式网络层流量筛选，以限制每个订阅中的虚拟网络中的流量。 Azure Firewall跨订阅和虚拟网络提供集中式、完全有状态的网络和应用程序级保护。

Azure 防火墙是具有多个保护层的托管服务，这些层包括使用 NIC 级 NSG（不可查看）进行的平台保护。 AzureFirewallSubnet 上不需要子网级 NSG，并且已禁用以防止服务中断。

专用终结点是Private Link的一种技术，它允许使用专用 IP 地址而不是公共 IP 地址与 Azure PaaS 服务进行交互。 Azure 防火墙可用于防止访问公共 IP 地址，以避免数据外泄到不使用 Private Link 的 Azure 服务。此外，它还可以通过定义组织中需要访问 Azure PaaS 服务的人员来实施零信任策略，因为默认情况下，Private Link 会为整个企业网络打开网络访问。

使用 Azure Firewall 检查发往专用终结点的流量的正确设计将取决于网络体系结构，可以在文章Azure Firewall方案中找到更多详细信息，以检查发往专用终结点的流量。

虚拟网络服务终结点是专用链接的替代方案，用于控制对 Azure PaaS 服务的网络访问。 即使客户端仍使用公共 IP 地址访问 PaaS 服务，源子网也可见，以便目标 PaaS 服务可以实施筛选器规则并基于每个子网限制访问。 可以在 “比较专用终结点”和服务终结点“中找到这两种机制之间的详细比较。

Azure Firewall应用程序规则可用于确保未发生流氓服务的数据外泄，并实现粒度超出子网级别的访问策略。 通常，需要在连接到Azure服务的客户端子网中启用虚拟网络服务终结点。 但是，当使用 Azure 防火墙检查到服务终结点的流量时，你需要改为在 Azure 防火墙子网中启用相应的服务终结点，并在实际客户端的子网（通常是分支虚拟网络）中禁用它们。 这样，便可以在Azure Firewall中使用应用程序规则来控制Azure工作负荷将有权访问哪些Azure服务。

有关定价详细信息，请参阅 Azure Firewall 定价。

有关服务限制，请参阅Azure订阅和服务限制、配额和约束。

Azure Firewall不会在部署客户数据的区域之外移动或存储数据。

否，卡塔尔目前不支持安全虚拟中心（vWAN）中的Azure Firewall。

是的，Azure Firewall支持入站和出站流量筛选。 入站筛选通常用于非 HTTP 协议，例如 RDP、SSH 和 FTP。 对于入站 HTTP 和 HTTPS 流量，请考虑使用 web 应用程序防火墙（如 Azure Web Application Firewall （WAF）或 Azure Firewall Premium 的 TLS 卸载和深度数据包检查功能。

是的，Azure Firewall Basic 支持强制隧道。

TCP ping 实际上不会连接到目标 FQDN。 Azure Firewall阻止与任何目标 IP 地址或 FQDN 的连接，除非规则明确允许。

对于 TCP ping，如果没有任何规则允许流量，防火墙本身将响应客户端的 TCP ping 请求。 此响应不会到达目标 IP 地址或 FQDN，并且未记录。 如果网络规则显式允许访问目标 IP 地址或 FQDN，ping 请求将到达目标服务器，并且其响应将中继回客户端。 此事件记录在网络规则日志中。

否，Azure Firewall 不原生支持 BGP 对等。 但是，Autolearn SNAT 路由功能通过 Azure Route Server 间接使用 BGP。

Azure Firewall本身不支持 ESP（封装安全有效负载），但可以通过配置网络规则来允许 ESP 流量，如下所示：

Azure Firewall配置（网络规则）：

• 协议：任何
• 源端口：* （任何）
• 目标端口：* （任何）
• 源/目标：根据需要指定 IP 地址

此配置允许 ESP 数据包（IP 协议编号 50）和其他非 TCP/UDP 流量与规则匹配。 但是，请注意，Azure Firewall 不会检查 ESP 数据负载。

参考：如果使用 NSG（网络安全组）而不是 Azure 防火墙： NSG 没有直接指定 ESP（IP 协议编号 50）的选项，但可以通过以下设置允许 ESP 数据包：

• 协议：任何
• 端口：* （任何）
• 源/目标：根据需要指定 IP 地址

Recommendations:

• 对于 IPsec VPN 配置，建议使用 Azure VPN Gateway。
• 请考虑根据要求使用 NVA（网络虚拟设备）模式。

可以使用Azure PowerShell解除分配和分配Azure Firewall。 该过程因配置而异。

对于没有管理 NIC 的防火墙：

# 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

对于具有管理 NIC 的防火墙：

# 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根据 CPU 使用率、吞吐量和连接计数自动缩放。 吞吐量容量从最初为 2.5–3 Gbps 到 30 Gbps（标准 SKU）或 100 Gbps（高级 SKU）。

是的。 有关详细信息，请参阅 Azure 订阅和服务限制、配额和约束。

否，目前不支持将 IP 组移动到其他资源组。

网络防火墙的标准行为是确保 TCP 连接保持活动状态，并在没有活动时迅速将其关闭。 Azure Firewall TCP 空闲超时为四分钟。 此设置不可配置，但你可以联系Azure支持人员，将入站和出站连接的空闲超时增加到最多 15 分钟。 无法更改东西向流量的空闲超时。

如果处于非活动状态的时间超过超时值，则不能保证维持 TCP 或 HTTP 会话。 常见的做法是使用 TCP 保持连接状态。 这种做法可以使连接状态保持更长时间。 有关详细信息，请参阅 .NET 示例。

是，但你必须在强制隧道模式下配置防火墙。 此配置创建一个管理接口，该接口具有Azure Firewall用于其操作的公共 IP 地址。 此公共 IP 地址用于管理流量。 它专用于Azure平台，不能用于任何其他目的。 可以在没有公共 IP 地址的情况下配置租户数据路径网络，并且 Internet 流量可以强制通过隧道连接到另一个防火墙或完全被阻止。

是的。 有关详细信息，请参阅 使用逻辑应用备份 Azure 防火墙和 Azure 防火墙策略。

若要安全访问 PaaS 服务，我们建议使用服务终结点。 可以选择在 Azure 防火墙子网中启用服务终结点，并在连接的分支虚拟网络中禁用它们。 这样可以受益于以下两个功能：服务终结点安全性和针对所有流量的集中日志记录。

能，可以在中心虚拟网络中使用 Azure 防火墙来路由和筛选多个分支虚拟网络之间的流量。 每个分支虚拟网络中的子网必须具有指向 Azure 防火墙的 UDR，作为此方案生效所需的默认网关。

是的。 但是，将 UDR 配置为在同一虚拟网络中的子网之间重定向流量时需要额外注意。 虽然将虚拟网络地址范围用作 UDR 的目标前缀已足够，但这也通过Azure Firewall实例将同一子网中的所有流量路由到同一子网中的另一台计算机。 为了避免这种情况，请在 UDR 中为子网包含一个路由，并将下一跃点类型设为虚拟网络。 管理这些路由可能很麻烦并且容易出错。 建议的内部网络分段方法是使用不需要 UDR 的网络安全组。

对于专用网络，当目标 IP 地址属于 IANA RFC 1918 或 IANA RFC 6598 规定的专用 IP 网段时，Azure 防火墙不会执行 SNAT。 如果组织对专用网络使用公共 IP 地址范围，Azure 防火墙会将流量通过 SNAT 转换为 AzureFirewallSubnet 中的某个防火墙专用 IP 地址。 可以将 Azure Firewall 配置为不对公共 IP 地址范围执行 SNAT。 有关详细信息，请参阅 Azure Firewall SNAT 专用 IP 地址范围。

此外，应用程序规则处理的流量始终经过 SNAT。 如果要在日志中查看 FQDN 流量的原始源 IP 地址，可将网络规则与目标 FQDN 结合使用。

创建新防火墙时支持强制隧道，并且通过为强制隧道添加管理 NIC 来支持现有防火墙。 有关新部署的更多详细信息，请参阅 Azure Firewall 强制隧道传输。 有关现有防火墙，请参阅 Azure Firewall Management NIC。

Azure Firewall必须具有直接 Internet 连接。 如果 AzureFirewallSubnet 知道通过 BGP 的本地网络的默认路由，则必须将其替代为 0.0.0.0/0 UDR，将 NextHopType 值设置为 Internet 以保持 Internet 直接连接。

如果你的配置需要通过强制隧道连接到本地网络，并且可以确定 Internet 目标的目标 IP 前缀，则可以通过 AzureFirewallSubnet 上用户定义的路由将本地网络的这些范围配置为下一跃点。 或者，可以使用 BGP 来定义这些路由。

• URL - 在最右边或最左边时，星号起作用。 如果它位于左侧，则不能是 FQDN 的一部分。
• FQDN - 星号在放在最左侧时可用。
• 常规 - 最左侧的星号表示左侧的任何内容将逐字匹配，这意味着多个子域和/或可能不需要的域名变体将匹配 - 参见以下示例。

示例：

类型	规则	是否支持？	正样本
目标 URL	www.contoso.com	是	www.contoso.com www.contoso.com/
目标 URL	*.contoso.com	是	any.contoso.com/ sub1.any.contoso.com
目标 URL	*contoso.com	是	example.anycontoso.com sub1.example.contoso.com contoso.com 警告：此通配符的使用还允许可能不需要/有风险的变体，例如 th3re4lcontoso.com -请谨慎使用。
目标 URL	www.contoso.com/test	是	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
目标 URL	www.contoso.com/test/*	是	www.contoso.com/test/anything 注意： www.contoso.com/test不匹配 （最后斜杠）
目标 URL	www.contoso.*/test/*	否
目标 URL	www.contoso.com/test?example=1	否
目标 URL	www.contoso.*	否
目标 URL	www.*contoso.com	否
目标 URL	www.contoso.com:8080	否
目标 URL	*.contoso.*	否
目标FQDN	www.contoso.com	是	www.contoso.com
目标FQDN	*.contoso.com	是	any.contoso.com 注意：如果要专门允许 contoso.com，则必须在规则中包含 contoso.com。 否则，默认情况下将删除连接，因为请求将不匹配任何规则。
目标FQDN	*contoso.com	是	example.anycontoso.com contoso.com
目标FQDN	www.contoso.*	否
目标FQDN	*.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 ping 实际上并不连接到目标 FQDN。 Azure 防火墙不允许连接到任何目标 IP 地址/FQDN，除非存在允许它的显式规则。

TCP ping 是一个独特的用例，其中如果没有允许的规则，防火墙本身也会响应客户端的 TCP ping 请求，即使 TCP ping 不到达目标 IP 地址/FQDN。 在这种情况下，不会记录事件。 如果存在允许访问目标 IP 地址/FQDN 的网络规则，则 ping 请求将到达目标服务器，并且其响应将中继回客户端。 此事件记录在网络规则日志中。

Azure Firewall充当端口 80、443 和 1433 的被动侦听器。 除非存在应用程序流量，否则Azure Firewall不会记录这些端口上的 TCP SYN 数据包。 HTTP GET 请求和 TLS 客户端 Hello 记录在 Azure Firewall。

是的。 有关详细信息，请参阅 Azure 订阅和服务限制、配额和约束

否，目前不支持将 IP 组移动到其他资源组。

网络防火墙的标准行为是确保 TCP 连接保持活动状态，并在没有活动时迅速将其关闭。 Azure Firewall TCP 空闲超时为四分钟。 此设置不可配置，但你可以联系Azure支持人员，将入站和出站连接的空闲超时增加到最多 15 分钟。 无法更改东西向流量的空闲超时。

如果处于非活动状态的时间超过超时值，则不能保证维持 TCP 或 HTTP 会话。 常见的做法是使用 TCP 保持连接状态。 这种做法可以使连接状态保持更长时间。 有关详细信息，请参阅 .NET 示例。

是，但你必须在强制隧道模式下配置防火墙。 此配置创建一个管理接口，该接口具有Azure Firewall用于其操作的公共 IP 地址。 此公共 IP 地址用于管理流量。 它专用于Azure平台，不能用于任何其他目的。 可以在没有公共 IP 地址的情况下配置租户数据路径网络，并且 Internet 流量可以强制通过隧道连接到另一个防火墙或完全被阻止。

Azure Firewall不会将客户数据移出其部署的区域。

是的。 有关详细信息，请参阅 使用逻辑应用备份 Azure 防火墙和 Azure 防火墙策略。

卡塔尔的安全虚拟中心（vWAN）中当前不支持Azure Firewall。

Azure 防火墙使用具有硬限制连接数的 Azure 虚拟机。 每个虚拟机的活动连接总数为 25 万。

每个防火墙的总限制为虚拟机连接限制 (250k) x 防火墙后端池中的虚拟机数。 Azure Firewall从两个虚拟机开始，并根据 CPU 使用率和吞吐量横向扩展。

Azure Firewall当前对出站 SNAT 流量使用 TCP/UDP 源端口，且没有空闲等待时间。 关闭 TCP/UDP 连接后，所使用的 TCP 端口立即被视为可供即将建立的连接使用。

作为某些体系结构的替代方案，可以使用 NAT 网关和 Azure 防火墙 进行部署和扩展，以提供更大的 SNAT 端口池，提高灵活性和可用性。

特定 NAT 行为取决于防火墙的配置和所配置的 NAT 类型。 例如，防火墙具有面向入站流量的 DNAT 规则，以及面向通过防火墙的出站流量的网络规则和应用程序规则。

有关详细信息，请参阅 Azure Firewall NAT 行为。

对于任何计划内维护，连接清空逻辑会正常更新后端节点。 Azure Firewall等待 90 秒才能关闭现有连接。 在前 45 秒中，后端节点不接受新连接，并在剩余时间内响应 RST 所有传入数据包。 如果需要，客户端可以自动重建到另一个后端节点的连接。

在虚拟机规模集横向缩减（纵向缩减）过程中，或者在舰队软件升级过程中，可能会发生 Azure 防火墙 VM 实例关闭的情况。 在这些情况下，新的传入连接会负载均衡到其余的防火墙实例，而不会转发到已关闭的防火墙实例。 在 45 秒后，防火墙会通过发送 TCP RST 数据包来开始拒绝现有的连接。 再过 45 秒后，防火墙 VM 会关闭。 有关详细信息，请参阅负载均衡器 TCP 重置和空闲超时。

当平均吞吐量或 CPU 消耗达到 60%，或者连接使用率达到 80% 时，Azure Firewall 会逐渐扩展。 例如，当它达到最大吞吐量的 60% 时，即会开始横向扩展。 最大吞吐量数因Azure Firewall SKU 和已启用的功能而异。 有关详细信息，请参阅 Azure Firewall 性能。

横向扩展需要 5 到 7 分钟。 在性能测试时，请确保至少测试 10 到 15 分钟，并启动新连接以利用新创建的Azure Firewall节点。

如果连接存在空闲超时时间（四分钟无活动），Azure Firewall通过发送 TCP RST 数据包有序地终止连接。

Azure服务定期进行维护更新，以提高功能、可靠性、性能和安全性。 在配置的维护期间，客户操作系统维护和服务维护将在该时段内执行。 但是，客户控制的维护不包括主机更新或关键安全更新。

Azure 防火墙维护的高级通知不可用。

否，至少需要五个小时的维护时段。

否，维护窗口当前配置为每天重复。

由客户控制的维护支持客户机操作系统和服务更新，这些更新涵盖了客户关注的大多数维护项目。 但是，某些更新（如主机更新）不在客户控制的维护范围内。 在极少数情况下，为了解决高严重性安全问题，我们可能会接管您对维护窗口的控制。

是的。

不是。 目前，只能将一个维护配置与Azure Firewall相关联。

所有 Azure 防火墙产品 - 基本版、标准版和高级版，都支持客户控制的维护。

关联维护策略后，Azure 防火墙可能需要长达 24 小时才能按照维护计划执行维护。

Azure Firewall上的维护活动不会在计划维护时段之前的时间段内暂停。 对于未纳入维护计划的日期，资源的常规维护操作将继续照常进行。

有关详细信息，请参阅 配置由客户控制的维护。