面向虚拟网络的防火墙和应用程序网关

若要保护 Azure 应用程序工作负载，应在应用程序中使用保护措施，例如身份验证和加密。 你还可以向托管应用程序的虚拟网络 (VNet) 添加安全层。 这些安全层可保护应用程序的入站流免遭意外使用。 它们还将到 Internet 的出站流限制为应用程序需要的那些终结点。 本文介绍 Azure DDoS 防护、Azure 防火墙和 Azure 应用程序网关等 Azure 虚拟网络安全服务，每项服务的使用时机，以及结合使用两者的网络设计选项。

• Azure DDoS 防护与应用程序设计最佳做法相结合，提供增强的 DDoS 缓解功能来更全面地防御 DDoS 攻击。 应在任何外围虚拟网络上启用 Azure DDOS 防护。
• Azure 防火墙是一种托管的下一代防火墙，它提供网络地址转换 (NAT)。 Azure 防火墙基于 Internet 协议 (IP) 地址、传输控制协议和用户数据报协议 (TCP/UDP) 端口进行数据包筛选，也可基于应用程序的 HTTP(S) 或 SQL 属性进行数据包筛选。 Azure 防火墙还应用 Microsoft 威胁情报来识别恶意 IP 地址。 有关详细信息，请参阅 Azure 防火墙文档。
• Azure 防火墙高级版包括 Azure 防火墙标准版的所有功能和其他功能，例如 TLS 检查和入侵检测与保护系统 (IDPS)。
• Azure 应用程序网关是一个托管 Web 流量负载均衡器和 HTTP(S) 完整反向代理，可执行安全套接字层 (SSL) 加密和解密。 应用程序网关在 X-Forwarded-For HTTP 标头中保留原始客户端 IP 地址。 应用程序网关还使用 Web 应用程序防火墙来检查 Web 流量并检测对 HTTP 层的攻击。 有关详细信息，请参阅应用程序网关文档。
• Azure Web 应用程序防火墙 (WAF) 是 Azure 应用程序网关的可选补充服务。 它提供对 HTTP 请求的检查，并防止对 Web 层的恶意攻击，例如 SQL 注入或跨站脚本。 有关详细信息，请参阅 Web 应用程序防火墙文档。

这些 Azure 服务互为补充。 其中一种服务或另一种服务可能最适合你的工作负载，你也可以结合使用这些服务以在网络和应用程序层提供最佳保护。 使用以下决策树和本文中的示例来确定应用程序虚拟网络的最佳安全选项。

Azure 防火墙和 Azure 应用程序网关使用不同的技术，并支持不同流的安全化：

根据应用程序所需的网络流量，设计可能因应用程序而异。 下图提供了一个简化的决策树，可帮助为应用程序选择推荐的方法。 决定取决于应用程序是通过 HTTP(S) 还是其他协议发布：

本文将介绍流程图中广泛推荐的设计，以及适用于不太常见场景的其他设计：

• 当虚拟网络中没有 Web 应用程序时，则仅使用 Azure 防火墙。 它将控制应用程序的入站流量和出站流量。
• 当虚拟网络中只有 Web 应用程序，并且网络安全组 (NSG) 提供足够的输出筛选时，则仅使用应用程序网关。 Azure 防火墙提供的功能可以防止许多攻击方案（例如数据外泄、IDPS 等）。 由于此原因，通常不建议使用单独应用程序网关的方案，因此未对其进行记录，上面的流程图中也未显示该方案。
• Azure 防火墙和应用程序网关并行，它是最常见的设计之一。 如果希望 Azure 应用程序网关保护 HTTP(S) 应用程序使其免遭 Web 攻击，并希望 Azure 防火墙保护所有其他工作负载并筛选出站流量，请使用此组合。
• 当你希望 Azure 防火墙检查所有流量，希望 WAF 保护 Web 流量，以及应用程序知道客户端的源 IP 地址时，请使用 Azure 防火墙前面的应用程序网关。 借助 Azure 防火墙高级版和 TLS 检查，此设计还支持端到端 SSL 方案。
• 当你希望 Azure 防火墙在流量到达应用程序网关之前对其进行检查和筛选时，请使用应用程序网关前的 Azure 防火墙。 由于 Azure 防火墙不会解密 HTTPS 流量，因此它添加到应用程序网关的功能是有限的。 上面的流程图中没有记录此场景。

