Changer l'IP publique d'une passerelle VPN Azure et déplacer l'abonnement

Dans Azure, trois objets différents répondent au nom d'adresse de la passerelle. L'adresse privée est allouée depuis GatewaySubnet. L'adresse publique est une ressource d'IP publique distincte vers laquelle pointe la configuration IP de la passerelle. L'abonnement et l'environnement cloud sont le contexte avec lequel votre shell trouve l'une ou l'autre. Changez l'une et les deux autres restent en place, c'est pourquoi le travail d'adressage s'arrête si souvent à mi-chemin.

J'exécute ces changements en quatre étapes : inventorier les objets, décider si l'IP publique migre sur la passerelle existante ou si la passerelle est reconstruite, appliquer le changement tant que l'ancienne adresse est encore disponible, puis vérifier chaque tunnel des deux côtés avant de supprimer quoi que ce soit. L'étape que l'on saute est l'inventaire.

Lequel des trois objets vous modifiez réellement

Nommez l'objet avant d'ouvrir le portail. Une passerelle VPN prend son adresse privée dans un sous-réseau qui doit s'appeler exactement GatewaySubnet, et Azure l'alloue depuis ce préfixe ; il n'existe pas de champ général pour l'épingler. L'adresse ne paraît stable que parce que le sous-réseau l'est. Readressez le sous-réseau ou reconstruisez la passerelle et elle suit.

L'adresse publique est modifiable, mais les règles de SKU décident si la modification est légale. Une passerelle Basic s'associe à une IP publique dynamique Basic, les SKU VpnGw exigent une Standard statique, et une passerelle redondante de zone exige une IP publique Standard portant les mêmes zones. Le mauvais SKU est rejeté avant qu'un tunnel ne tombe.

Inventaire avant que rien ne bouge

Prouvez d'abord l'abonnement, car le reste de l'inventaire ne vaut rien sans lui. Capturez la passerelle, ses configurations IP et chaque connexion qui s'y termine, et conservez la sortie à côté du registre de changement.

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

Les ID de ressource comptent plus que les noms. Une connexion contient des références à la passerelle et à une passerelle de réseau local, et ces ID apparaissent dans des scripts, alertes et affectations de stratégie que personne ne retient. Listez aussi ce qui est hors d'Azure : le nom DNS qui résout vers l'adresse, la liste d'autorisation du partenaire, le pare-feu de l'agence qui épingle l'ancienne IP.

Remplacer l'IP publique sur la passerelle en service

Créez d'abord l'adresse de remplacement, dans la même région et avec le jeu de zones correspondant à la passerelle, et laissez l'ancienne ressource en place. Reconstruisez ensuite la configuration IP et poussez la mise à jour en un seul appel. Cet appel remplace toute la collection de configurations, donc une passerelle actif-actif a besoin des deux, sinon vous gardez un tunnel et perdez l'autre.

$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

Les tunnels tombent pendant le reprovisionnement de la passerelle. Le côté distant a besoin du calendrier : un pare-feu partenaire continue d'offrir l'ancienne adresse jusqu'à ce que quelqu'un le modifie, et une connexion dont l'extrémité distante attend l'IP précédente reste coupée même si Azure paraît sain. Abaissez le TTL DNS avant la fenêtre.

Les clients point à site ont besoin d'un nouveau profil, car le paquet téléchargé porte le point de terminaison. Un nom DNS personnalisé devant la passerelle vous épargne la redistribution : gardez le nom, changez l'enregistrement.

Déplacer la passerelle vers un autre abonnement

Un déplacement de ressources déplace un ensemble, et la passerelle seule en est le membre le moins utile. Le réseau virtuel, les ressources d'IP publique, les passerelles de réseau local et les connexions voyagent ensemble car chacun détient une référence à un autre. L'abonnement cible doit être dans le même locataire, Microsoft.Network doit y être inscrit, et vous avez besoin d'un accès en écriture des deux côtés.

La validation s'exécute avant tout changement, un déplacement rejeté laisse donc les ressources en place. C'est pourquoi le déplacement mérite un essai avant une reconstruction : un déplacement réussi emporte l'IP publique, donc les pairs et les listes d'autorisation continuent de fonctionner, alors qu'une passerelle reconstruite rend rarement la même adresse.

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

Lisez l'échec de validation au lieu de le réessayer. Les causes habituelles sont une dépendance laissée derrière, un type de ressource qui ne peut pas être déplacé ou un verrou sur l'un des groupes de ressources. Si le déplacement est impossible, reconstruisez dans la cible et basculez : confirmez le routage et l'authentification depuis un sous-réseau de test, arrêtez les anciennes connexions au lieu de les supprimer, puis retirez l'ancien chemin dans une fenêtre ultérieure.

Quand la passerelle semble manquer, vérifiez le contexte

L'erreur introuvable est généralement une erreur de portée. Un compte avec plusieurs abonnements pointe une cmdlet vers le mauvais, et le message accuse la ressource. Cherchez plutôt l'objet par son ID de ressource complet : l'ID porte son propre abonnement, donc s'il se résout, rien ne manque et votre contexte par défaut est faux.

Deux autres incompatibilités se lisent de la même façon. Une passerelle de cloud commercial n'existe pas dans une session visant un environnement gouvernemental ou chinois, et les anciennes versions de modules manquent des formes de ressources que l'API renvoie déjà. Épinglez l'abonnement, alignez l'environnement, puis ouvrez un cas.

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

Vérifiez des deux côtés avant de nettoyer

Connecté est un état, pas une preuve. Vérifiez l'état du tunnel par connexion, l'état du pair BGP si vous utilisez le routage dynamique, et les routes effectives sur un sous-réseau de charge. Passez ensuite une vraie requête par une application qui dépend du tunnel. Une connexion peut se déclarer connectée alors que le préfixe dont vous avez besoin manque à la table de routage.

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

Gardez l'ancienne IP publique dissociée plutôt que supprimée jusqu'à la fermeture de la fenêtre de repli, et notez les modifications de pair et de pare-feu pour pouvoir les annuler dans l'ordre.

• Contexte épinglé à l'abonnement propriétaire de la passerelle
• Ancienne IP publique conservée et ses dépendances notées
• Chaque connexion au vert et une vraie requête à travers
• Utilisateurs point à site basculés sur le profil actualisé
• Enregistrement DNS modifié et son ancienne valeur consignée