Cambiar o IP público dunha pasarela VPN de Azure e mover a subscrición
Guía para substituír o IP público dunha pasarela VPN e movela entre subscricións, co inventario, a reversión e as comprobacións de contexto que manteñen os túneles activos.
En Azure, tres obxectos distintos responden ao nome de enderezo da pasarela. O enderezo privado asígnase desde GatewaySubnet. O enderezo público é un recurso de IP pública aparte ao que apunta a configuración IP da pasarela. A subscrición e a contorna de nube son o contexto co que o teu shell atopa un ou outro. Cambia un e os outros dous quedan onde estaban, e por iso o traballo con enderezos se detén tantas veces a metade.
Fago estes cambios en catro etapas: inventariar os obxectos, decidir se o IP público se move na pasarela existente ou se reconstrúe a pasarela, aplicar o cambio mentres aínda temos o enderezo antigo, e logo verificar cada túnel desde ambos os extremos antes de borrar nada. A etapa que a xente salta é o inventario.
Cal dos tres obxectos estás cambiando realmente
Nomea o obxecto antes de abrir o portal. Unha pasarela VPN toma o seu enderezo privado dunha subrede que debe chamarse exactamente GatewaySubnet, e Azure asígno desde ese prefixo; non hai un campo xeral para fixalo. O enderezo parece estable só porque a subrede é estable. Reasigna a subrede ou reconstrúe a pasarela e múdase con elas.
O enderezo público é editable, pero as regras de SKU deciden se a edición é legal. Unha pasarela Basic emparellase cun IP público dinámico Basic, as SKU VpnGw necesitan unha Standard estática e unha pasarela con redundancia de zona necesita un IP público Standard coas mesmas zonas. A SKU incorrecta rexéitase antes de que caia un túnel.
| Object | Where it lives | What a change forces |
|---|---|---|
| Private address | GatewaySubnet prefix, assigned at deployment | Subnet resize or rebuild, then routes, NSGs and peer review |
| Public address | Public IP resource referenced by the IP configuration | Gateway reprovision, peer and allowlist edits, new client profiles |
| Subscription context | Your PowerShell or CLI session | Nothing in Azure, and it clears most not-found errors |
Inventario antes de que algo se mova
Demostra primeiro a subscrición, porque o resto do inventario non vale nada sen ela. Captura a pasarela, as súas configuracións IP e cada conexión que remata nela, e garda a saída xunto ao rexistro do cambio.
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 importan máis que os nomes. Unha conexión contén referencias á pasarela e a unha pasarela de rede local, e eses ID aparecen en scripts, alertas e asignacións de directivas que ninguén recorda. Enumera tamén o que está fóra de Azure: o nome DNS que resolve ao enderezo, a lista de permisos do socio, a devasa da sucursal que fixa o IP antigo.
Cambiar o IP público na pasarela en funcionamento
Crea primeiro o enderezo de substitución, na mesma rexión e co conxunto de zonas que encaixa coa pasarela, e deixa o recurso antigo no seu sitio. Despois reconstrúe a configuración IP e envía a actualización nunha soa chamada. Esa chamada substitúe toda a colección de configuracións, así que unha pasarela activo-activo necesita as dúas ou quedas cun túnel e perdes 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úneles caen mentres a pasarela se reaprovisiona. O lado remoto necesita a planificación: unha devasa do socio segue ofrecendo o enderezo antigo ata que alguén a edite, e unha conexión cuxo extremo remoto espera o IP anterior queda caída por moi san que pareza Azure. Baixa o TTL de DNS antes da ventá.
Os clientes de punto a sitio necesitan un perfil novo, porque o paquete descargado leva o punto de conexión. Un nome DNS propio diante da pasarela aforra a redistribución: mantén o nome, cambia o rexistro.
Mover a pasarela a outra subscrición
Mover recursos traslada un conxunto, e a pasarela soa é o seu membro menos útil. A rede virtual, os recursos de IP pública, as pasarelas de rede local e as conexións viaxan xuntas porque cada unha mantén unha referencia a outra. A subscrición de destino debe estar no mesmo inquilino, Microsoft.Network debe estar rexistrado alí e necesitas acceso de escritura en ambos os lados.
A validación execútase antes de que algo cambie, así que un movemento rexeitado deixa os recursos no seu sitio. Por iso o movemento merece un intento antes de reconstruír: un movemento correcto leva o IP público, de xeito que os socios e as listas de permisos seguen funcionando, mentres que unha pasarela reconstruída raramente devolve o mesmo enderezo.
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
Le o fallo de validación en lugar de reintentalo. As causas habituais son unha dependencia que se deixou atrás, un tipo de recurso que non se pode mover ou un bloqueo en calquera dos grupos de recursos. Se o movemento é imposible, reconstrúe no destino e fai o cambio: confirma o encamiñamento e a autenticación desde unha subrede de proba, detén as conexións antigas en lugar de borralas e elimina a ruta antiga nunha ventá posterior.
Cando a pasarela parece faltar, comproba o contexto
O erro de non atopado adoita ser un erro de ámbito. Unha conta con varias subscricións apunta un cmdlet á equivocada, e a mensaxe culpa o recurso. Busca o obxecto polo seu ID de recurso completo: o ID leva a súa propia subscrición, así que se se resolve, non falta nada e o teu contexto predeterminado é erróneo.
Dous desaxustes máis len igual. Unha pasarela de nube comercial non existe nunha sesión dirixida a unha contorna gobernamental ou de China, e as versións antigas dos módulos non ven formas de recurso que a API xa devolve. Fixa a subscrición, axusta a contorna e despois abre un 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
Verifica desde ambos os extremos antes de limpar
Conectado é un estado, non unha proba. Comproba o estado do túnel por conexión, o estado do veciño BGP se usas encamiñamento dinámico e as rutas efectivas nunha subrede de carga. Despois pasa unha petición real por unha aplicación que dependa do túnel. Unha conexión pode informar que está conectada mentres falta o prefixo que necesitas na táboa de rutas.
Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app
Mantén o IP público antigo desasociado en lugar de borrado ata que se peche a ventá de reversión, e anota as edicións do socio e da devasa para poder revertelas en orde.
- Contexto fixado á subscrición propietaria da pasarela
- IP público antigo conservado e as súas dependencias anotadas
- Cada conexión en verde e unha petición real a través dela
- Usuarios de punto a sitio movidos ao perfil actualizado
- Rexistro DNS cambiado e o seu valor anterior anotado