本文的最后部分介绍先前基本设计的变化。 这些变化包括：

• 本地应用程序客户端。
• 中心和分支网络。
• Azure Kubernetes 服务 (AKS) 实现。

可以添加其他反向代理服务，例如 API 管理网关或 Azure Front Door。 你也可以将 Azure 资源替换为第三方网络虚拟设备。

仅限 Azure 防火墙

如果虚拟网络中没有可以从 WAF 中受益的基于 Web 的工作负载，则只能使用 Azure 防火墙。 在这种情况下，设计很简单，但查看数据包流将有助于理解更复杂的设计。 在此设计中，所有入站流量都通过用户定义的路由 (UDR) 发送到 Azure 防火墙，用于来自本地或其他 Azure VNet 的连接。 它针对 Azure 防火墙的公共 IP 地址进行寻址，用于来自公共 Internet 的连接，如下图所示。 来自 Azure VNet 的出站流量通过 UDR 发送到防火墙，如下面的对话框中所示。

下表总结了此场景中的流量流：

Azure 防火墙不会检查入站 HTTP(S) 流量， 但它将能够应用第 3 层和第 4 层规则和基于 FQDN 的应用程序规则。 Azure 防火墙将根据 Azure 防火墙层以及是否配置了 TLS 检查来检查出站 HTTP(S) 流量：

• Azure 防火墙标准版将仅检查网络规则中数据包的第 3 层和第 4 层属性，以及应用程序规则中的主机 HTTP 标头。
• Azure 防火墙高级版会添加一些功能，例如检查 User-Agent 等其他 HTTP 标头和启用 TLS 检查，以便进行更深入的数据包分析。 Azure 防火墙不等同于 Web 应用程序防火墙。 如果虚拟网络中有 Web 工作负载，强烈建议使用 WAF。

以下数据包遍历示例显示了客户端如何通过公共 Internet 访问 VM 托管的应用程序。 为简单起见，该图仅包含一个 VM。 为了实现更高的可用性和可伸缩性，负载均衡器后面将有多个应用程序实例。 在此设计中，Azure 防火墙使用 UDR 检查来自公共 Internet 的传入连接和来自应用程序子网 VM 的出站连接。

• Azure 防火墙服务在后台部署了多个实例，其中前端 IP 地址为 192.168.100.4，内部地址范围为 192.168.100.0/26。 Azure 管理员通常看不到这些单独的实例。 但在某些情况下（例如在排查网络问题时），注意到这种差异是有帮助的。
• 如果流量来自本地虚拟专用网络 (VPN) 或 Azure ExpressRoute 网关而不是 Internet，则客户端会启动与 VM 的 IP 地址的连接。 它不会启动与防火墙 IP 地址的连接，并且防火墙默认不执行源 NAT。

体系结构

下图显示了流量流（假设实例 IP 地址为 192.168.100.7）。

工作流

1. 客户端开始连接到 Azure 防火墙的公共 IP 地址：
   • 源 IP 地址：ClientPIP
   • 目标 IP 地址：AzFwPIP
2. 对 Azure 防火墙公共 IP 的请求将被分发到防火墙的后端实例，在本例中为 192.168.100.7。 Azure 防火墙目标 NAT (DNAT) 规则将目标 IP 地址转换为虚拟网络内的应用程序 IP 地址。 如果 Azure 防火墙进行了 DNAT，则也会对数据包进行源 NAT (SNAT)。 有关详细信息，请参阅 Azure 防火墙已知问题。 VM 在传入数据包中看到以下 IP 地址：
   • 源 IP 地址：192.168.100.7
   • 目标 IP 地址：192.168.1.4
3. VM 响应应用程序请求、反转源和目标 IP 地址。 入站流不需要用户定义的路由 (UDR)，因为源 IP 是 Azure 防火墙的 IP 地址。 图中的 UDR 0.0.0.0/0 用于出站连接，以确保到公共 Internet 的数据包通过 Azure 防火墙。
   • 源 IP 地址：192.168.1.4
   • 目标 IP 地址：192.168.100.7
