无需 NVA：在 ExpressRoute 上使用 Azure 专用 IP VPN

Azure VPN Gateway 可以通过 ExpressRoute 在专用地址上终止 IPsec。启用两个标志，然后阻止直接对等路由绕过隧道。

误区是：要在 ExpressRoute 专用对等互连上加密流量，必须使用网络虚拟设备。事实并非如此。Azure 支持 Site-to-Site VPN Gateway，其隧道终结点是经由线路传送的 RFC1918 专用地址，虚拟设备是可选项，而非结构性要求。这个误区真正掩盖的问题是：只在一个对象上启用专用终结点而不是两个，以及让直接对等路由悄悄压过加密路径。

误区从何而来

这种说法有可敬的渊源。多年来，在专用对等互连上运行 IPsec 的实用方案就是 NVA，因为托管网关只暴露公共终结点。情况已经改变，但改变之前写下的答案仍在一些没人核对日期的帖子里被引用。纠正范围很窄：带专用地址的 VPN 网关确实存在，它改变的是终结点，而不是其周边的路由逻辑。

这些都不意味着 NVA 退休。真正退场的是「设备是满足该需求的唯一途径」这一假设。

在两个层级都启用专用终结点

先从一条可用、且已关联到承载 VPN 网关的 VNet 的 ExpressRoute 专用对等连接开始。本地侧必须已经能通过该线路访问相关专用地址，因为隧道将把这些地址用作传输。然后是网关的先决条件：Microsoft 针对专用 IP VPN 的流程要求基于 Standard 公共 IP 资源构建的网关。专用隧道地址并不能免除该要求，这让一些认为「专用」等于「任何地方都没有公共 IP」的人感到意外。

现在在两个位置都启用该标志。网关配置有自己针对专用 IP 的开关，而单条 Site-to-Site 连接还有第二个开关，使该连接使用专用地址。只设一个而不设另一个是最常见的配置不完整；隧道要么建立不起来，要么建立到错误的终结点。

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

请对照已安装的 CLI 版本确认属性名称，因为门户标签与 CLI 属性的措辞并不总是一致。活动-活动网关会暴露两个专用隧道地址，若希望这种冗余有意义，本地设备需要配置两个对端。BGP 并非仅仅为了拉起这条专用地址隧道所必需，尽管它通常是分发前缀方式的一部分。

第二个误区：隧道建立即代表流量已加密

现在有两条路径到达应用网络：直接专用对等路径和经 VPN 的路径。两者都通。只有一条会施加这一层 IPsec。Microsoft 说明，当相同前缀同时通过 ExpressRoute 和 VPN 通告时，Azure 优先选择直接 ExpressRoute 路径，因此隧道健康、计数器健康并不能证明应用报文实际走了哪里。

有文档记载的引导方法有两种：在 ExpressRoute 上用覆盖范围、在 VPN 上用更具体的受保护范围；或在两条路径上使用不相交的前缀。举例来说，专用对等可以承载 10.40.0.0/16，而 VPN 通告 10.40.12.0/24。更具体的前缀胜出，范围内其余部分仍走直连。

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

在本地方向也要做同样的检查，因为出站流量从哪一侧离开由你的路由器偏好决定。并且要把隧道自身的传输保持在 ExpressRoute 路径上；把网关专用终结点拉进隧道的路由会让隧道依赖自身。

决定隧道中断时会发生什么

隧道中断时，更具体的 VPN 路由消失，而更宽泛的直接路由仍在。此时流量会在未加密的情况下流动，而一切看起来都正常，这对一个旨在保证加密的需求来说是最糟的失效模式。如果该需求禁止这种回退，路由与访问策略必须明确说明，而不是依赖隧道的可用性。

写下哪些前缀可以保持直接可达，哪些在加密路径缺失时必须停止。然后用真实流量测试被允许的情形并比较连接计数器，因为仅靠路由表无法告诉你加密要求是否仍然成立。

这个框架也让你能按 NVA 的真实功能来评估它，例如多隧道、吞吐量或厂商检测，而不是因为终结点是专用地址就买一个。

相关文章