Byta offentlig IP på Azure VPN-gateway och flytta prenumerationen

I Azure kallas tre olika objekt för gateway-adressen. Den privata adressen tilldelas från GatewaySubnet. Den offentliga adressen är en egen offentlig IP-resurs som gatewayens IP-konfiguration pekar på. Prenumerationen och molnmiljön är den kontext som ditt skal använder för att hitta endera. Ändra en och de två andra står kvar — därför stannar adressarbete så ofta halvvägs.

Jag gör dessa ändringar i fyra steg: inventera objekten, avgöra om den offentliga IP:n flyttar på den befintliga gatewayen eller om gatewayen byggs om, utföra ändringen medan den gamla adressen ännu finns kvar, och sedan verifiera varje tunnel från båda sidor innan något raderas. Steget folk hoppar över är inventeringen.

Vilket av de tre objekten du faktiskt ändrar

Namnge objektet innan du öppnar portalen. En VPN-gateway tar sin privata adress från ett undernät som måste heta exakt GatewaySubnet, och Azure tilldelar den från det prefixet; det finns inget allmänt fält för att låsa den. Adressen verkar bara stabil för att undernätet är stabilt. Byt adress på undernätet eller bygg om gatewayen och den följer med.

Den offentliga adressen är redigerbar, men SKU-regler avgör om redigeringen är tillåten. En Basic-gateway passar med en Basic dynamisk offentlig IP, VpnGw-SKU:er kräver en Standard statisk, och en zonredundant gateway kräver en Standard offentlig IP med samma zoner. Fel SKU avvisas innan en tunnel faller.

Inventering innan något rör sig

Bevisa först prenumerationen, för resten av inventeringen är värdelös utan den. Registrera gatewayen, dess IP-konfigurationer och varje anslutning som slutar på den, och förvara utdata bredvid ändringsprotokollet.

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

Resurs-ID:n betyder mer än namn. En anslutning håller referenser till gatewayen och till en lokal nätverksgateway, och dessa ID:n dyker upp i skript, larm och policytilldelningar som ingen minns. Lista också det som ligger utanför Azure: DNS-namnet som pekar på adressen, partnerns tillåtelselista och filialbrandväggen som låser den gamla IP:n.

Byta den offentliga IP:n på den körande gatewayen

Skapa först ersättningsadressen, i samma region och med den zonuppsättning som passar gatewayen, och låt den gamla resursen stå kvar. Bygg sedan om IP-konfigurationen och skicka uppdateringen i ett enda anrop. Anropet ersätter hela konfigurationssamlingen, så en aktiv-aktiv gateway behöver båda, annars behåller du en tunnel och tappar den andra.

$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

Tunnlarna faller medan gatewayen provisioneras om. Fjärrsidan behöver planen: en partnerbrandvägg fortsätter erbjuda den gamla adressen tills någon redigerar den, och en anslutning vars fjärrände väntar sig den förra IP:n ligger kvar nere hur frisk Azure än ser ut. Sänk DNS-TTL före fönstret.

Punkt-till-plats-klienter behöver en ny profil, eftersom paketet som laddas ner bär slutpunkten. Ett eget DNS-namn framför gatewayen sparar omdistributionen: behåll namnet, ändra posten.

Flytta gatewayen till en annan prenumeration

En resursflytt flyttar en uppsättning, och gatewayen ensam är dess minst användbara medlem. Det virtuella nätverket, de offentliga IP-resurserna, de lokala nätverksgatewayerna och anslutningarna reser tillsammans eftersom var och en håller en referens till en annan. Målprenumerationen måste ligga i samma klient, Microsoft.Network måste vara registrerat där, och du behöver skrivåtkomst på båda sidor.

Valideringen körs innan något ändras, så en avvisad flytt lämnar resurserna kvar. Därför förtjänar flytten ett försök före en ombyggnad: en lyckad flytt tar den offentliga IP:n med sig, så partners och tillåtelselistor fortsätter fungera, medan en ombyggd gateway sällan ger samma adress tillbaka.

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

Läs ett valideringsfel i stället för att upprepa det. Vanliga orsaker är ett kvarlämnat beroende, en resurstyp som inte kan flyttas eller ett lås på någon av resursgrupperna. Om flytten är omöjlig, bygg om i målet och växla över: bekräfta routning och autentisering från ett testundernät, stoppa de gamla anslutningarna i stället för att radera dem, och ta sedan bort den gamla vägen i ett senare fönster.

När gatewayen verkar saknas, kontrollera kontexten

Felet hittades inte är oftast ett omfångsfel. Ett konto med flera prenumerationer riktar en cmdlet mot fel prenumeration, och meddelandet skyller på resursen. Slå upp objektet med dess fullständiga resurs-ID i stället: ID:t bär sin egen prenumeration, så om det löses upp saknas inget och din standardkontext är fel.

Ytterligare två avvikelser läses likadant. En kommersiell molngateway finns inte i en session riktad mot en myndighets- eller Kinamiljö, och äldre modulversioner missar resursformer som API:t redan returnerar. Fäst prenumerationen, matcha miljön och öppna sedan ett ärende.

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

Verifiera från båda sidor innan du städar

Ansluten är ett tillstånd, inte ett bevis. Kontrollera tunnelstatus per anslutning, BGP-peerstatus om du kör dynamisk routning, och effektiva rutter på ett arbetslastundernät. Skicka sedan en riktig begäran genom ett program som är beroende av tunneln. En anslutning kan rapportera ansluten medan det prefix du behöver saknas i rutttabellen.

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

Håll den gamla offentliga IP:n frånkopplad i stället för raderad tills återställningsfönstret stänger, och skriv ner partner- och brandväggsändringarna så att de kan återställas i ordning.

• Kontext fäst vid prenumerationen som äger gatewayen
• Gammal offentlig IP bevarad, dess beroenden nedskrivna
• Varje anslutning grön plus en riktig begäran igenom
• Punkt-till-plats-användare flyttade till den uppdaterade profilen
• DNS-post ändrad och dess tidigare värde registrerat