Cambiar la IP pública de una puerta de enlace VPN de Azure y mover la suscripción
Guía para sustituir la IP pública de una puerta de enlace VPN y moverla entre suscripciones, con el inventario, la reversión y las comprobaciones de contexto que mantienen los túneles activos.
En Azure, tres objetos distintos responden al nombre de dirección de la puerta de enlace. La dirección privada se asigna desde GatewaySubnet. La dirección pública es un recurso de IP pública aparte al que apunta la configuración IP de la puerta de enlace. La suscripción y el entorno de nube son el contexto con el que tu shell encuentra una u otra. Cambia una y las otras dos se quedan donde estaban, y por eso el trabajo con direcciones se detiene tantas veces a medio camino.
Hago estos cambios en cuatro etapas: inventariar los objetos, decidir si la IP pública se mueve en la puerta de enlace existente o se reconstruye la puerta de enlace, aplicar el cambio mientras aún tenemos la dirección antigua, y luego verificar cada túnel desde ambos extremos antes de borrar nada. La etapa que la gente se salta es el inventario.
Cuál de los tres objetos estás cambiando en realidad
Nombra el objeto antes de abrir el portal. Una puerta de enlace VPN toma su dirección privada de una subred que debe llamarse exactamente GatewaySubnet, y Azure la asigna desde ese prefijo; no hay un campo general para fijarla. La dirección parece estable solo porque la subred es estable. Reasigna la dirección de la subred o reconstruye la puerta de enlace y se mueve con ellas.
La dirección pública es editable, pero las reglas de SKU deciden si la edición es legal. Una puerta de enlace Basic se empareja con una IP pública dinámica Basic, las SKU VpnGw necesitan una Standard estática y una puerta de enlace con redundancia de zona necesita una IP pública Standard con las mismas zonas. La SKU incorrecta se rechaza antes de que caiga 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 mueva
Demuestra primero la suscripción, porque el resto del inventario no vale nada sin ella. Captura la puerta de enlace, sus configuraciones IP y cada conexión que termina en ella, y guarda la salida junto al registro del 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
Los ID de recurso importan más que los nombres. Una conexión contiene referencias a la puerta de enlace y a una puerta de enlace de red local, y esos ID aparecen en scripts, alertas y asignaciones de directivas que nadie recuerda. Enumera también lo que está fuera de Azure: el nombre DNS que resuelve a la dirección, la lista de permisos del socio, el firewall de la sucursal que fija la IP antigua.
Cambiar la IP pública en la puerta de enlace en funcionamiento
Crea primero la dirección de sustitución, en la misma región y con el conjunto de zonas que encaja con la puerta de enlace, y deja el recurso antiguo en su sitio. Después reconstruye la configuración IP y envía la actualización en una sola llamada. Esa llamada sustituye toda la colección de configuraciones, así que una puerta de enlace activo-activo necesita las dos o te quedas con un túnel y pierdes el otro.
$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
Los túneles caen mientras la puerta de enlace se reaprovisiona. El lado remoto necesita la planificación: un firewall del socio sigue ofreciendo la dirección antigua hasta que alguien lo edite, y una conexión cuyo extremo remoto espera la IP anterior permanece caída por muy sano que parezca Azure. Baja el TTL de DNS antes de la ventana.
Los clientes de punto a sitio necesitan un perfil nuevo, porque el paquete descargado lleva el punto de conexión. Un nombre DNS propio delante de la puerta de enlace te ahorra la redistribución: mantén el nombre, cambia el registro.
Mover la puerta de enlace a otra suscripción
Mover recursos traslada un conjunto, y la puerta de enlace sola es su miembro menos útil. La red virtual, los recursos de IP pública, las puertas de enlace de red local y las conexiones viajan juntas porque cada una mantiene una referencia a otra. La suscripción de destino debe estar en el mismo inquilino, Microsoft.Network debe estar registrado allí y necesitas acceso de escritura en ambos lados.
La validación se ejecuta antes de que algo cambie, así que un movimiento rechazado deja los recursos en su sitio. Por eso el movimiento merece un intento antes de reconstruir: un movimiento correcto se lleva la IP pública, de modo que los socios y las listas de permisos siguen funcionando, mientras que una puerta de enlace reconstruida rara vez devuelve la misma dirección.
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
Lee el fallo de validación en lugar de reintentarlo. Las causas habituales son una dependencia que se dejó atrás, un tipo de recurso que no se puede mover o un bloqueo en cualquiera de los grupos de recursos. Si el movimiento es imposible, reconstruye en el destino y haz el cambio: confirma el enrutamiento y la autenticación desde una subred de prueba, detén las conexiones antiguas en lugar de borrarlas y elimina la ruta antigua en una ventana posterior.
Cuando la puerta de enlace parece faltar, comprueba el contexto
El error de no encontrado suele ser un error de ámbito. Una cuenta con varias suscripciones apunta un cmdlet a la equivocada, y el mensaje culpa al recurso. Busca el objeto por su ID de recurso completo: el ID lleva su propia suscripción, así que si se resuelve, no falta nada y tu contexto predeterminado es erróneo.
Dos desajustes más se leen igual. Una puerta de enlace de nube comercial no existe en una sesión dirigida a un entorno gubernamental o de China, y las versiones antiguas de los módulos no ven formas de recurso que la API ya devuelve. Fija la suscripción, ajusta el entorno y luego 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 extremos antes de limpiar
Conectado es un estado, no una prueba. Comprueba el estado del túnel por conexión, el estado del vecino BGP si usas enrutamiento dinámico y las rutas efectivas en una subred de carga de trabajo. Después pasa una petición real por una aplicación que dependa del túnel. Una conexión puede informar que está conectada mientras falta el prefijo que necesitas en la tabla de rutas.
Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app
Mantén la IP pública antigua desasociada en lugar de borrada hasta que se cierre la ventana de reversión, y anota las ediciones del socio y del firewall para poder revertirlas en orden.
- Contexto fijado a la suscripción propietaria de la puerta de enlace
- IP pública antigua conservada y sus dependencias anotadas
- Cada conexión en verde y una petición real a través de ella
- Usuarios de punto a sitio movidos al perfil actualizado
- Registro DNS cambiado y su valor anterior anotado