Alterar o IP público de um gateway VPN do Azure e mover a subscrição

No Azure, três objetos diferentes respondem pelo nome de endereço do gateway. O endereço privado é atribuído a partir do GatewaySubnet. O endereço público é um recurso de IP público separado para o qual aponta a configuração IP do gateway. A subscrição e o ambiente de cloud são o contexto com que a shell encontra um ou outro. Mude um e os outros dois ficam onde estavam, e é por isso que o trabalho de endereços tantas vezes para a meio.

Faço estas alterações em quatro fases: inventariar os objetos, decidir se o IP público se move no gateway existente ou se o gateway é reconstruído, aplicar a alteração enquanto o endereço antigo ainda está à mão, e depois verificar cada túnel dos dois lados antes de apagar seja o que for. A fase que se salta é o inventário.

Qual dos três objetos está realmente a alterar

Dê nome ao objeto antes de abrir o portal. Um gateway VPN recebe o endereço privado de uma sub-rede que tem de se chamar exatamente GatewaySubnet, e o Azure atribui-o a partir desse prefixo; não existe um campo geral para o fixar. O endereço parece estável só porque a sub-rede é estável. Reenderece a sub-rede ou reconstrua o gateway e ele move-se com elas.

O endereço público é editável, mas as regras de SKU decidem se a edição é legal. Um gateway Basic emparelha com um IP público dinâmico Basic, as SKU VpnGw exigem um Standard estático e um gateway com redundância de zona exige um IP público Standard com as mesmas zonas. A SKU errada é rejeitada antes de um túnel cair.

Inventário antes de algo se mover

Prove primeiro a subscrição, porque o resto do inventário não vale nada sem ela. Capture o gateway, as suas configurações IP e cada ligação que termina nele, e guarde a saída junto do registo da alteração.

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

Os ID de recurso contam mais do que os nomes. Uma ligação contém referências ao gateway e a um gateway de rede local, e esses ID aparecem em scripts, alertas e atribuições de políticas que ninguém recorda. Liste também o que está fora do Azure: o nome DNS que resolve para o endereço, a lista de permissões do parceiro, a firewall da filial que fixa o IP antigo.

Substituir o IP público no gateway em funcionamento

Crie primeiro o endereço de substituição, na mesma região e com o conjunto de zonas que corresponde ao gateway, e deixe o recurso antigo no lugar. Depois reconstrua a configuração IP e envie a atualização numa só chamada. Essa chamada substitui toda a coleção de configurações, por isso um gateway ativo-ativo precisa das duas, ou fica com um túnel e perde o outro.

$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

Os túneis caem enquanto o gateway é reaprovisionado. O lado remoto precisa do calendário: uma firewall do parceiro continua a oferecer o endereço antigo até alguém a editar, e uma ligação cujo extremo remoto espera o IP anterior fica em baixo por muito saudável que o Azure pareça. Baixe o TTL do DNS antes da janela.

Os clientes ponto-a-site precisam de um perfil novo, porque o pacote descarregado transporta o endpoint. Um nome DNS próprio à frente do gateway poupa a redistribuição: mantenha o nome, mude o registo.

Mover o gateway para outra subscrição

Mover recursos desloca um conjunto, e o gateway sozinho é o seu membro menos útil. A rede virtual, os recursos de IP público, os gateways de rede local e as ligações viajam juntos porque cada um mantém uma referência a outro. A subscrição de destino tem de estar no mesmo inquilino, o Microsoft.Network tem de estar registado lá, e precisa de acesso de escrita nos dois lados.

A validação corre antes de algo mudar, por isso uma movimentação rejeitada deixa os recursos no lugar. Por isso a movimentação merece uma tentativa antes de reconstruir: uma movimentação bem-sucedida leva o IP público consigo, pelo que parceiros e listas de permissões continuam a funcionar, enquanto um gateway reconstruído raramente devolve o mesmo endereço.

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

Leia a falha de validação em vez de a repetir. As causas habituais são uma dependência deixada para trás, um tipo de recurso que não pode ser movido ou um bloqueio em qualquer dos grupos de recursos. Se a movimentação for impossível, reconstrua no destino e faça o corte: confirme o encaminhamento e a autenticação a partir de uma sub-rede de teste, pare as ligações antigas em vez de as apagar e depois remova o caminho antigo numa janela posterior.

Quando o gateway parece faltar, verifique o contexto

O erro de não encontrado é normalmente um erro de âmbito. Uma conta com várias subscrições aponta um cmdlet para a errada, e a mensagem culpa o recurso. Procure o objeto pelo ID de recurso completo: o ID transporta a sua própria subscrição, por isso, se resolver, não falta nada e o contexto predefinido está errado.

Mais dois desalinhamentos leem-se da mesma forma. Um gateway de cloud comercial não existe numa sessão dirigida a um ambiente governamental ou chinês, e as versões antigas dos módulos não veem formas de recurso que a API já devolve. Fixe a subscrição, alinhe o ambiente e só depois abra um caso.

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

Verifique dos dois lados antes de limpar

Ligado é um estado, não uma prova. Verifique o estado do túnel por ligação, o estado do par BGP se usar encaminhamento dinâmico e as rotas efetivas numa sub-rede de carga de trabalho. Depois passe um pedido real por uma aplicação que dependa do túnel. Uma ligação pode reportar-se ligada enquanto o prefixo de que precisa falta na tabela de rotas.

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

Mantenha o IP público antigo desassociado em vez de apagado até a janela de reversão fechar, e registe as edições do parceiro e da firewall para que possam ser revertidas por ordem.

• Contexto fixado à subscrição proprietária do gateway
• IP público antigo conservado e as suas dependências registadas
• Cada ligação verde e um pedido real através dela
• Utilizadores ponto-a-site passados para o perfil atualizado
• Registo DNS alterado e o valor anterior anotado