应用程序网关基础结构配置Application Gateway infrastructure configuration

应用程序网关基础结构包括虚拟网络、子网、网络安全组和用户定义路由。The application gateway infrastructure includes the virtual network, subnets, network security groups, and user defined routes.

虚拟网络和专用子网Virtual network and dedicated subnet

应用程序网关是虚拟网络中的专用部署。An application gateway is a dedicated deployment in your virtual network. 需要在虚拟网络中为应用程序网关配置一个专用子网。Within your virtual network, a dedicated subnet is required for the application gateway. 在子网中,可以创建给定应用程序网关部署的多个实例。You can have multiple instances of a given application gateway deployment in a subnet. 还可以在该子网中部署其他应用程序网关。You can also deploy other application gateways in the subnet. 但不能在应用程序网关子网中部署其他任何资源。But you can't deploy any other resource in the application gateway subnet. 不能在同一子网中混合使用 Standard_v2 和 Standard Azure 应用程序网关。You can't mix Standard_v2 and Standard Azure Application Gateway on the same subnet.

备注

应用程序网关子网中当前不支持虚拟网络服务终结点策略Virtual network service endpoint policies are currently not supported in an Application Gateway subnet.

子网的大小Size of the subnet

如果配置了专用前端 IP,则应用程序网关将使用每个实例的 1 个专用 IP 地址,以及另一个专用 IP 地址。Application Gateway uses one private IP address per instance, plus another private IP address if a private front-end IP is configured.

另外,Azure 会在每个子网中保留 5 个 IP 地址供内部使用:前 4 个 IP 地址和最后一个 IP 地址。Azure also reserves five IP addresses in each subnet for internal use: the first four and the last IP addresses. 例如,假设有 15 个应用程序网关实例没有专用前端 IP。For example, consider 15 application gateway instances with no private front-end IP. 至少需要为此子网提供 20 个 IP 地址:5 个 IP 地址供内部使用,15 个 IP 地址供应用程序网关实例使用。You need at least 20 IP addresses for this subnet: five for internal use and 15 for the application gateway instances.

假设某个子网包含 27 个应用程序网关实例,并且包含一个用作专用前端 IP 的 IP 地址。Consider a subnet that has 27 application gateway instances and an IP address for a private front-end IP. 在这种情况下,需要 33 个 IP 地址:27 个 IP 地址用于应用程序网关实例,1 个 IP 地址用于专用前端,5 个 IP 地址供内部使用。In this case, you need 33 IP addresses: 27 for the application gateway instances, one for the private front end, and five for internal use.

应用程序网关(标准或 WAF)SKU 最多可支持 32 个实例(已预留 32 个实例 IP 地址 + 1 个专用前端 IP + 5 个 Azure)- 因此建议使用的最小子网大小为 /26Application Gateway (Standard or WAF) SKU can support up to 32 instances (32 instance IP addresses + 1 private front-end IP + 5 Azure reserved) - so a minimum subnet size of /26 is recommended

应用程序网关(Standard_v2 或 WAF_v2 SKU)最多可支持 125 个实例(已预留 125 个实例 IP 地址 + 1 个专用前端 IP + 5 个 Azure)- 因此建议使用的最小子网大小为 /24Application Gateway (Standard_v2 or WAF_v2 SKU) can support up to 125 instances (125 instance IP addresses + 1 private front-end IP + 5 Azure reserved) - so a minimum subnet size of /24 is recommended

网络安全组Network security groups

应用程序网关支持网络安全组 (NSG)。Network security groups (NSGs) are supported on Application Gateway. 但是,存在一些限制:But there are some restrictions:

  • 对于应用程序网关 v1 SKU,必须允许 TCP 端口 65503-65534 上的传入 Internet 流量,对于目标子网为 Any 且源为 GatewayManager 服务标记的 v2 SKU,必须允许 TCP 端口 65200-65535 上的传入 Internet 流量。You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as Any and source as GatewayManager service tag. 此端口范围是进行 Azure 基础结构通信所必需的。This port range is required for Azure infrastructure communication. 这些端口受 Azure 证书的保护(处于锁定状态)。These ports are protected (locked down) by Azure certificates. 外部实体(包括这些网关的客户)无法在这些终结点上通信。External entities, including the customers of those gateways, can't communicate on these endpoints.

  • 不能阻止出站 Internet 连接。Outbound Internet connectivity can't be blocked. NSG 中的默认出站规则允许 Internet 连接。Default outbound rules in the NSG allow Internet connectivity. 建议:We recommend that you:

    • 不要删除默认出站规则。Don't remove the default outbound rules.
    • 不要创建拒绝任何出站连接的其他出站规则。Don't create other outbound rules that deny any outbound connectivity.
  • 必须允许目标子网为“任意”的 AzureLoadBalancer 标记的流量 。Traffic from the AzureLoadBalancer tag with the destination subnet as Any must be allowed.