4. 最后，Azure 防火墙会撤消 SNAT 和 DNAT 操作，并将响应传递给客户端：
   • 源 IP 地址：AzFwPIP
   • 目标 IP 地址：ClientPIP

仅限应用程序网关

此设计涵盖了虚拟网络中仅存在 Web 应用程序的情况，并且使用 NSG 检查出站流量足以保护到 Internet 的出站流。

与仅使用 Azure 防火墙的先前设计的主要区别在于，应用程序网关不充当具有 NAT 的路由设备。 它充当完整的反向应用程序代理。 也就是说，应用程序网关会停止来自客户端的 Web 会话，并与其中一个后端服务器建立单独的会话。 来自 Internet 的入站 HTTP(S) 连接需要发送到应用程序网关的公共 IP 地址，而来自 Azure 或本地的连接需要发送到网关的专用 IP 地址。 来自 Azure VM 的返回流量将遵循返回到应用程序网关的标准 VNet 路由（请参阅数据包以进一步了解更多详细信息）。 来自 Azure VM 的出站 Internet 流将直接发送到 Internet。

下表汇总了流量流：

体系结构

以下数据包遍历示例显示了客户端如何通过公共 Internet 访问 VM 托管的应用程序。

工作流

1. 客户端开始连接到 Azure 应用程序网关的公共 IP 地址：
   • 源 IP 地址：ClientPIP
   • 目标 IP 地址：AppGwPIP
2. 对应用程序网关公共 IP 的请求将被分发到网关的后端实例，在本例中为 192.168.200.7。 接收请求的应用程序网关实例停止来自客户端的连接，并与其中一个后端建立新连接。 后端将应用程序网关实例视为源 IP 地址。 应用程序网关插入一个具有原始客户端 IP 地址的 X-Forwarded-For HTTP 标头。
   • 源 IP 地址：192.168.200.7（应用网关实例的专用 IP 地址）
   • 目标 IP 地址：192.168.1.4
   • X-Forwarded-For 标头：ClientPIP
3. VM 响应应用程序请求、反转源和目标 IP 地址。 VM 已经知道如何访问应用程序网关，因此不需要 UDR。
   • 源 IP 地址：192.168.1.4
   • 目标 IP 地址：192.168.200.7
4. 最后，应用程序网关实例会响应客户端：
   • 源 IP 地址：AppGwPIP
   • 目标 IP 地址：ClientPIP

Azure 应用程序网关将元数据添加到数据包 HTTP 标头，例如包含原始客户端 IP 地址的 X-Forwarded-For 标头。 某些应用程序服务器需要源客户端 IP 地址才能提供特定于地理位置的内容或进行日志记录。 有关详细信息，请参阅应用程序网关的工作原理。

• IP 地址 192.168.200.7 是 Azure 应用程序网关服务在后台部署的实例之一，此处为内部的专用前端 IP 地址 192.168.200.4。 Azure 管理员通常看不到这些单独的实例。 但在某些情况下（例如在排查网络问题时），注意到这种差异是有帮助的。

• 如果客户端来自通过 VPN 或 ExpressRoute 网关的本地网络，则流是类似的。 不同之处在于，客户端访问应用程序网关的专用 IP 地址而不是公共地址。

防火墙和应用程序网关并行

由于并行运行应用程序网关和 Azure 防火墙简单且灵活，因此通常是最佳方案。

如果虚拟网络中同时存在 Web 工作负载和非 Web 工作负载，则实现此设计。 Azure 应用程序网关中的 Azure WAF 保护 Web 工作负载的入站流量，而 Azure 防火墙检查其他应用程序的入站流量。 Azure 防火墙将涵盖来自这两种工作负载类型的出站流。

