虚拟网络的 Azure 防火墙和应用程序网关
为了帮助保护 Azure 应用程序工作负载，请使用安全措施，例如在应用程序中进行身份验证和加密。 可以将安全层添加到托管应用程序的虚拟网络。 这些安全层有助于保护应用程序的入站流免受意外使用。 它们还会将出站流限制为仅将出站流限制为应用程序所需的终结点。 本文介绍 Azure 虚拟网络 安全服务，例如 Azure DDoS 防护、Azure 防火墙和 Azure 应用程序网关。 它还介绍了何时使用合并它们的每个服务和网络设计选项。
DDoS 防护与应用程序设计最佳做法相结合，提供了增强的 DDoS 缓解功能，可改善对 DDoS 攻击的防御。 应在每个外围虚拟网络上启用 DDoS 防护。
Azure 防火墙 是一种托管的下一代防火墙，可提供 网络地址转换（NAT） 功能。 Azure 防火墙基于 IP 地址和传输控制协议（TCP）或用户数据报协议（UDP）端口筛选数据包。 它可以使用基于应用程序的属性（如 HTTP（S）和 SQL 来筛选流量。 Azure 防火墙还应用Microsoft威胁情报来帮助识别恶意 IP 地址。 有关详细信息，请参阅 Azure 防火墙文档。
除了传输层安全性（TLS）检查和入侵检测和防护系统（IDPS）等功能外，Azure 防火墙高级版 还包括 Azure 防火墙标准的所有功能。
应用程序网关 是一个托管的 Web 流量负载均衡器和 HTTP（S）完全反向代理，可执行安全套接字层（SSL）加密和解密。 应用程序网关在
X-Forwarded-ForHTTP 标头中保留原始客户端 IP 地址。 应用程序网关还使用 Azure Web 应用程序防火墙来检查 Web 流量，并检测 HTTP 层的攻击。 有关详细信息，请参阅 应用程序网关文档。Web 应用程序防火墙 是应用程序网关的可选补充。 它检查 HTTP 请求并防止 Web 层攻击，例如 SQL 注入和跨站点脚本。 有关详细信息，请参阅 Web 应用程序防火墙文档。
这些 Azure 服务相互补充。 根据需求，使用一个服务可能更适合工作负荷。 但是，可以将这些服务一起使用，以帮助在网络层和应用程序层提供最佳保护。 使用以下决策树和本文中的示例为应用程序的虚拟网络选择最佳安全选项。
Azure 防火墙和应用程序网关使用不同的技术来帮助保护不同类型的数据流。
| 应用程序流 | 可以通过 Azure 防火墙筛选 | 可以通过应用程序网关上的 Web 应用程序防火墙进行筛选 |
|---|---|---|
| 从本地或 Internet 到 Azure 的 HTTP（S） 流量（入站） | 是的 | 是的 |
| 从 Azure 到本地或 Internet 的 HTTP（S） 流量（出站） | 是的 | 不 |
| 非 HTTP（S） 流量（入站或出站） | 是的 | 不 |
根据每个应用程序所需的网络流，设计可能会有所不同。 下图提供了一个简化的决策树，可帮助你为应用程序选择推荐的方法。 此选项取决于应用程序是通过 HTTP（S） 还是其他协议发布。
本文介绍流程图中显示的广为推荐的设计，以及适合不太常见的方案的设计：
Azure 防火墙仅： 虚拟网络中没有 Web 应用程序时使用此设计。 它控制应用程序的入站流量和出站流量。
应用程序网关仅： 仅当 Web 应用程序位于虚拟网络中并且 网络安全组（NSG） 提供足够的输出筛选时，请使用此设计。 Azure 防火墙提供的功能可帮助防止多种攻击方案，例如数据外泄和 IDPS。 因此，通常不建议使用仅限应用程序网关的设计，因此它不包括在前面的流程图中。
Azure 防火墙和应用程序网关并行： 当希望应用程序网关保护 HTTP（S） 应用程序免受 Web 攻击和 Azure 防火墙保护所有其他工作负荷并筛选出站流量时，请使用此设计。 Azure 防火墙和应用程序网关是一种常见的设计。
Azure 防火墙前面的应用程序网关： 当希望 Azure 防火墙检查所有流量、用于保护 Web 流量的 Web 应用程序防火墙以及应用程序标识客户端的源 IP 地址时，请使用此设计。 通过 Azure 防火墙高级版和 TLS 检查，此设计还支持端到端 SSL 方案。
应用程序网关前的 Azure 防火墙： 希望 Azure 防火墙在到达应用程序网关之前检查和筛选流量时使用此设计。 由于 Azure 防火墙不会解密 HTTPS 流量，因此其添加到应用程序网关的功能有限。 上一个流程图中未记录此方案。
本文稍后将介绍这些基本设计的变体，包括：
可以添加其他反向代理服务，例如 Azure API 管理 网关或 Azure Front Door。 或者，可以将 Azure 资源替换为非Microsoft 网络虚拟设备（NVA）。
注意
在以下方案中，Azure 虚拟机（VM）用作 Web 应用程序工作负荷的示例。 这些方案也适用于其他工作负荷类型，例如容器或 Azure Web 应用。 对于包括专用终结点的设置，请考虑 Azure 防火墙方案中的建议，以检查发往专用终结点的流量。
仅限 Azure 防火墙的设计
如果虚拟网络中没有可从 Web 应用程序防火墙中受益的基于 Web 的工作负荷，则可以使用仅限 Azure 防火墙的设计。 此示例中的设计很简单，但你可以查看数据包流，以便更好地了解更复杂的设计。 在此设计中，所有入站流量都通过用户定义的路由（UDR）发送到 Azure 防火墙，以便从本地或其他 Azure 虚拟网络建立连接。 它针对来自公共 Internet 的连接的 Azure 防火墙公共 IP 地址进行寻址，如下图所示。 UDR 将出站流量从 Azure 虚拟网络定向到 Azure 防火墙，如以下对话框中所示。
下表汇总了此方案的流量流。
| 流 | 浏览应用程序网关/Web 应用程序防火墙 | 通过 Azure 防火墙 |
|---|---|---|
| 来自 Internet 或本地到 Azure 的 HTTP（S） 流量 | N/A | 是的 |
| 从 Azure 到 Internet 或本地的 HTTP（S） 流量 | N/A | 是的 |
| 来自 Internet 或本地到 Azure 的非 HTTP（S） 流量 | N/A | 是的 |
| 从 Azure 到 Internet 或本地的非 HTTP（S） 流量 | N/A | 是的 |
Azure 防火墙不会检查入站 HTTP（S） 流量。 但它可以应用第 3 层和第 4 层规则以及基于 FQDN 的完全限定的域名应用程序规则。 Azure 防火墙根据 Azure 防火墙层以及是否配置 TLS 检查来检查出站 HTTP（S） 流量：
Azure 防火墙标准版仅检查网络规则中的数据包的第 3 层和第 4 层属性，以及应用程序规则中的主机 HTTP 标头。
Azure 防火墙高级版添加了功能，例如检查其他 HTTP 标头（如用户代理），并启用 TLS 检查，以便进行更深入的数据包分析。 但是，Azure 防火墙与 Web 应用程序防火墙不同。 如果虚拟网络中有 Web 工作负载，建议使用 Web 应用程序防火墙。
以下数据包演练示例演示客户端如何从公共 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。
显示仅限 Azure 防火墙设计的 
工作流
客户端启动与 Azure 防火墙的公共 IP 地址的连接。
- 源 IP 地址：
ClientPIP - 目标 IP 地址：
AzFwPIP
- 源 IP 地址：
对 Azure 防火墙公共 IP 地址的请求将分发到防火墙的后端实例，在此示例中
192.168.100.7。 Azure 防火墙 目标网络地址转换（DNAT）规则 将目标 IP 地址转换为虚拟网络中的应用程序 IP 地址。 如果数据包使用 DNAT，Azure 防火墙还会在数据包上实现 源网络地址转换（SNAT）。 有关详细信息，请参阅 Azure 防火墙已知问题。 VM 在传入数据包中看到以下 IP 地址：- 源 IP 地址：
192.168.100.7 - 目标 IP 地址：
192.168.1.4
- 源 IP 地址：
VM 会回答应用程序请求，这会撤消源 IP 地址和目标 IP 地址。 入站流不需要 UDR，因为源 IP 是 Azure 防火墙 IP 地址。
0.0.0.0/0关系图中的 UDR 用于出站连接，以确保到公共 Internet 的数据包通过 Azure 防火墙。- 源 IP 地址：
192.168.1.4 - 目标 IP 地址：
192.168.100.7
- 源 IP 地址：
Azure 防火墙会撤消 SNAT 和 DNAT作，并向客户端传递响应。
- 源 IP 地址：
AzFwPIP - 目标 IP 地址：
ClientPIP
- 源 IP 地址：
仅限应用程序网关的设计
此设计描述了虚拟网络中仅存在 Web 应用程序的情况，使用 NSG 检查出站流量足以保护发到 Internet 的出站流。
注意
不建议使用此设计，因为使用 Azure 防火墙控制出站流，而不是仅依赖于 NSG，有助于防止数据外泄等攻击方案。 借助 Azure 防火墙，可以帮助确保工作负荷仅将数据发送到批准的 URL 列表。 此外，NSG 仅在第 3 层和第 4 层运行，并且不支持 FQDN。
与以前的仅限 Azure 防火墙的设计的主要区别在于，应用程序网关不能用作具有 NAT 的路由设备。 相反，它充当完整的反向应用程序代理。 此方法意味着应用程序网关停止来自客户端的 Web 会话，并使用其后端服务器之一建立单独的会话。 来自 Internet 的入站 HTTP（S） 连接将发送到应用程序网关的公共 IP 地址，来自 Azure 或本地的连接使用网关的专用 IP 地址。 从 Azure VM 返回流量遵循标准虚拟网络路由回应用程序网关。 有关详细信息，请参阅本文后面的数据包演练。 来自 Azure VM 的出站 Internet 流直接转到 Internet。
下表汇总了流量流。
| 流 | 浏览应用程序网关/Web 应用程序防火墙 | 通过 Azure 防火墙 |
|---|---|---|
| 来自 Internet 或本地到 Azure 的 HTTP（S） 流量 | 是的 | N/A |
| 从 Azure 到 Internet 或本地的 HTTP（S） 流量 | 不 | N/A |
| 来自 Internet 或本地到 Azure 的非 HTTP（S） 流量 | 不 | N/A |
| 从 Azure 到 Internet 或本地的非 HTTP（S） 流量 | 不 | N/A |
建筑
以下数据包演练示例演示客户端如何从公共 Internet 访问 VM 托管的应用程序。
显示仅限应用程序网关设计的 
工作流
客户端启动与应用程序网关的公共 IP 地址的连接。
- 源 IP 地址：
ClientPIP - 目标 IP 地址：
AppGwPIP
- 源 IP 地址：
对应用程序网关公共 IP 地址的请求将分发到网关的后端实例，在此示例中
192.168.200.7。 接收请求的应用程序网关实例会停止来自客户端的连接，并与其中一个后端建立新连接。 后端将应用程序网关实例视为源 IP 地址。 应用程序网关使用原始客户端的 IP 地址插入X-Forwarded-ForHTTP 标头。- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
192.168.200.7 - 目标 IP 地址：
192.168.1.4 -
X-Forwarded-For标头：ClientPIP
- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
VM 会回答应用程序请求，并反转源 IP 地址和目标 IP 地址。 VM 可以访问应用程序网关，因此不需要 UDR。
- 源 IP 地址：
192.168.1.4 - 目标 IP 地址：
192.168.200.7
- 源 IP 地址：
应用程序网关实例回答客户端。
- 源 IP 地址：
AppGwPIP - 目标 IP 地址：
ClientPIP
- 源 IP 地址：
应用程序网关将元数据添加到数据包 HTTP 标头，例如包含原始客户端 IP 地址的 X-Forwarded-For 标头。 某些应用程序服务器需要源客户端 IP 地址来提供特定于地理位置的内容，或用于日志记录。 有关详细信息，请参阅 应用程序网关的工作原理。
在此示例中，
192.168.200.7IP 地址是应用程序网关服务自动部署的实例之一。 它具有内部专用前端 IP 地址192.168.200.4。 这些单个实例通常对 Azure 管理员不可见。 但指出差异可能很有用，例如排查网络问题时。如果客户端通过 VPN 或 ExpressRoute 网关来自本地网络，则流类似。 区别在于客户端访问应用程序网关的专用 IP 地址，而不是公共 IP 地址。
注意
有关 X-Forwarded-For 标头以及如何在请求中保留主机名的详细信息，请参阅 保留原始 HTTP 主机。
Azure 防火墙和应用程序网关并行设计
由于它的简单性和灵活性，最好并行运行应用程序网关和 Azure 防火墙。
如果虚拟网络中同时存在 Web 工作负载和非 Web 工作负载，请实现此设计。 应用程序网关中的 Web 应用程序防火墙有助于保护发到 Web 工作负荷的入站流量。 Azure 防火墙检查其他应用程序的入站流量。 Azure 防火墙涵盖两种工作负荷类型的出站流。
应将来自 Internet 的入站 HTTP（S） 连接发送到应用程序网关的公共 IP 地址。 应将来自 Azure 或本地的 HTTP（S） 连接发送到其专用 IP 地址。 标准虚拟网络路由将数据包从应用程序网关发送到目标 VM，以及从目标 VM 发回应用程序网关。 有关详细信息，请参阅本文后面的数据包演练。
对于入站非 HTTP（S） 连接，如果流量来自公共 Internet，流量应面向 Azure 防火墙的公共 IP 地址。 如果流量来自其他 Azure 虚拟网络或本地网络，则应通过 UDR 通过 Azure 防火墙发送。 来自 Azure VM 的所有出站流都由 UDR 转发到 Azure 防火墙。
下表汇总了此方案的流量流。
| 流 | 浏览应用程序网关/Web 应用程序防火墙 | 通过 Azure 防火墙 |
|---|---|---|
| 来自 Internet 或本地到 Azure 的 HTTP（S） 流量 | 是的 | 不 |
| 从 Azure 到 Internet 或本地的 HTTP（S） 流量 | 不 | 是的 |
| 来自 Internet 或本地到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet 或本地的非 HTTP（S） 流量 | 不 | 是的 |
此设计提供比仅使用 NSG 更精细的出口筛选。 例如，如果应用程序需要连接到特定的 Azure 存储帐户，则可以使用基于 FQDN 的筛选器。 使用基于 FQDN 的筛选器，应用程序不会将数据发送到恶意存储帐户。 如果仅使用 NSG，则无法阻止此方案。 当出站流量需要基于 FQDN 的筛选时，通常使用此设计。 一种情况是 限制 AKS 群集的出口流量。
架构
下图演示了来自外部客户端的入站 HTTP（S） 连接的流量流。
下图演示了从网络 VM 到 Internet 的出站连接的流量流。 一个示例是连接到后端系统或获取作系统更新。
每个服务的数据包流步骤与前面的独立设计选项中的步骤相同。
Azure 防火墙设计前的应用程序网关
使用 Azure 防火墙和应用程序网关的 Web 应用程序的零信任网络，更详细地解释了此设计。 本文重点介绍与其他设计选项的比较。 在此拓扑中，入站 Web 流量通过 Azure 防火墙和 Web 应用程序防火墙。 Web 应用程序防火墙在 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） 连接，如果流量来自公共 Internet，流量应面向 Azure 防火墙的公共 IP 地址。 如果流量来自其他 Azure 虚拟网络或本地网络，则应通过 UDR 通过 Azure 防火墙发送。 来自 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 签名应用于流量。 可以在 Azure 防火墙 IDPS 规则中找到有关 IDPS 的 Azure 防火墙 IDPS 规则指示和专用 IP 前缀的详细信息。
下表汇总了此方案的流量流。
| 流 | 浏览应用程序网关/Web 应用程序防火墙 | 通过 Azure 防火墙 |
|---|---|---|
| 来自 Internet 或本地到 Azure 的 HTTP（S） 流量 | 是的 | 是的 |
| 从 Azure 到 Internet 或本地的 HTTP（S） 流量 | 不 | 是的 |
| 来自 Internet 或本地到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet 或本地的非 HTTP（S） 流量 | 不 | 是的 |
对于从本地或从 Internet 到 Azure 的 Web 流量，Azure 防火墙会检查 Web 应用程序防火墙允许的流。 根据应用程序网关是否加密后端流量，即从应用程序网关发往应用程序服务器的流量，可能会发生不同的情况：
应用程序网关遵循零信任原则（如 端到端 TLS 加密）加密流量，Azure 防火墙接收加密的流量。 Azure 防火墙标准版仍可使用 TLS 服务器名称指示（SNI）标头应用检查规则，例如网络规则中的第 3 层和第 4 层筛选，或者在应用程序规则中应用 FQDN 筛选。 Azure 防火墙高级版 通过 TLS 检查（例如基于 URL 的筛选）提供更深入的可见性。
如果应用程序网关向应用程序服务器发送未加密的流量，Azure 防火墙会以明文形式看到入站流量。 Azure 防火墙中不需要 TLS 检查。
如果在 Azure 防火墙中启用了 IDPS，它将验证 HTTP 主机标头是否与目标 IP 地址匹配。 若要执行此验证，它需要主机标头中指定的 FQDN 的名称解析。 可以使用 Azure DNS 专用区域和默认 Azure 防火墙 DNS 设置来执行此名称解析。 也可以使用需要在 Azure 防火墙设置中配置的自定义 DNS 服务器来实现此目的。 如果对部署 Azure 防火墙的虚拟网络没有管理访问权限，则后一种方法是唯一的选择。 一个示例是部署在 Azure 虚拟 WAN 保护的中心中的 Azure 防火墙实例。
建筑
对于其余流（包括入站非 HTTP（S）流量和任何出站流量，Azure 防火墙提供 IDPS 检查和 TLS 检查（如果适用）。 它还在基于 DNS 的网络规则中提供基于 FQDN 的筛选
在 Azure 防火墙设计前显示应用程序网关的 
工作流
来自公共 Internet 的网络流量遵循以：
客户端启动与应用程序网关的公共 IP 地址的连接。
- 源 IP 地址：
ClientPIP - 目标 IP 地址：
AppGwPIP
- 源 IP 地址：
对应用程序网关公共 IP 地址的请求将分发到网关的后端实例，在此示例中
192.168.200.7。 应用程序网关实例停止来自客户端的连接，并建立与其中一个后端的新连接。 应用程序网关子网中要192.168.1.0/24的 UDR 将数据包转发到 Azure 防火墙，并将目标 IP 地址保留到 Web 应用程序。- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
192.168.200.7 - 目标 IP 地址：
192.168.1.4 -
X-Forwarded-For标头：ClientPIP
- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
Azure 防火墙不会将 SNAT 应用到流量，因为流量将流向专用 IP 地址。 如果规则允许，它会将流量转发到应用程序 VM。 有关详细信息，请参阅 Azure 防火墙 SNAT 专用 IP 地址范围。 但是，如果流量在防火墙中命中应用程序规则，则工作负荷将看到处理数据包的特定防火墙实例的源 IP 地址，因为 Azure 防火墙代理连接。
- 如果 Azure 防火墙网络规则允许流量，并且是其中一个应用程序网关实例的专用 IP 地址，则源 IP 地址：
192.168.200.7 - 如果 Azure 防火墙应用程序规则允许流量，并且是其中一个 Azure 防火墙实例的专用 IP 地址，则源 IP 地址：
192.168.100.7 - 目标 IP 地址：
192.168.1.4 -
X-Forwarded-For标头：ClientPIP
- 如果 Azure 防火墙网络规则允许流量，并且是其中一个应用程序网关实例的专用 IP 地址，则源 IP 地址：
VM 会回答请求，这会撤消源 IP 地址和目标 IP 地址。 要
192.168.200.0/24UDR 捕获发回应用程序网关的数据包，将其重定向到 Azure 防火墙，并将目标 IP 地址保留到应用程序网关。- 源 IP 地址：
192.168.1.4 - 目标 IP 地址：
192.168.200.7
- 源 IP 地址：
同样，Azure 防火墙不会将 SNAT 应用到流量，因为它会转到专用 IP 地址并将流量转发到应用程序网关。
- 源 IP 地址：
192.168.1.4 - 目标 IP 地址：
192.168.200.7
- 源 IP 地址：
应用程序网关实例回答客户端。
- 源 IP 地址：
AppGwPIP - 目标 IP 地址：
ClientPIP
- 源 IP 地址：
从 VM 到公共 Internet 的出站流通过 Azure 防火墙，UDR 将定义 0.0.0.0/0。
作为此设计的变体，可以在 Azure 防火墙中配置专用 DNAT，以便应用程序工作负荷将 Azure 防火墙实例的 IP 地址视为源，无需使用 UDR。 应用程序客户端的源 IP 地址已保留在应用程序网关 X-Forwarded-For HTTP 标头中。 因此，如果 Azure 防火墙将 DNAT 应用于流量，则不会丢失任何信息。 有关详细信息，请参阅 使用 Azure 门户通过 Azure 防火墙策略 DNAT 筛选入站 Internet 或 Intranet 流量。
应用程序网关设计前的 Azure 防火墙
此设计允许 Azure 防火墙在到达应用程序网关之前筛选和丢弃恶意流量。 例如，它可以应用基于威胁情报的筛选等功能。 另一个好处是，无论协议如何，应用程序都会为入站和出站流量获取相同的公共 IP 地址。 有三种模式可以理论上配置 Azure 防火墙：
具有 DNAT 规则的 Azure 防火墙： Azure 防火墙仅交换 IP 地址层上的 IP 地址，但它不会处理有效负载。 因此，它不会更改任何 HTTP 标头。
禁用了应用程序规则和 TLS 检查的 Azure 防火墙： Azure 防火墙可以查看 TLS 中的 SNI 标头，但不会对其进行解密。 从防火墙创建到下一跃点的新 TCP 连接。 在此示例中，它是应用程序网关。
启用了应用程序规则和 TLS 检查的 Azure 防火墙： Azure 防火墙会调查数据包内容并解密它们。 它充当 HTTP 代理，并且可以将 HTTP 标头设置为
X-Forwarded-For以保留 IP 地址。 但是，它将自生成证书呈现给客户端。 对于基于 Internet 的应用程序，使用自生成的证书不是一个选项，因为从其浏览器将安全警告发送到应用程序客户端。
在前两个选项（这是基于 Internet 的应用程序的唯一有效选项）中，Azure 防火墙将 SNAT 应用于传入的流量，而无需设置 X-Forwarded-For 标头。 因此，应用程序看不到 HTTP 请求的原始 IP 地址。 对于管理任务（例如故障排除），可以通过将其与 Azure 防火墙的 SNAT 日志相关联来获取特定连接的实际客户端 IP 地址。
此方案的好处是有限的，因为除非使用 TLS 检查并将自生成的证书呈现给客户端，否则 Azure 防火墙只会看到发送到应用程序网关的加密流量。 此方案通常仅适用于内部应用程序。 但是，在某些情况下，此设计是首选的。 一种情况是，如果网络前面存在另一个 Web 应用程序防火墙（例如，使用 Azure Front Door），它可以捕获 X-Forwarded-For HTTP 标头中的原始源 IP。 如果许多公共 IP 地址是必需的，则你可能更喜欢此设计，因为应用程序网关支持单个 IP 地址。
来自公共 Internet 的 HTTP（S） 入站流应面向 Azure 防火墙的公共 IP 地址。 Azure 防火墙将 DNAT 和 SNAT 数据包传送到应用程序网关的专用 IP 地址。 从其他 Azure 虚拟网络或本地网络，HTTP（S） 流量应发送到应用程序网关专用 IP 地址，并使用 UDR 通过 Azure 防火墙转发。 标准虚拟网络路由可确保使用 DNAT 规则时，从 Azure VM 返回流量返回到应用程序网关和从应用程序网关发往 Azure 防火墙。 对于来自本地或 Azure 的流量，请使用应用程序网关子网中的 UDR。 有关详细信息，请参阅本文后面的数据包演练。 从 Azure VM 发往 Internet 的所有出站流量都通过 UDR 通过 Azure 防火墙发送。
下表汇总了此方案的流量流。
| 流 | 浏览应用程序网关/Web 应用程序防火墙 | 通过 Azure 防火墙 |
|---|---|---|
| 来自 Internet 或本地到 Azure 的 HTTP（S） 流量 | 是的 | 是的 |
| 从 Azure 到 Internet 或本地的 HTTP（S） 流量 | 不 | 是的 |
| 来自 Internet 或本地到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 从 Azure 到 Internet 或本地的非 HTTP（S） 流量 | 不 | 是的 |
对于入站 HTTP（S） 流量，Azure 防火墙通常不会解密流量。 而是应用不需要 TLS 检查的 IDPS 策略，例如基于 IP 地址的筛选或使用 HTTP 标头。
建筑
应用程序看不到 Web 流量的原始源 IP 地址。 Azure 防火墙在数据包传入虚拟网络时将 SNAT 应用到数据包。 若要避免此问题，请使用防火墙前 Azure Front Door。 Azure Front Door 在进入 Azure 虚拟网络之前，将客户端的 IP 地址作为 HTTP 标头注入。
显示 Azure 防火墙后的应用程序网关的 
工作流
来自公共 Internet 的网络流量遵循以：
客户端启动与 Azure 防火墙的公共 IP 地址的连接。
- 源 IP 地址：
ClientPIP - 目标 IP 地址：
AzFWPIP
- 源 IP 地址：
对 Azure 防火墙公共 IP 地址的请求将分发到防火墙的后端实例，在此示例中
192.168.100.7。 Azure 防火墙将 DNAT 应用到 Web 端口（通常为 TCP 443）到应用程序网关实例的专用 IP 地址。 执行 DNAT 时，Azure 防火墙也会应用 SNAT。 有关详细信息，请参阅 Azure 防火墙已知问题。- 源 IP 地址，这是 Azure 防火墙实例的专用 IP 地址：
192.168.100.7 - 目标 IP 地址：
192.168.200.4
- 源 IP 地址，这是 Azure 防火墙实例的专用 IP 地址：
应用程序网关在处理连接和后端服务器之一的实例之间建立新会话。 客户端的原始 IP 地址不在数据包中。
- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
192.168.200.7 - 目标 IP 地址：
192.168.1.4 -
X-Forwarded-For标头：192.168.100.7
- 源 IP 地址，这是应用程序网关实例的专用 IP 地址：
VM 会回答应用程序网关，这会反转源 IP 地址和目标 IP 地址：
- 源 IP 地址：
192.168.1.4 - 目标 IP 地址：
192.168.200.7
- 源 IP 地址：
应用程序网关回复 Azure 防火墙实例的 SNAT 源 IP 地址。 Azure 防火墙将应用程序网关的内部 IP 地址（
.4）视为源 IP 地址，即使连接来自特定应用程序网关实例（如.7）。- 源 IP 地址：
192.168.200.4 - 目标 IP 地址：
192.168.100.7
- 源 IP 地址：
Azure 防火墙撤消 SNAT 和 DNAT 并回答客户端。
- 源 IP 地址：
AzFwPIP - 目标 IP 地址：
ClientPIP
- 源 IP 地址：
应用程序网关需要公共 IP 地址，以便Microsoft可以管理它，即使它没有为应用程序配置侦听器也是如此。
注意
不支持在指向 Azure 防火墙的应用程序网关子网中 0.0.0.0/0 的默认路由，因为它会中断应用程序网关正常运行所需的控制平面流量。
本地客户端
上述设计都显示来自公共 Internet 的传入应用程序客户端。 本地网络也访问应用程序。 以前的大多数信息和流量流与 Internet 客户端相同，但存在一些显著差异：
VPN 网关或 ExpressRoute 网关位于 Azure 防火墙或应用程序网关前面。
Web 应用程序防火墙使用应用程序网关的专用 IP 地址。
Azure 防火墙不支持专用 IP 地址的 DNAT，因此必须使用 UDR 从 VPN 或 ExpressRoute 网关将入站流量发送到 Azure 防火墙。
请务必验证 强制隧道应用程序网关 以及 Azure 防火墙的注意事项。 即使工作负荷不需要到公共 Internet 的出站连接，也不能为指向本地网络的应用程序网关注入默认路由（如
0.0.0.0/0，因为它会中断控制流量）。 对于应用程序网关，默认路由需要指向公共 Internet。
建筑
下图显示了应用程序网关和 Azure 防火墙并行设计。 应用程序客户端来自通过 VPN 或 ExpressRoute 连接到 Azure 的本地网络：
即使所有客户端都位于本地或 Azure 中，应用程序网关和 Azure 防火墙也需要有公共 IP 地址。 这些公共 IP 地址允许Microsoft管理服务。
中心和辐射拓扑
本文中的设计适用于 中心辐射型 拓扑。 中心虚拟网络中的共享资源通过虚拟网络对等互连连接到独立辐射虚拟网络中的应用程序。
建筑
考虑
此拓扑的一些注意事项包括：
Azure 防火墙部署在中心中心虚拟网络中。 上图显示了如何在中心部署应用程序网关。 应用程序团队通常管理应用程序网关或 API 管理网关等组件。 在此方案中，这些组件部署在辐射虚拟网络中。
特别注意辐射网络中的 UDR。 当分支中的应用程序服务器接收来自特定 Azure 防火墙实例的流量（如前面的示例中的
192.168.100.7IP 地址）时，它应将返回流量发回同一实例。 如果辐射中的 UDR 将发往中心的下一跃点流量设置为 Azure 防火墙 IP 地址（上图中的192.168.100.4），则返回数据包可能最终位于不同的 Azure 防火墙实例上。 这种情况会导致非对称路由。 如果辐射虚拟网络中有 UDR，请确保通过 Azure 防火墙将流量发送到中心内的共享服务。 这些 UDR 不包括 Azure 防火墙子网的前缀。前面的建议同样适用于应用程序网关子网以及可能在中心虚拟网络中部署的任何其他 NVA 或反向代理。
不能通过具有下一跃点类型的
Virtual Network的静态路由为应用程序网关或 Azure 防火墙子网设置下一跃点。 此下一跃点类型仅在本地虚拟网络中有效，不能跨虚拟网络对等互连。 有关 UDR 和下一跃点类型的详细信息，请参阅 虚拟网络流量路由。
非对称路由
下图显示了分支如何将 SNAT 流量发送回 Azure 防火墙的 Azure 负载均衡器。 此设置会导致非对称路由。
若要解决此问题，请在辐射中定义没有 Azure 防火墙子网的 UDR，并且只定义共享服务的子网。 在上图中，辐射中正确的 UDR 应仅包含 192.168.1.0/24。 它不应包含整个区域 192.168.0.0/16，该范围用红色标记。
与其他 Azure 产品的集成
可以将 Azure 防火墙和应用程序网关与其他 Azure 产品和服务集成。
API 管理网关
将反向代理服务（如 API 管理 网关）集成到以前的设计中，以提供 API 限制或身份验证代理等功能。 API 管理网关集成不会显著影响设计。 主要区别在于，没有单一应用程序网关反向代理，而是相互链接的两个反向代理。
有关详细信息，请参阅 设计指南，以将 API 管理和应用程序网关集成到虚拟网络 中，以及用于微服务 的应用程序模式API 网关。
AKS
对于在 AKS 群集上运行的工作负荷，可以独立于群集部署应用程序网关。 或者，可以使用 应用程序网关入口控制器将其与 AKS 群集集成。 在 Kubernetes 级别（如服务和入口）上配置特定对象时，应用程序网关会自动调整，而无需额外的手动步骤。
Azure 防火墙在 AKS 群集安全性中起着重要作用。 它提供所需的功能来基于 FQDN 筛选 AKS 群集的出口流量，而不仅仅是 IP 地址。 有关详细信息，请参阅 在 AKS中使用 Azure 防火墙限制网络流量。
将应用程序网关和 Azure 防火墙组合在一起以保护 AKS 群集时，最好使用并行设计选项。 使用 Web 应用程序防火墙的应用程序网关处理群集中 Web 应用程序的入站连接请求。 Azure 防火墙仅允许显式允许的出站连接。 有关并行设计选项的详细信息，请参阅 AKS 群集 基线体系结构。
Azure Front Door
Azure Front Door 具有与多个区域中的应用程序网关重叠的功能。 这两种服务都提供 Web 应用程序防火墙、SSL 卸载和基于 URL 的路由。 但是，一个关键区别在于，虽然应用程序网关在虚拟网络中运行，但 Azure Front Door 是一项全球分散式服务。
有时可以通过将应用程序网关替换为分散式 Azure Front Door 来简化虚拟网络设计。 本文中所述的大多数设计仍适用，但将 Azure 防火墙放置在 Azure Front Door 前面的选项除外。
一种方案是在虚拟网络中的应用程序网关前使用 Azure 防火墙。 应用程序网关将 X-Forwarded-For 标头注入防火墙实例的 IP 地址，而不是客户端的 IP 地址。 解决方法是在防火墙前使用 Azure Front Door 将客户端的 IP 地址作为 X-Forwarded-For 标头注入，然后流量进入虚拟网络并到达 Azure 防火墙。 还可以 使用 Azure Front Door Premium中的 Azure 专用链接保护源。
有关两个服务之间的差异或何时使用每个服务的详细信息，请参阅 Azure Front Door 的常见问题。
其他 NVA
Microsoft产品并不是在 Azure 中实现 Web 应用程序防火墙或下一代防火墙功能的唯一选择。 各种Microsoft合作伙伴都提供 NVA。 概念和设计实质上与本文相同，但有一些重要的注意事项：
用于下一代防火墙的合作伙伴 NVA 可以为 Azure 防火墙不支持的 NAT 配置提供更多控制和灵活性。 示例包括来自本地的 DNAT 或来自 Internet 的 DNAT（没有 SNAT）。
与用户需要跨多个设备处理可伸缩性和复原能力的 NVA 相比，应用程序网关和 Azure 防火墙等 Azure 托管 NVA 降低了复杂性。
在 Azure 中使用 NVA 时，请使用 主动-主动 和 自动缩放 设置，这样这些设备就不是虚拟网络中运行的应用程序的瓶颈。
贡献
Microsoft维护本文。 以下参与者撰写了本文。
主体作者：
- 何塞·雷诺 |首席客户工程师
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。
后续步骤
详细了解组件技术：
相关资源
探索相关的体系结构：
- 实现安全的混合网络
- 安全管理的 Web 应用程序
- 在 Azure 上 多租户软件即服务
- 使用应用服务环境 企业部署
- 使用应用服务环境 高可用性企业部署