为什么添加 Azure VPN 前缀会导致连接断开

把前缀添加到错误的 Azure 对象上，会得到一条报告 Connected 却什么都不转发的连接，而这是这套技术栈里代价最高的错误。涉及三个资源，其中只有一个拥有远程地址空间：虚拟网络网关、描述对端的本地网络网关，以及把两者连接起来的连接。前缀属于本地网络网关，必须重建连接改动才会生效，而网关本身通常不动。顺序不可协商，门户也只展示了其中一部分。

三个对象，其中一个持有前缀

虚拟网络的地址空间回答的是另一个问题：Azure 内部有什么。在那里添加远程前缀并不会把流量路由过去，只会扩大平台自认为拥有的空间，这可能与真实的远程网段冲突。持有远程前缀的对象是本地网络网关，而连接同时引用两个网关和一个预共享密钥。

还有第三个需要记牢的保留项。 GatewaySubnet 承载托管网关实例，必须精确使用这个名称，对于非 Basic 的 SKU，期望它至少是 /27。

该子网里不该有别的资源，改前缀也没有理由去碰它。本地网络网关里缺失的前缀，无论连接状态怎么说都不可达，因为网关在协商隧道时只会提供被告知过的前缀。这就是症状不对称的原因：隧道是通的，安全关联也正常，只有一个子网始终不出现在流量选择器里。如果相邻网段都正常而只有一个远程网段缺失，别再盯着隧道，去读本地网络网关。

为什么被移除的是连接

连接对象会在其整个生命周期内锁定协商好的配置。因此文档中的流程是先删除连接、更新本地网络网关，再用同一个共享密钥重建连接。仅改前缀不会重建网关实例，这让中断被限制在连接拆除范围内，而不是重新部署网关。

那次删除就是中断本身，所以应当把它当作有开始时间和预期结束时间的计划变更，而不是一次快速编辑。在 PowerShell 里顺序很短： Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force，然后 Set-AzLocalNetworkGateway 配上新的 -AddressPrefix 数组，然后 New-AzVirtualNetworkGatewayConnection 配上同一个 -SharedKey 和同样的网关。复用密钥很重要，因为对端并没有被重新配置，新密钥意味着要和远程设备的所有者协调。如果那台设备由另一个团队运维，动手之前先和他们约好窗口。

什么时候才需要重建网关本身

围绕这个问题流传的第二种说法是必须重建网关并重新交换密钥。那对另一组操作才是对的：更改网关类型或 SKU、在点到站点与站点到站点之间切换，或者修复自身配置有误的网关。那些改动确实会改变网关资源，所以重建确实必要。

为点到站点创建的网关不能直接拿来给站点到站点连接用。必须先移除点到站点配置并重建网关，这同时会产生新的共享密钥和新的客户端包。

点到站点包值得单独说明，因为它会过期。门户生成的文件寿命很短，所以务实的做法是下载一次，连同客户端证书一起分发，而不是把门户链接发给用户——等他们点开时链接早已失效。至于前缀这个问题，以上都不适用。把两套流程分开就是全部纪律：前缀是连接层面的变更，网关属性是网关层面的变更。

读状态，而不是读门户徽章

从资源读状态，而不是从门户里的徽章读。 Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 会返回 ConnectionStatus 以及入向和出向字节计数器，而计数器正是区分「已连接但什么都没传」和「从未建立」的关键。

传输中途停止增长的计数器 指向路径而不是认证。完全不动计数器指向前缀集合或共享密钥。

计时器解释了一类常被错误归咎于 VPN 的断线。Azure 的负载均衡器会在配置的超时之后关闭空闲流，写这些笔记时默认是四分钟，而且可以调大，所以没有 keepalive 的 VM 上的 OpenVPN 服务器可能每隔几分钟就掉线，而其他一切看起来都很正常。平台周期性重启的网关也可能 打断 VNet 到 Web App 的连接，而这种故障在平台侧，不在客户端配置里。判断线索是断线跟随固定间隔，还是跟随你做的某次改动。

把三个对象和它们的值记在同一条记录里：虚拟网络地址空间、本地网络网关的前缀列表，以及连接的共享密钥引用。 站点到站点的 PowerShell 文章 记录了本地网络网关的命令及其应有的顺序。拿前缀改动去和记忆比对，就是把一条本来正常的隧道重建两次的方式。

然后按你改动的顺序验证：本地网络网关显示新的前缀列表，连接回到 Connected，向新网段里的主机发送流量时计数器开始增长。如果前两步都过而第三步失败，说明对端没有接受新的流量选择器，远程设备需要对应的阶段 2 条目。那是和隧道另一端的对话，不是 Azure 里再做一次改动。