来自 Internet 的入站 HTTP(S) 连接应发送到应用程序网关的公共 IP 地址，而来自 Azure 或本地的 HTTP(S) 连接应发送到其专用 IP 地址。 标准 VNet 路由会将数据包从应用程序网关发送到目标 VM，以及将其从目标 VM 发送回应用程序网关（请参阅数据包以进一步了解更多详细信息）。 对于入站非 HTTP(S) 连接，流量应以 Azure 防火墙的公共 IP 地址为目标（如果来自公共 Internet），或者将由 UDR 通过 Azure 防火墙发送（如果来自其他 Azure VNet 或本地网络）。 来自 Azure VM 的所有出站流都将通过 UDR 转发到 Azure 防火墙。

下表总结了此场景中的流量流：

此设计提供了比 NSG 更精细的流出量筛选。 例如，如果应用程序需要连接到特定的 Azure 存储帐户，则可以使用基于完全限定的域名 (FQDN) 的筛选器。 有了基于 FQDN 的筛选器，应用程序不会向未授权存储帐户发送数据。 如果仅使用 NSG，则无法避免这种情况。 此设计通常用于需要基于 FQDN 进行筛选的出站流量。 其中一种示例情况是限制来自 Azure Kubernetes 服务群集的出口流量。

体系结构

下图说明了来自外部客户端的入站 HTTP(S) 连接的流量流：

下图说明了从网络 VM 到 Internet 的出站连接的流量流。 其中一个示例是连接到后端系统或获取操作系统更新：

每项服务的数据包流步骤与之前的独立设计选项相同。

防火墙前面的应用程序网关

本设计在使用 Azure 防火墙和应用程序网关的 Web 应用程序零信任网络中进行了更详细的说明，本文档将侧重于与其他设计方案的比较。 在此拓扑中，入站 Web 流量通过 Azure 防火墙和 WAF。 WAF 在 Web 应用程序层提供保护。 Azure 防火墙充当中心日志记录和控制点，并检查应用程序网关和后端服务器之间的流量。 应用程序网关和 Azure 防火墙不是并行的，而是相继的。

借助 Azure 防火墙高级版，此设计可以支持端到端方案，其中 Azure 防火墙应用 TLS 检查对应用程序网关和 Web 后端之间的加密流量执行 IDPS。

此设计适合需要知道传入客户端源 IP 地址的应用程序，例如用于提供特定于地理位置的内容或进行日志记录。 Azure 防火墙前面的应用程序网关在 X-forwarded-for 标头中捕获传入数据包的源 IP 地址，以便 Web 服务器可在此标头中看到原始 IP 地址。 有关详细信息，请参阅应用程序网关的工作原理。

来自 Internet 的入站 HTTP(S) 连接需要发送到应用程序网关的公共 IP 地址，而来自 Azure 或本地的 HTTP(S) 连接需要发送到专用 IP 地址。 来自应用程序网关的 UDR 将确保数据包通过 Azure 防火墙进行路由（请参阅数据包以进一步了解更多详细信息）。 对于入站非 HTTP(S) 连接，流量应以 Azure 防火墙的公共 IP 地址为目标（如果来自公共 Internet），或者将由 UDR 通过 Azure 防火墙发送（如果来自其他 Azure VNet 或本地网络）。 来自 Azure VM 的所有出站流都将通过 UDR 转发到 Azure 防火墙。

这种设计的一个重要特点是，Azure 防火墙高级版将看到来自应用程序网关子网的源 IP 地址的流量。 如果此子网配置了专用 IP 地址（在 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 或 100.64.0.0/10 中），则 Azure 防火墙高级版会将来自应用程序网关的流量视为内部流量，不会对入站流量应用 IDPS 规则。 有关 Azure 防火墙 IDPS 规则方向和 IDPS 专用 IP 前缀的详细信息，请参阅 Azure 防火墙 IDPS 规则。 因此，建议修改 Azure 防火墙策略中的 IDPS 专用前缀，以便让应用程序网关子网不会被视为内部源，从而对流量应用入站和出站 IDPS 签名。

下表总结了此场景中的流量流：

对于从本地或 Internet 到 Azure 的 Web 流量，Azure 防火墙将检查 WAF 已允许的流。 根据应用程序网关是否加密后端流量（从应用程序网关到应用程序服务器的流量），提供不同的潜在方案：

