应用程序网关基础结构配置
Azure 应用程序网关基础结构包括虚拟网络、子网、网络安全组 (NSG) 和用户定义路由 (UDR)。
虚拟网络和专用子网
应用程序网关是虚拟网络中的专用部署。 需要在虚拟网络中为应用程序网关配置一个专用子网。 在子网中，可以具有给定应用程序网关部署的多个实例。 还可以在该子网中部署其他应用程序网关。 但不能在应用程序网关子网中部署其他任何资源。 不能在同一子网上混合 v1 和 v2 应用程序网关 SKU。
注意
应用程序网关子网中当前不支持虚拟网络服务终结点策略。
子网的大小
应用程序网关对每个实例使用一个专用 IP 地址，如果配置了专用前端 IP，则另外还使用一个专用 IP 地址。
Azure 还会在每个子网中保留 5 个 IP 地址供内部使用。 它们是前四个地址和最后一个 IP 地址。 例如，假设有 15 个应用程序网关实例没有专用前端 IP。 至少需要为此子网提供 20 个 IP 地址。 需要 5 个 IP 地址供内部使用，15 个 IP 地址用于应用程序网关实例。
假设某个子网包含 27 个应用程序网关实例，以及一个用作专用前端 IP 的 IP 地址。 在这种情况下，需要 33 个 IP 地址。 需要 27 个 IP 地址用于应用程序网关实例，1 个 IP 地址用于专用前端，5 个 IP 地址供内部使用。
应用程序网关（标准或 WAF_v2 SKU）最多可支持 32 个实例（32 个实例 IP 地址 + 1 个专用前端 IP + 5 个预留的 Azure）。 建议最小子网大小为 /26。
应用程序网关（Standard_v2 或 WAF_v2 SKU）最多可支持 125 个实例（已预留 125 个实例 IP 地址 + 1 个专用前端 IP 配置 + 5 个 Azure IP 地址）。 建议最小子网大小为 /24。
若要确定预配了现有应用程序网关的子网的可用容量，请获取子网的大小，并减去平台保留的子网的五个保留 IP 地址。 接下来，获取每个网关并减去最大实例计数。 对于每个具有专用前端 IP 配置的网关，请再减去每个网关的一个 IP 地址。
例如，下面介绍如何计算具有三个不同大小的网关的子网的可用地址：
- 网关 1：最多 10 个实例。 使用专用前端 IP 配置。
- 网关 2：最多 2 个实例。 无专用前端 IP 配置。
- 网关 3：最多 15 个实例。 使用专用前端 IP 配置。
- 子网大小：/24
- 子网大小 /24 = 256 个 IP 地址 - 从平台保留的 5 个可用地址 = 251 个可用地址
- 251：网关 1 （10） - 1 个专用前端 IP 配置 = 240
- 240：网关 2 （2） = 238
- 238：网关 3 (15) - 1 个专用前端 IP 配置 = 222
重要
尽管不需要每个应用程序网关 v2 SKU 部署中都有 /24 子网，但强烈建议使用此大小。 /24 子网是为了确保应用程序网关 v2 有足够的空间用于自动缩放扩展和维护升级。
应确保应用程序网关 v2 子网有足够的地址空间来容纳处理最大预期流量所需的实例数。 如果指定最大实例计数，子网的容量应该至少可以容纳这么多的地址。 有关实例计数的容量计划，请参阅实例计数详细信息。
名为 GatewaySubnet 的子网是为 VPN 网关保留的。 使用 GatewaySubnet 子网的应用程序网关 V1 资源需要在 2023 年 9 月 30 日之前移动到其他子网或迁移到 V2 SKU，以避免控制平面故障和平台不一致。 有关更改现有应用程序网关实例的子网的信息，请参阅有关应用程序网关的常见问题解答。
提示
IP 地址从网关实例的已定义子网空间的开头分配。 由于创建网关或缩放事件而创建和删除实例，因此很难理解子网中下一个可用地址是什么。 为了能够确定用于未来网关的下一个地址，以及拥有针对前端 IP 的连续寻址方案，请考虑从定义的子集空间的上半部分分配前端 IP 地址。
例如，如果子网地址空间为 10.5.5.0/24，请考虑从 10.5.5.254 开始设置网关的专用前端 IP 配置，然后针对未来的网关设置 10.5.5.253、10.5.5.252、10.5.5.251 等。
可以更改同一虚拟网络中现有应用程序网关的子网实例。 若要进行此更改，请使用 Azure PowerShell 或 Azure CLI。 有关详细信息，请参阅有关应用程序网关的常见问题解答。
用于名称解析的 DNS 服务器
虚拟网络资源支持 DNS 服务器配置，允许在 Azure 提供的默认 DNS 服务器或自定义 DNS 服务器之间进行选择。 应用程序网关的实例也按照此 DNS 配置进行任何名称解析。 更改此设置后，必须重启（停止和启动）应用程序网关，以使这些更改在实例上生效。
注意
如果在应用程序网关虚拟网络中使用自定义 DNS 服务器，则 DNS 服务器必须能够解析公共 Internet 名称。 应用程序网关需要此功能。
虚拟网络权限
应用程序网关资源部署在虚拟网络中，因此我们还会进行检查，以验证对提供的虚拟网络资源的权限。 此项验证在执行创建和管理操作期间执行。
检查 Azure 基于角色的访问控制，以验证操作应用程序网关的用户（和服务主体）是否还在虚拟网络或子网上至少拥有 Microsoft.Network/virtualNetworks/subnets/join/action 权限。
可以使用已经支持此权限的内置角色，例如网络参与者。 如果内置角色不提供正确的权限，你可以创建和分配自定义角色。 详细了解如何管理子网权限。
注意
在角色分配发生更改后，可能需要留出足够的时间进行 Azure 资源管理器缓存刷新。
识别订阅受影响的用户或服务主体
通过访问帐户的 Azure 顾问，可以验证订阅中是否存在权限不足的任何用户或服务主体。 该项建议的详细信息如下：
标题：更新应用程序网关用户的 VNet 权限
类别：可靠性
影响：高
使用临时 Azure 功能公开控制 (AFEC) 标志
我们引入了订阅级 Azure 功能公开控制 (AFEC)，作为临时扩展。 可以注册 AFEC 并使用它，直到修复所有用户和服务主体的权限。 按照与 Azure 订阅的预览功能注册相同的步骤注册功能。
名称：Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
说明：禁用应用程序网关子网权限检查
ProviderNamespace：Microsoft.Network
EnrollmentType：AutoApprove
注意
建议在分配正确的权限之前，仅将 AFEC 预配用作临时缓解措施。 必须优先修复所有适用的用户（和服务主体）的权限，然后取消注册此 AFEC 标志，以重新引入对虚拟网络资源的权限验证。 建议不要永久依赖于此 AFEC 方法，因为它将来会被移除。
Azure Virtual Network Manager
Azure Virtual Network Manager 是一项管理服务，可用于跨订阅对虚拟网络进行全局分组、配置、部署和管理。 使用 Virtual Network Manager，可以定义网络组来对虚拟网络进行标识和逻辑分段。 之后，可以确定所需的连接和安全配置，并且一次将它们应用于网络组中的所有选定虚拟网络。
Azure Virtual Network Manager 中的安全管理员规则配置可以大规模定义安全策略，并一次将其应用到多个虚拟网络。
注意
Azure Virtual Network Manager 的安全管理员规则仅适用于包含已启用网络隔离的应用程序网关的应用程序网关子网。 禁用网络隔离的应用程序网关的子网没有安全管理员规则。
网络安全组
可以将 NSG 用于应用程序网关子网，但请注意一些关键点和限制。
必需的安全规则
要将 NSG 与应用程序网关配合使用，需要创建或保留一些基本安全规则。 可以按相同的顺序设置其优先级。
入站规则
客户端流量 - 允许来自预期客户端（作为源 IP 或 IP 范围）的传入流量，以及作为应用程序网关的整个子网 IP 前缀和入站访问端口的目标流量。 例如，如果为端口 80 和 443 配置了侦听器，则必须允许使用这些端口。 还可以将此规则设置为 Any。
| 源 | 源端口 | 目标 | 目标端口 | 协议 | 访问 |
|---|---|---|---|---|---|
<as per need> |
任意 | <Subnet IP Prefix> |
<listener ports> |
TCP | 允许 |
通过同一端口号（使用规则）配置活动的公共和专用侦听器后，应用程序网关会将所有入站流的“目标”更改为网关的前端 IP。 即使对于不共享任何端口的侦听器，也会发生此更改。 因此，在使用相同的端口配置时，必须在入站规则的“目标”中包含网关的前端公共和专用 IP 地址。
| Source | 源端口 | 目标 | 目标端口 | 协议 | 访问 |
|---|---|---|---|---|---|
<as per need> |
任意 | <Public and Private<br/>frontend IPs> |
<listener ports> |
TCP | 允许 |
基础结构端口：允许来自作为 GatewayManager 服务标记和任何目标的源的传入请求。 目标端口范围因 SKU 而异，并且是传达后端运行状况状态所必需的。 这些端口受 Azure 证书的保护/锁定。 如果没有适当的证书，外部实体将无法对这些终结点启动更改。
- V2：端口 65200-65535
- V1：端口 65503-65534
| 源 | 源端口 | 目标 | 目标端口 | 协议 | 访问 |
|---|---|---|---|---|---|
| GatewayManager | 任意 | 任意 | <as per SKU given above> |
TCP | Allow |
Azure 负载均衡器探测：允许来自作为 AzureLoadBalancer 服务标记的源的传入流量。 此规则默认为 NSG 创建。 不得使用手动拒绝规则替代它，以确保顺利操作应用程序网关。
| Source | 源端口 | 目标 | 目标端口 | 协议 | 访问 |
|---|---|---|---|---|---|
| AzureLoadBalancer | 任意 | 任意 | 任意 | 任意 | 允许 |
可以使用“全部拒绝”规则阻止其他所有传入流量。
出站规则
Internet 出站：允许所有目标的 Internet 出站流量。 此规则默认为 NSG 创建。 不得使用手动拒绝规则替代它，以确保顺利操作应用程序网关。 不得创建拒绝任何出站连接的出站 NSG 规则。
| 源 | 源端口 | 目标 | 目标端口 | 协议 | 访问 |
|---|---|---|---|---|---|
| 任意 | 任意 | Internet | 任意 | 任意 | 允许 |
注意
当禁用了“允许发往远程虚拟网络的流量”时，未启用网络隔离的应用程序网关不允许在对等互连的 VNet 之间发送流量。
支持的用户定义路由
公共预览版中可以通过路由表规则对应用程序网关子网进行精细控制。
对于当前功能，存在一些限制：
重要
在应用程序网关子网中使用 UDR 可能会导致后端运行状况视图中的运行状态显示为“未知”。 此外，可能还会导致应用程序网关日志和指标生成失败。 建议不要在应用程序网关子网中使用 UDR，以便能够查看后端运行状况、日志和指标。
v1：使用 v1 SKU 时，如果 UDR 未更改端到端请求/响应通信，应用程序网关子网就会支持这些 UDR。 例如，可以在应用程序网关子网中设置一个指向防火墙设备的、用于检查数据包的 UDR。 但是，必须确保数据包在检查后可以访问其预期目标。 否则，可能会导致不正确的运行状况探测或流量路由行为。 也包括已探测到的路由，或者通过 Azure ExpressRoute 或 VPN 网关在虚拟网络中传播的默认 0.0.0.0/0 路由。
v2：v2 SKU 存在支持和不支持的方案。
v2 支持的方案
警告
错误配置路由表可能会导致应用程序网关 v2 中出现非对称路由。 确保所有管理/控制平面流量直接发送到 Internet，且不通过虚拟设备发送。 日志记录、指标和 CRL 检查也可能受到影响。
方案 1：使用 UDR 禁用向应用程序网关子网进行边界网关协议 (BGP) 路由传播
有时，默认网关路由 (0.0.0.0/0) 会通过与应用程序网关虚拟网络关联的 ExpressRoute 或 VPN 网关进行播发。 此行为会中断管理平面流量，这需要 Internet 的直接路径。 在这种情况下，可以使用 UDR 来禁用 BGP 路由传播。
若要禁用 BGP 路由传播：
- 在 Azure 中创建路由表资源。
- 禁用“虚拟网络网关路由传播”参数。
- 将路由表关联到相应的子网。
为此方案启用 UDR 不应会破坏任何现有设置。
方案 2：使用 UDR 将 0.0.0.0/0 定向到 Internet
可以创建一个 UDR，用于将 0.0.0.0/0 流量直接发送到 Internet。
方案 3：对 kubenet 中的 Azure Kubernetes 服务 (AKS) 使用 UDR
如果使用包含 AKS 和应用程序网关入口控制器的 kubenet，则需要路由表，以允许将从应用程序网关发送到 pod 的流量路由到正确的节点。 如果使用 Azure 容器网络接口，则无需使用路由表。
若要使用路由表以使 kubenet 能够正常工作：
转到 AKS 创建的资源组。 资源组的名称应以
MC_开头。在该资源组中查找 AKS 创建的路由表。 路由表中应填充以下信息：
- 地址前缀应是要在 AKS 中访问的 pod 的 IP 范围。
- 下一个跃点的类型应是虚拟设备。
- 下一跃点地址应是托管 pod 的节点的 IP 地址。
将此路由表关联到应用程序网关子网。
v2 不支持的方案
方案 1：虚拟设备的 UDR
V2 不支持需要通过任何虚拟设备、中心/辐射虚拟网络或者在本地（强制隧道）重定向 0.0.0.0/0 的任何方案。