允许访问少量源 IPAllow access to a few source IPs

对于此方案,请在应用程序网关子网中使用 NSG。For this scenario, use NSGs on the Application Gateway subnet. 按以下优先顺序对子网施加以下限制:Put the following restrictions on the subnet in this order of priority:

  1. 允许来自源 IP 或 IP 范围的传入流量,其目标为整个应用程序网关子网地址范围,目标端口为入站访问端口,例如,使用端口 80 进行 HTTP 访问。Allow incoming traffic from a source IP or IP range with the destination as the entire Application Gateway subnet address range and destination port as your inbound access port, for example, port 80 for HTTP access.
  2. 允许特定的传入请求,这些请求来自采用 GatewayManager 服务标记的源,其目标为“任意”,目标端口为 65503-65534(适用于应用程序网关 v1 SKU)或 65200-65535(适用于 v2 SKU),可以进行后端运行状况通信Allow incoming requests from source as GatewayManager service tag and destination as Any and destination ports as 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for v2 SKU for back-end health status communication. 此端口范围是进行 Azure 基础结构通信所必需的。This port range is required for Azure infrastructure communication. 这些端口受 Azure 证书的保护(处于锁定状态)。These ports are protected (locked down) by Azure certificates. 如果没有适当的证书,外部实体将无法对这些终结点做出任何更改。Without appropriate certificates in place, external entities can't initiate changes on those endpoints.
  3. 允许网络安全组中的传入 Azure 负载均衡器探测(AzureLoadBalancer 标记)和入站虚拟网络流量(VirtualNetwork 标记)。Allow incoming Azure Load Balancer probes (AzureLoadBalancer tag) and inbound virtual network traffic (VirtualNetwork tag) on the network security group.
  4. 使用“全部拒绝”规则阻止其他所有传入流量。Block all other incoming traffic by using a deny-all rule.
  5. 允许所有目的地的 Internet 出站流量。Allow outbound traffic to the Internet for all destinations.

支持的用户定义路由Supported user-defined routes

重要