1. 应用程序网关按照零信任原则（端到端 TLS 加密）对流量进行加密，Azure 防火墙将接收已加密的流量。 尽管如此，Azure 防火墙标准版仍将能够应用检查规则，例如使用 TLS 服务器名称指示 (SNI) 标头在网络规则中进行第 3 层和第 4 层筛选，或在应用程序规则中进行 FQDN 筛选。 Azure 防火墙高级版通过 TLS 检查提供更深入的可见性，例如基于 URL 进行筛选。
2. 如果应用程序网关将未加密的流量发送到应用程序服务器，则 Azure 防火墙将以明文形式查看入站流量。 Azure 防火墙中不需要 TLS 检查。
3. 如果在 Azure 防火墙中启用了 IDPS，它将验证 HTTP 主机头是否与目标 IP 匹配。 为此，它需要对主机头中指定的 FQDN 进行名称解析。 此名称解析可通过 Azure DNS 专用区域和使用 Azure DNS 的默认 Azure 防火墙 DNS 设置来实现。 也可通过需要在 Azure 防火墙设置中配置的自定义 DNS 服务器来实现此目的。 （有关详细信息，请参阅 Azure 防火墙 DNS 设置。）如果没有对部署了 Azure 防火墙的虚拟网络的管理访问权限，则只能使用第二种方法。 其中一个示例就是部署在虚拟 WAN 安全中心中的 Azure 防火墙。

体系结构

对于其余的流（入站非 HTTP(S) 流量和任何出站流量），Azure 防火墙将在适当的情况下提供 IDPS 检查和 TLS 检查。 它还提供基于 DNS 在网络规则中基于 FQDN 进行筛选。

Workflow

来自公共 Internet 的网络流量遵循以下流程：

1. 客户端开始连接到 Azure 应用程序网关的公共 IP 地址：
   • 源 IP 地址：ClientPIP
   • 目标 IP 地址：AppGwPIP
2. 对应用程序网关公共 IP 的请求将被分发到网关的后端实例，在本例中为 192.168.200.7。 应用程序网关实例停止来自客户端的连接，并与其中一个后端建立新连接。 应用程序网关子网中的 UDR 192.168.1.0/24 将数据包转发到 Azure 防火墙，同时将目标 IP 保留给 Web 应用程序：
   • 源 IP 地址：192.168.200.7（应用网关实例的专用 IP 地址）
   • 目标 IP 地址：192.168.1.4
   • X-Forwarded-For 标头：ClientPIP
3. Azure 防火墙不会对流量进行 SNAT，因为流量将发送到专用 IP 地址。 如果规则允许将流量转发到应用程序 VM，则 Azure 防火墙会这样做。 有关详细信息，请参阅 Azure 防火墙 SNAT。 但是，如果流量遇到防火墙中的应用程序规则，工作负载将看到处理数据包的特定防火墙实例的源 IP 地址，因为 Azure 防火墙将代理连接：
   • 源 IP 地址（如果 Azure 防火墙网络规则允许流量）：192.168.200.7（其中一个应用程序网关实例的专用 IP 地址）。
   • 源 IP 地址（如果 Azure 防火墙应用程序规则允许流量）：192.168.100.7（其中一个 Azure 防火墙实例的专用 IP 地址）。
   • 目标 IP 地址：192.168.1.4
   • X-Forwarded-For 标头：ClientPIP
4. VM 响应请求、反转源和目标 IP 地址。 UDR 192.168.200.0/24 捕获发送回应用程序网关的数据包并将其重定向到 Azure 防火墙，同时将目标 IP 保留到应用程序网关。
   • 源 IP 地址：192.168.1.4
   • 目标 IP 地址：192.168.200.7
5. 再说一次，由于流量将发送到专用 IP 地址，因此 Azure 防火墙不会对流量进行 SNAT，并将流量转发到应用程序网关。
   • 源 IP 地址：192.168.1.4
   • 目标 IP 地址：192.168.200.7
6. 最后，应用程序网关实例会响应客户端：
   • 源 IP 地址：AppGwPIP
   • 目标 IP 地址：ClientPIP

从 VM 到公共 Internet 的出站流通过由 UDR 0.0.0.0/0 定义的 Azure 防火墙。

防火墙后面的应用程序网关

