Azure 站点到站点 VPN 流量应在何处应用 NSG

站点到站点隧道已经建立，本地客户端能访问部分 Azure 主机，却访问不了另一些，于是有人在 GatewaySubnet 上挂了一个网络安全组想解决问题。请在此停手。Azure 不支持在 GatewaySubnet 上使用 NSG，而且该组看不到内层数据包，只有工作负载规则才能看到。请把策略放在目标子网或网卡上，匹配解密后真实存在的源地址，然后用新连接而不是旧连接进行验证。

把 NSG 放在 Azure 真正评估的位置

工作负载筛选受支持的边界是目标子网或目标网络接口。网关子网属于基础设施，Azure 明确说明不支持在其上使用 NSG，且可能损害网关运行。

放置位置还有逻辑问题。位于 GatewaySubnet 的 NSG 会评估外层 IPsec 交换，而那些地址属于两个网关。你的应用规则需要隧道内的私有源地址，而该数据包只有在网关解密之后才存在。把组挂到工作负载子网，规则才能看到它本该匹配的地址。

在改动之前先检查现有绑定，明确你要移动什么：

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

找到解密后的源地址

内层源是本地客户端的私有地址，或设备、VPN NAT 在转换后呈现的地址。它不是本地 VPN 网关的公网地址，后者属于外层交换。

当设计包含 NAT 时，要确认实际呈现的源地址，而不是假设。在 Azure 虚拟机上抓包，或查看服务连接日志中的源字段，比阅读本地配置更快得到答案。然后针对该地址和真实目标端口编写规则。

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

每个要暴露的服务用一条规则，并让端口列表保持简短。允许本地网段所有端口的规则，会让 NSG 沦为形式。

检查默认的 VirtualNetwork 范围

VirtualNetwork 服务标记比本地虚拟网络更宽。其定义包含已连接的本地区域地址空间、对等网络以及其他经网关连接的网段。因此，限定为 VirtualNetwork 的默认允许规则，可能已经放行了运维人员以为属于外部的隧道流量。

在添加窄规则之前先读默认规则，并读每一条可能先匹配的高优先级规则。新增显式允许并不会移除已有的更宽允许规则。若策略要求拒绝，请把拒绝放在真正先于允许被评估的优先级上。

Microsoft 的 服务标记文档 列出了 VirtualNetwork 标记覆盖的范围，当有人主张该标记只代表 VNet 网段时，应当引用这份资料。

读取两道边界上的有效规则

当子网 NSG 与网卡 NSG 同时生效时，流量必须同时满足两者。一边的允许不能覆盖另一边的拒绝，数据包真正面对的是合并后的结果。

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

如果涉及 Azure Virtual Network Manager 的安全管理员规则，也要检查这一层。管理员的 Always allow 规则可以在不评估 NSG 的情况下放行流量，而管理员的 Deny 会在 NSG 看到之前就拦截。对这种结构，只看 NSG 并不完整。

记住 NSG 是有状态的。修改规则未必会终止已有的允许连接，因此验收测试需要新的流量。这个特性在生产中有用，在变更窗口里却容易误导。

用新连接验证

从本地客户端向服务端口建立新会话，再从一台应被拒绝的主机重复一次。同时从虚拟机一侧执行流测试，确认回程路径完好。

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG 的允许只是一次访问决策，既不是路由也不是监听。如果规则放行了流量而连接仍失败，在再次修改该组之前，请检查 客户端进入 VPN 的路由、Azure 的回程路由以及主机防火墙。记录真实源地址、NSG 绑定和匹配的规则，并附上已批准的服务，因为下一次对等或路由变更可能改变 VirtualNetwork 标记的覆盖范围。