更改 Azure VPN 网关的公共 IP 并迁移订阅

更换 VPN 网关公共 IP 并在订阅之间迁移的操作手册，包含资产清点、回滚以及维持隧道可用的上下文检查。

在 Azure 中，有三种不同的对象都被称作网关地址。专用地址从 GatewaySubnet 分配。公共地址是 IP 配置所指向的独立公共 IP 资源。订阅与云环境则是 Shell 用来定位前两者的上下文。改动其中一个，另外两个仍留在原处，这正是地址类工作常常半途而废的原因。

我把这类变更分四个阶段：先清点对象，再决定公共 IP 是在现有网关上更换还是把网关整体重建，趁旧地址还在手里时执行变更，最后在删除任何东西之前从两端验证每条隧道。最常被跳过的阶段就是清点，而它恰恰决定后面每一步是否有依据。

你真正在改的是三个对象中的哪一个

打开门户之前先给对象命名。VPN 网关的专用地址来自名称必须恰为 GatewaySubnet 的子网，Azure 从该前缀中分配，并没有可以固定它的通用字段。地址看起来稳定，只是因为子网稳定。改了子网或重建了网关，地址就随之移动。

公共地址可以修改，但能否修改由 SKU 规则决定。Basic 网关搭配 Basic 动态公共 IP，VpnGw SKU 需要 Standard 静态 IP，区域冗余网关需要携带相同区域的 Standard 公共 IP。SKU 不匹配会在隧道中断之前就被拒绝。

ObjectWhere it livesWhat a change forces
Private addressGatewaySubnet prefix, assigned at deploymentSubnet resize or rebuild, then routes, NSGs and peer review
Public addressPublic IP resource referenced by the IP configurationGateway reprovision, peer and allowlist edits, new client profiles
Subscription contextYour PowerShell or CLI sessionNothing in Azure, and it clears most not-found errors

动任何东西之前先清点

先证明订阅，否则其余清点毫无意义。记录网关、它的 IP 配置以及终结其上的每条连接，并把输出放在变更记录旁边。

Get-AzContext | Select-Object Subscription, Tenant, Environment
Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub |
  Select-Object Name, Sku, EnableActiveActive, IpConfigurations
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName rg-hub |
  Select-Object Name, ConnectionStatus, ConnectionType

资源 ID 比名称更重要。一条连接同时持有对网关和对本地网络网关的引用，这些 ID 会出现在没人记得的脚本、告警和策略分配里。也要把 Azure 之外的东西列清楚：解析到该地址的 DNS 名称、合作伙伴的许可清单，以及把旧 IP 钉死的分支防火墙。

在运行中的网关上更换公共 IP

先在同一区域、用与网关匹配的区域集创建替换地址，旧资源保持不动。然后重建 IP 配置，用一次调用推送更新。该调用会替换整个配置集合，因此双活网关两项都要给，否则你会保住一条隧道而丢掉另一条。

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub
$pip = New-AzPublicIpAddress -Name pip-gw-hub-2 -ResourceGroupName rg-hub `
  -Location westeurope -AllocationMethod Static -Sku Standard
$conf = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 `
  -SubnetId $gw.IpConfigurations[0].Subnet.Id -PublicIpAddressId $pip.Id
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -IpConfigurations $conf

网关重新配置期间隧道会中断。对端需要排期：伙伴防火墙会一直提供旧地址，直到有人修改它；而对端仍期待旧 IP 的连接，无论 Azure 看起来多健康都会保持中断。在窗口之前调低 DNS TTL。

点到站点客户端需要新的配置文件，因为下载的包带着终结点。若在网关前放置自有 DNS 名称，就免去重新分发：保留名称，改记录即可。

把网关迁移到另一个订阅

资源迁移搬的是一个集合，单网关是最没有用的成员。虚拟网络、公共 IP 资源、本地网络网关和连接要一起走，因为彼此互相引用。目标订阅必须在同一租户中，必须注册 Microsoft.Network，且两侧都要有写权限。

验证在所有变更之前运行，因此被拒绝的迁移会让资源原地不动。这就是迁移值得在重建之前先试一次的原因：成功的迁移会把公共 IP 一并带走，伙伴与许可清单继续可用；而重建的网关很少返回同一个地址。

az resource move --destination-group rg-hub `
  --destination-subscription-id 00000000-0000-0000-0000-000000000000 `
  --ids /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

读懂验证失败，而不是反复重试。常见原因是遗留的依赖、根本无法迁移的资源类型，或任一资源组上的锁。若迁移确实不可能，就在目标端重建再切换：先从测试子网确认路由与身份验证，停止旧连接而不是直接删除，最后在后续窗口里移除旧路径。

当网关看起来消失时，检查上下文

找不到错误通常是作用域错误。拥有多个订阅的账户把 cmdlet 指向了错误的一个，消息却归咎于资源。改用完整资源 ID 查询对象：ID 自带订阅，因此若能解析，就说明什么都没丢，是你的默认上下文错了。

另外两种错配读起来一样。商业云网关不会出现在针对政府或中国环境的会话里；旧版本模块也识别不了 API 已经返回的资源形态。固定订阅、对齐环境，然后再开工单。

Set-AzContext -SubscriptionId 11111111-1111-1111-1111-111111111111
Get-AzResource -ResourceId /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

清理之前从两端验证

已连接只是状态，不是证据。要按连接检查隧道状态，使用动态路由时检查 BGP 邻居状态，并查看工作负载子网上的有效路由。然后再通过一个依赖该隧道的应用发一次真实请求。连接可以报告已连接，而所需前缀并不在路由表里。

Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app

在回退窗口关闭之前，把旧公共 IP 解绑而不是删除，并把对端与防火墙的改动写下来，以便按顺序回滚。

  • 上下文已固定在拥有网关的订阅上
  • 旧公共 IP 已保留，其依赖项已记录
  • 每条连接均为绿色，并有一个真实请求通过
  • 点到站点用户已迁移到刷新后的配置文件
  • DNS 记录已更改，并记录了原值

相关文章