此设计允许 Azure 防火墙在恶意流量到达应用程序网关之前对其进行筛选和放弃。 例如，它可以应用基于威胁情报进行筛选等功能。 另一个好处是，不管协议如何，应用程序都可以为入站流量和出站流量获得相同的公共 IP 地址。 不过，Azure 防火墙会对传入的流量进行 SNAT，因此应用程序将无法查看 HTTP 请求的原始 IP 地址。 从管理角度看，例如出于故障排除目的，可以通过将特定连接与 Azure 防火墙的 SNAT 日志相关联来获取特定连接的实际客户端 IP。

在此方案中，优点有限，因为 Azure 防火墙只会看到发送到应用程序网关的已加密流量。 在某些情况下，建议首选此设计。 一种情况是当另一个 WAF 在网络中更早出现时（例如使用 Azure Front Door），这可捕获 X-Forwarded-For HTTP 标头中的原始源 IP。 如果需要很多公共 IP 地址，也建议首选此设计。

来自公共 Internet 的 HTTP(S) 入站流应以 Azure 防火墙的公共 IP 地址为目标，Azure 防火墙会对数据包进行 DNAT（和 SNAT），使其转换为应用程序网关的专用 IP 地址。 来自其他 Azure VNet 或本地网络的 HTTP(S) 流量应发送到应用程序网关的专用 IP，并通过带有 UDR 的 Azure 防火墙进行转发。 标准 VNet 路由将确保来自 Azure VM 的返回流量返回到应用程序网关，如果使用了 DNAT 规则，则从应用程序网关返回到 Azure 防火墙。 应使用来自应用程序网关子网中的本地或 Azure UDR 的流量（请参阅数据包以进一步了解更多详细信息）。 从 Azure VM 到 Internet 的所有出站流量都将由 UDR 通过 Azure 防火墙发送。

下表总结了此场景中的流量流：

对于入站 HTTP(S) 流量，Azure 防火墙通常不会对流量进行解密， 而是应用不需要 TLS 检查的 IDPS 策略，例如基于 IP 进行筛选或使用 HTTP 标头。

体系结构

应用程序看不到 Web 流量的原始源 IP 地址；在将数据包发送到虚拟网络时，Azure 防火墙会对其进行 SNAT。 若要避免此问题，请在防火墙前面使用 Azure Front Door。 Azure Front Door 会在客户端进入 Azure 虚拟网络之前将其 IP 地址作为 HTTP 标头注入。

Workflow

来自公共 Internet 的网络流量遵循以下流程：

1. 客户端开始连接到 Azure 防火墙的公共 IP 地址：
   • 源 IP 地址：ClientPIP
   • 目标 IP 地址：AzFWPIP
2. 对 Azure 防火墙公共 IP 的请求将被分发到防火墙的后端实例，在本例中为 192.168.100.7。 Azure 防火墙会对 Web 端口进行 DNAT（通常是 TCP 443）以转换为应用程序网关实例的专用 IP 地址。 Azure 防火墙在执行 DNAT 时也会进行 SNAT。 有关详细信息，请参阅 Azure 防火墙已知问题：
   • 源 IP 地址：192.168.100.7（Azure 防火墙实例的专用 IP 地址）
   • 目标 IP 地址：192.168.200.4
3. 应用程序网关在处理连接的实例和其中一个后端服务器之间建立一个新会话。 数据包中不包含客户端的原始 IP 地址：
   • 源 IP 地址：192.168.200.7（应用网关实例的专用 IP 地址）
   • 目标 IP 地址：192.168.1.4
   • X-Forwarded-For 标头：192.168.100.7
4. VM 响应应用程序请求、反转源和目标 IP 地址：
   • 源 IP 地址：192.168.1.4
   • 目标 IP 地址：192.168.200.7
5. 应用程序网关回复 Azure 防火墙实例的 SNAT 源 IP 地址。 即使连接来自特定的应用程序网关实例（如 .7），Azure 防火墙也会将应用程序网关的内部 IP 地址 .4 视为源 IP：
   • 源 IP 地址：192.168.200.4
   • 目标 IP 地址：192.168.100.7
6. 最后，Azure 防火墙撤消 SNAT 和 DNAT 并响应客户端：
   • 源 IP 地址：AzFwPIP
   • 目标 IP 地址：ClientPIP

