Application Gateway V2关联NSG部署失败求助

核心原因 #

V2 SKU的Application Gateway（AG）依赖Azure管理平面（通过Azure Load Balancer）的入站流量维持健康状态与管理操作，这些流量使用端口范围65200-65535。你之前设置的sourceAddressPrefix: 'Internet'或*不符合Azure验证逻辑——Azure会检查NSG是否允许AzureLoadBalancer源的这些端口流量，而非公网流量。

具体修复步骤 #

1. 修正NSG入站规则的源地址 #

将nsgRule110的sourceAddressPrefix改为AzureLoadBalancer，这是AG V2要求的合法源地址。示例Bicep代码：

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
  name: 'nsg-acc-waf'
  location: resourceGroup().location
  properties: {
    securityRules: [
      // 保留已有的其他规则，添加/修改以下规则
      {
        name: 'nsgRule110'
        properties: {
          priority: 110
          direction: 'Inbound'
          access: 'Allow'
          protocol: '*'
          sourceAddressPrefix: 'AzureLoadBalancer'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '65200-65535'
        }
      }
      // 不要删除Azure默认的NSG规则（如AllowVnetInBound、AllowAzureLoadBalancerInBound）
    ]
  }
}

2. 确保规则优先级正确 #

• 这条允许规则的优先级必须高于任何拒绝这些端口的规则（比如自定义的Deny规则）。
• 默认的DenyAllInBound优先级是65500，所以你的规则优先级（如110）要远低于这个数值（数字越小优先级越高）。

3. 调整Bicep部署依赖关系 #

如果NSG已绑定到AG子网，重新部署时需确保NSG规则先完成更新，再触发子网关联的验证。可以通过显式设置依赖实现：

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-05-01' = {
  parent: vnet
  name: 'snet-acc-waf'
  properties: {
    addressPrefix: '10.0.1.0/24'
    networkSecurityGroup: {
      id: nsg.id
    }
  }
  // 明确依赖NSG资源，确保规则先部署完成
  dependsOn: [
    nsg
  ]
}

4. 排查隐式拒绝规则 #

检查NSG中是否存在其他优先级更高的规则，比如自定义的Deny规则，可能会覆盖这条允许规则。确保所有影响65200-65535端口的规则中，允许规则的优先级最高。

为什么手动操作可行？ #

手动添加规则时，Azure的验证逻辑会在规则生效后再检查子网与AG的关联状态；而Bicep重新部署时，可能因部署顺序问题，在规则未完全更新完成前就触发了AG的子网绑定验证，从而抛出错误。

内容的提问来源于stack exchange，提问作者rdvanbuuren