Het openbare IP van een Azure VPN-gateway wijzigen en het abonnement verplaatsen

In Azure heten drie verschillende objecten het gateway-adres. Het privéadres wordt uit GatewaySubnet toegewezen. Het openbare adres is een aparte openbare IP-resource waar de IP-configuratie van de gateway naar wijst. Het abonnement en de cloudomgeving zijn de context waarmee je shell een van beide vindt. Wijzig er één en de andere twee blijven staan, daarom stopt adreswerk zo vaak halverwege.

Ik doe deze wijzigingen in vier fasen: de objecten inventariseren, beslissen of het openbare IP op de bestaande gateway meeverhuist of de gateway opnieuw wordt gebouwd, de wijziging doorvoeren terwijl het oude adres nog binnen handbereik is, en dan elke tunnel van beide kanten verifiëren voordat er iets wordt verwijderd. De fase die men overslaat, is de inventaris.

Welk van de drie objecten je werkelijk wijzigt

Benoem het object voordat je de portal opent. Een VPN-gateway haalt zijn privéadres uit een subnet dat precies GatewaySubnet moet heten, en Azure wijst het uit dat prefix toe; er is geen algemeen veld om het vast te pinnen. Het adres lijkt alleen stabiel omdat het subnet stabiel is. Heradresseer het subnet of bouw de gateway opnieuw en het schuift mee.

Het openbare adres is bewerkbaar, maar SKU-regels bepalen of de bewerking is toegestaan. Een Basic-gateway past bij een dynamisch openbaar Basic-IP, VpnGw-SKU's vereisen een statisch Standard-IP, en een zoneredundante gateway vereist een openbaar Standard-IP met dezelfde zones. De verkeerde SKU wordt geweigerd voordat een tunnel valt.

Inventaris voordat er iets beweegt

Bewijs eerst het abonnement, want de rest van de inventaris is waardeloos zonder. Leg de gateway, zijn IP-configuraties en elke verbinding die erop eindigt vast, en bewaar de uitvoer naast het wijzigingsrecord.

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

Resource-ID's tellen zwaarder dan namen. Een verbinding houdt verwijzingen naar de gateway en naar een lokaal netwerkgateway, en die ID's duiken op in scripts, waarschuwingen en beleidstoewijzingen die niemand onthoudt. Inventariseer ook wat buiten Azure ligt: de DNS-naam die naar het adres wijst, de toelatingslijst van de partner, de filiaal-firewall die het oude IP vastzet.

Het openbare IP op de draaiende gateway vervangen

Maak eerst het vervangende adres aan, in dezelfde regio en met de zoneset die bij de gateway past, en laat de oude resource staan. Bouw daarna de IP-configuratie opnieuw en stuur de update in één aanroep. Die aanroep vervangt de hele configuratieverzameling, dus een actief-actief gateway heeft beide nodig, anders behoud je één tunnel en verlies je de andere.

$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

Tunnels vallen terwijl de gateway opnieuw wordt ingericht. De andere kant heeft de planning nodig: een partnerfirewall blijft het oude adres aanbieden tot iemand die aanpast, en een verbinding waarvan de andere kant het vorige IP verwacht, blijft neer liggen hoe gezond Azure er ook uitziet. Verlaag de DNS-TTL vóór het venster.

Point-to-site-clients hebben een nieuw profiel nodig, omdat het gedownloade pakket het eindpunt draagt. Een eigen DNS-naam vóór de gateway bespaart je de herverdeling: houd de naam, wijzig het record.

De gateway naar een ander abonnement verplaatsen

Een resourceverhuizing verplaatst een set, en de gateway alleen is daarvan het minst nuttige lid. Het virtuele netwerk, de openbare IP-resources, de lokale netwerkgateways en de verbindingen reizen samen omdat elk een verwijzing naar een ander bevat. Het doelabonnement moet in dezelfde tenant staan, Microsoft.Network moet daar geregistreerd zijn, en je hebt schrijfrechten aan beide kanten.

De validatie draait voordat er iets verandert, dus een afgewezen verhuizing laat de resources staan. Daarom verdient de verhuizing een poging vóór een herbouw: een geslaagde verhuizing neemt het openbare IP mee, zodat partners en toelatingslijsten blijven werken, terwijl een herbouwde gateway zelden hetzelfde adres teruggeeft.

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

Lees een validatiefout in plaats van hem te herhalen. De gebruikelijke oorzaken zijn een achtergebleven afhankelijkheid, een resourcetype dat niet kan verhuizen, of een slot op een van de resourcegroepen. Als de verhuizing onmogelijk is, bouw dan in het doel opnieuw en schakel over: bevestig routing en authenticatie vanuit een testsubnet, stop de oude verbindingen in plaats van ze te verwijderen, en verwijder daarna het oude pad in een later venster.

Als de gateway lijkt te ontbreken, controleer de context

De niet-gevonden-fout is meestal een bereikfout. Een account met meerdere abonnementen richt een cmdlet op het verkeerde, en het bericht beschuldigt de resource. Zoek het object op via zijn volledige resource-ID: de ID draagt zijn eigen abonnement, dus als die wordt opgelost, ontbreekt er niets en is je standaardcontext verkeerd.

Twee andere mismatches lezen hetzelfde. Een commerciële cloud-gateway bestaat niet in een sessie gericht op een overheids- of China-omgeving, en oudere moduleversies missen resourcevormen die de API al teruggeeft. Pin het abonnement, stem de omgeving af en open dan een case.

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

Verifieer van beide kanten voordat je opruimt

Verbonden is een status, geen bewijs. Controleer de tunnelstatus per verbinding, de BGP-peerstatus als je dynamische routing gebruikt, en de effectieve routes op een workload-subnet. Stuur daarna één echt verzoek door een applicatie die van de tunnel afhangt. Een verbinding kan verbonden melden terwijl het prefix dat je nodig hebt ontbreekt in de routetabel.

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

Houd het oude openbare IP losgekoppeld in plaats van verwijderd tot het terugvalvenster sluit, en schrijf de partner- en firewallwijzigingen op zodat ze in volgorde kunnen worden teruggedraaid.

• Context vastgepind op het abonnement dat de gateway bezit
• Oud openbaar IP bewaard, de afhankelijkheden opgeschreven
• Elke verbinding groen plus één echt verzoek erdoor
• Point-to-site-gebruikers overgezet naar het vernieuwde profiel
• DNS-record gewijzigd en de vorige waarde vastgelegd