即使应用程序网关没有为应用程序配置侦听器，它仍需要公共 IP 地址，以便 Microsoft 可以对其进行管理。

本地客户端

上述设计都显式了来自公共 Internet 的应用程序客户端。 本地网络也可以访问应用程序。 上述大部分信息和流量流与 Internet 客户端相同，但也有一些显著的区别：

• VPN 网关或 ExpressRoute 网关位于 Azure 防火墙或应用程序网关的前面。
• WAF 使用应用程序网关的专用 IP 地址。
• 对于专用 IP 地址，Azure 防火墙不支持 DNAT。 这就是必须使用 UDR 将入站流量从 VPN 或 ExpressRoute 网关发送到 Azure 防火墙的原因。
• 确保验证有关 Azure 应用程序网关和 Azure 防火墙的强制隧道的注意事项。 即使工作负载不需要到公共 Internet 的出站连接，也不能为指向本地网络的应用程序网关注入 0.0.0.0/0 等默认路由，否则将中断控制流量。 对于 Azure 应用程序网关，默认路由需要指向公共 Internet。

体系结构

下图显示了 Azure 应用程序网关和 Azure 防火墙的并行设计。 应用程序客户端来自通过 VPN 或 ExpressRoute 连接到 Azure 的本地网络：

即使所有客户端都位于本地或 Azure 中，Azure 应用程序网关和 Azure 防火墙也需要具有公共 IP 地址。 Microsoft 可通过公共 IP 地址来管理服务。

中心和辐射拓扑

本文中的设计仍然适用于中心和辐射拓扑。 中央的中心虚拟网络中的共享资源通过虚拟网络对等互连来连接到不同分支虚拟网络中的应用程序。

体系结构

注意事项

此拓扑的一些注意事项包括：

• Azure 防火墙部署在中央的中心虚拟网络中。 上图显示在中心中部署应用程序网关的做法。 不过，应用程序团队通常会管理 Azure 应用程序网关或 Azure API 管理网关等组件。 在本例中，这些组件部署在分支虚拟网络中。
• 请特别注意分支网络中的 UDR：当分支中的应用程序服务器从特定 Azure 防火墙实例（如前面示例中的 192.168.100.7 地址）接收流量时，它应将返回流量发送回相同的实例。 如果分支中的 UDR 将发送到中心的流量的下一个跃点设置为 Azure 防火墙 IP 地址（上图中的 192.168.100.4），则返回数据包可能最终到达不同的 Azure 防火墙实例，从而导致非对称路由。 确保如果分支 VNet 中的 UDR 通过 Azure 防火墙将流量发送到中心中的共享服务，这些 UDR 不包括 Azure 防火墙子网的前缀。
• 上述建议同样适用于应用程序网关子网和可能部署在中心 VNet 中的任何其他网络虚拟设备或反向代理。
• 不能通过具有 Virtual Network 下一个跃点类型的静态路由为应用程序网关或 Azure 防火墙子网设置下一个跃点。 此下一个跃点类型仅在本地 VNet 中有效，而在 VNet 对等互连中无效。 有关用户定义的路由和下一个跃点类型的详细信息，请参阅虚拟网络流量路由。

非对称路由

下图显示了中心如何将已进行 SNAT 的流量发送回 Azure 防火墙的 ALB。 此设置会导致非对称路由：

若要解决此问题，请在没有 Azure 防火墙子网但仅包含共享服务所在的子网的中心中定义 UDR。 在示例中，中心中的正确 UDR 应仅包含 192.168.1.0/24。 它不应包含用红色标记的整个 192.168.0.0/16。

与其他 Azure 产品集成

可将 Azure 防火墙和 Azure 应用程序网关与其他 Azure 产品和服务集成。

API 管理网关

将 API 管理网关等反向代理服务集成到前面的设计中，以提供 API 限制或身份验证代理等功能。 集成 API 管理网关并不会在很大程度地改变设计。 主要区别在于，不提供单个应用程序网关反向代理，而是提供两个相互链接的反向代理。