在应用程序网关子网中使用 UDR 可能会导致后端运行状况视图中的运行状态显示为“未知”。Using UDRs on the Application Gateway subnet might cause the health status in the back-end health view to appear as Unknown. 此外,可能还会导致应用程序网关日志和指标生成失败。It also might cause generation of Application Gateway logs and metrics to fail. 建议不要在应用程序网关子网中使用 UDR,以便能够查看后端运行状况、日志和指标。We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.

  • v1v1

    使用 v1 SKU 时,只要用户定义的路由 (UDR) 未更改端到端请求/响应通信,则应用程序网关子网就会支持这些 UDR。For the v1 SKU, user-defined routes (UDRs) are supported on the Application Gateway subnet, as long as they don't alter end-to-end request/response communication. 例如,可以在应用程序网关子网中设置一个指向防火墙设备的、用于检查数据包的 UDR。For example, you can set up a UDR in the Application Gateway subnet to point to a firewall appliance for packet inspection. 但是,必须确保数据包在检查后可以访问其预期目标。But you must make sure that the packet can reach its intended destination after inspection. 否则,可能会导致不正确的运行状况探测或流量路由行为。Failure to do so might result in incorrect health-probe or traffic-routing behavior. 这包括已探测到的路由,或者通过 Azure ExpressRoute 或 VPN 网关在虚拟网络中传播的默认 0.0.0.0/0 路由。This includes learned routes or default 0.0.0.0/0 routes that are propagated by Azure ExpressRoute or VPN gateways in the virtual network. V1 不支持需要在本地(强制隧道)重定向 0.0.0.0/0 的任何情况。Any scenario in which 0.0.0.0/0 needs to be redirected on-premises (forced tunneling) isn't supported for v1.

  • v2v2

    v2 SKU 存在支持和不支持的方案:For the v2 SKU, there are supported and unsupported scenarios:

    v2 支持的方案v2 supported scenarios

    警告

    错误配置路由表可能会导致应用程序网关 v2 中出现非对称路由。An incorrect configuration of the route table could result in asymmetrical routing in Application Gateway v2. 确保所有管理平面/控制平面流量直接发送到 Internet,且不通过虚拟设备发送。Ensure that all management/control plane traffic is sent directly to the Internet and not through a virtual appliance. 日志和指标也可能会受影响。Logging and metrics could also be affected.

    场景 1:使用 UDR 禁用向应用程序网关子网进行边界网关协议 (BGP) 路由传播Scenario 1: UDR to disable Border Gateway Protocol (BGP) Route Propagation to the Application Gateway subnet

    有时,默认网关路由 (0.0.0.0/0) 会通过与应用程序网关虚拟网络关联的 ExpressRoute 或 VPN 网关进行播发。Sometimes the default gateway route (0.0.0.0/0) is advertised via the ExpressRoute or VPN gateways associated with the Application Gateway virtual network. 这会中断管理平面流量,因此需要 Internet 的直接路径。This breaks management plane traffic, which requires a direct path to the Internet. 在这种情况下,可以使用 UDR 来禁用 BGP 路由传播。In such scenarios, a UDR can be used to disable BGP route propagation.

    若要禁用 BGP 路由传播,请使用以下步骤:To disable BGP route propagation, use the following steps:

    1. 在 Azure 中创建一个“路由表”资源。Create a Route Table resource in Azure.
    2. 禁用“虚拟网络网关路由传播”参数。Disable the Virtual network gateway route propagation parameter.
    3. 将路由表关联到相应的子网。Associate the Route Table to the appropriate subnet.

    为此方案启用 UDR 不应会破坏任何现有设置。Enabling the UDR for this scenario shouldn't break any existing setups.

    场景 2:使用 UDR 将 0.0.0.0/0 定向到 InternetScenario 2: UDR to direct 0.0.0.0/0 to the Internet

    可以创建一个 UDR,用于将 0.0.0.0/0 流量直接发送到 Internet。You can create a UDR to send 0.0.0.0/0 traffic directly to the Internet.

    方案 3:对 kubenet 中的 Azure Kubernetes 服务使用 UDRScenario 3: UDR for Azure Kubernetes Service with kubenet

    如果使用包含 Azure Kubernetes 服务 (AKS) 和应用程序网关入口控制器 (AGIC) 的 kubenet,则需要路由表,以允许将发送到 pod 的流量从应用程序网关路由到正确的节点。If you're using kubenet with Azure Kubernetes Service (AKS) and Application Gateway Ingress Controller (AGIC), you'll need a route table to allow traffic sent to the pods from Application Gateway to be routed to the correct node. 如果使用 Azure CNI,则不需要这样做。This won't be necessary if you use Azure CNI.

    若要使用路由表以使 kubenet 能够正常工作,请执行以下步骤:To use the route table to allow kubenet to work, follow the steps below:

    1. 转到 AKS 创建的资源组(资源组名称应以“MC_”开头)Go to the resource group created by AKS (the name of the resource group should begin with "MC_")
    2. 在该资源组中查找 AKS 创建的路由表。Find the route table created by AKS in that resource group. 路由表中应填充以下信息:The route table should be populated with the following information:
      • 地址前缀应是要在 AKS 中访问的 pod 的 IP 范围。Address prefix should be the IP range of the pods you want to reach in AKS.
      • 下一跃点类型应是“虚拟设备”。Next hop type should be Virtual Appliance.
      • 下一跃点地址应是托管 pod 的节点的 IP 地址。Next hop address should be the IP address of the node hosting the pods.
    3. 将此路由表关联到应用程序网关子网。Associate this route table to the Application Gateway subnet.

    v2 不支持的方案v2 unsupported scenarios

    场景 1:对虚拟设备使用 UDRScenario 1: UDR for Virtual Appliances

    V2 不支持需要通过任何虚拟设备、中心辐射型虚拟网络或者在本地(强制隧道)重定向 0.0.0.0/0 的任何方案。Any scenario where 0.0.0.0/0 needs to be redirected through any virtual appliance, a hub/spoke virtual network, or on-premise (forced tunneling) isn't supported for V2.

后续步骤Next steps