有关详细信息，请参阅关于在虚拟网络中集成 API 管理和应用程序网关的设计指南和应用程序模式用于微服务的 API 网关。

Azure Kubernetes 服务

对于在 AKS 群集上运行的工作负载，可以独立于群集部署 Azure 应用程序网关。 你也可以使用 Azure 应用程序网关入口控制器将其与 AKS 群集集成。 当在 Kubernetes 级别配置某些对象（例如服务和入口）时，应用程序网关会自动适应，而无需额外的手动步骤。

Azure 防火墙在 AKS 群集安全性方面发挥着重要作用。 它提供了基于 FQDN（而不仅仅是 IP 地址）筛选来自 AKS 群集的出口流量所需的功能。 有关详细信息，请参阅控制 AKS 群集节点的出口流量。

当结合使用应用程序网关和 Azure 防火墙来保护 AKS 群集时，最好使用并行设计选项。 带有 WAF 的应用程序网关处理对群集中 Web 应用程序的入站连接请求。 Azure 防火墙仅允许显式允许的出站连接。 有关并行设计选项的示例，请参阅 Azure Kubernetes 服务 (AKS) 群集的基线体系结构。

Azure Front Door

Azure Front Door 功能与 Azure 应用程序网关部分重叠。 例如，这两种服务都提供 Web 应用程序防火墙、SSL 卸载和基于 URL 的路由。 一个主要区别是，虽然 Azure 应用程序网关位于虚拟网络内，但 Azure Front Door 是一项全局分散式服务。

有时，可以通过将应用程序网关替换为分散式 Azure Front Door 来简化虚拟网络设计。 此处介绍的大多数设计仍然有效，但“将 Azure 防火墙置于 Azure Front Door 前面”选项除外。

一个有趣的用例是在虚拟网络中的应用程序网关前面使用 Azure 防火墙。 如前文所述，应用程序网关注入的 X-Forwarded-For 标头将包含防火墙实例的 IP 地址，而不是客户端的 IP 地址。 一种解决方法是在流量进入虚拟网络并到达 Azure 防火墙之前，在防火墙前面使用 Azure Front Door 将客户端的 IP 地址作为 X-Forwarded-For 标头注入。 第二个选项是在 Azure Front Door 高级版中使用专用链接保护源。

有关这两种服务之间的差异或其中每种服务的使用时机的详细信息，请参阅 Azure Front Door 常见问题解答。

其他网络虚拟设备

Microsoft 产品并不是在 Azure 中实现 Web 应用程序防火墙或下一代防火墙功能的唯一选择。 许多 Microsoft 合作伙伴提供网络虚拟设备 (NVA)。 概念和设计与本文中的基本相同，但有一些重要的注意事项：

• 用于下一代防火墙的合作伙伴 NVA 可以为 Azure 防火墙不支持的 NAT 配置提供更多控制和灵活性。 示例包括在没有 SNAT 的情况下来自本地的 DNAT 或来自 Internet 的 DNAT。
• 与用户需要跨多个设备处理可伸缩性和复原能力的 NVA 相比，Azure 管理的 NVA（如应用程序网关和 Azure 防火墙）可降低复杂性。
• 当在 Azure 中使用 NVA 时，请使用“主动-主动”和“自动缩放”设置，以便这些设备不会成为在虚拟网络中运行的应用程序的瓶颈。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Jose Moreno | 首席客户工程师

后续步骤

了解有关组件技术的详细信息：

• 什么是 Azure 应用程序网关？
• 什么是 Azure 防火墙？
• 什么是 Azure Front Door？
• Azure Kubernetes 服务
• 什么是 Azure 虚拟网络？
• 什么是 Azure Web 应用程序防火墙？

相关资源

探索相关体系结构：

• 实现安全的混合网络
• 安全地托管 Web 应用程序
• 使用防火墙保护 Microsoft Teams 频道机器人和 Web 应用
• Azure 上的消费者健康门户
• Azure 中高度敏感的 IaaS 应用的安全注意事项
• Azure 上的多租户 SaaS
• 使用应用服务环境进行企业部署
• 使用应用服务环境进行高可用性企业部署
• Azure Kubernetes 服务 (AKS) 群集的基线体系结构