Skift af offentlig IP på Azure VPN-gateway og flytning af abonnement

Runbook til at udskifte en VPN-gateways offentlige IP og flytte den mellem abonnementer, med inventar, tilbagerulning og kontekstkontroller, der holder tunnelerne oppe.

Tre forskellige objekter kaldes gateway-adressen i Azure. Den private adresse tildeles fra GatewaySubnet. Den offentlige adresse er en separat offentlig IP-ressource, som gatewayens IP-konfiguration peger på. Abonnementet og cloudmiljøet er den kontekst, din shell bruger til at finde en af dem. Skift den ene, og de to andre bliver, hvor de var — derfor stopper adresserarbejde så ofte halvvejs.

Jeg laver disse ændringer i fire faser: inventér objekterne, beslut om den offentlige IP flytter med den eksisterende gateway eller gatewayen genopbygges, anvend ændringen, mens den gamle adresse stadig er ved hånden, og verificér derefter hver tunnel fra begge ender, før noget slettes. Den fase, folk springer over, er inventaret.

Hvilket af de tre objekter du faktisk ændrer

Navngiv objektet, før du åbner portalen. En VPN-gateway tager sin private adresse fra et subnet, der skal hedde præcis GatewaySubnet, og Azure tildeler den fra det præfiks; der findes ikke et generelt felt til at fastlåse den. Adressen ser kun stabil ud, fordi subnettet er stabilt. Genadressér subnettet, eller genopbyg gatewayen, og den flytter med.

Den offentlige adresse kan redigeres, men SKU-regler afgør, om redigeringen er lovlig. En Basic-gateway passer med en Basic dynamisk offentlig IP, VpnGw-SKU'er kræver en Standard statisk, og en zoneredundant gateway kræver en Standard offentlig IP med de samme zoner. Den forkerte SKU afvises, før en tunnel falder.

ObjectWhere it livesWhat a change forces
Private addressGatewaySubnet prefix, assigned at deploymentSubnet resize or rebuild, then routes, NSGs and peer review
Public addressPublic IP resource referenced by the IP configurationGateway reprovision, peer and allowlist edits, new client profiles
Subscription contextYour PowerShell or CLI sessionNothing in Azure, and it clears most not-found errors

Inventar, før noget flytter sig

Bevis først abonnementet, for resten af inventaret er værdiløst uden det. Registrér gatewayen, dens IP-konfigurationer og hver forbindelse, der ender på den, og gem outputtet ved siden af ændringsregistreringen.

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

Ressource-ID'er betyder mere end navne. En forbindelse holder referencer til gatewayen og til en lokal netværksgateway, og disse ID'er dukker op i scripts, alarmer og politikktildelinger, som ingen husker. List også det, der ligger uden for Azure: DNS-navnet, der peger på adressen, partnerens tilladelsesliste, filialfirewallen, der fastholder den gamle IP.

Udskiftning af den offentlige IP på den kørende gateway

Opret erstatningsadressen først, i samme region og med det zonesæt, der passer til gatewayen, og lad den gamle ressource blive. Genopbyg derefter IP-konfigurationen, og send opdateringen i ét kald. Det kald erstatter hele konfigurationssamlingen, så en aktiv-aktiv gateway kræver begge, ellers beholder du en tunnel og mister den anden.

$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

Tunneler falder, mens gatewayen genoprettes. Den fjerne side skal have planen: en partnerfirewall bliver ved med at tilbyde den gamle adresse, indtil nogen redigerer den, og en forbindelse, hvis fjerne ende forventer den forrige IP, forbliver nede, uanset hvor sund Azure ser ud. Sænk DNS-TTL før vinduet.

Point-to-site-klienter skal have en ny profil, fordi den downloadede pakke bærer endepunktet. Et eget DNS-navn foran gatewayen sparer dig redistributionen: behold navnet, skift posten.

Flytning af gatewayen til et andet abonnement

En ressourceflytning flytter et sæt, og gatewayen alene er dets mindst nyttige medlem. Det virtuelle netværk, de offentlige IP-ressourcer, de lokale netværksgateways og forbindelserne rejser sammen, fordi hver især holder en reference til en anden. Målabonnementet skal ligge i samme tenant, Microsoft.Network skal være registreret der, og du skal have skriveadgang på begge sider.

Valideringen kører, før noget ændres, så en afvist flytning lader ressourcerne blive. Derfor fortjener flytningen et forsøg før en genopbygning: en vellykket flytning tager den offentlige IP med, så peers og tilladelseslister fortsat virker, mens en genopbygget gateway sjældent giver samme adresse tilbage.

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 en valideringsfejl i stedet for at prøve igen. De sædvanlige årsager er en efterladt afhængighed, en ressourcetype, der ikke kan flyttes, eller en lås på en af ressourcegrupperne. Hvis flytningen er umulig, genopbyg i målet, og skift over: bekræft routing og godkendelse fra et testsubnet, stop de gamle forbindelser i stedet for at slette dem, og fjern derefter den gamle vej i et senere vindue.

Når gatewayen ser ud til at mangle, kontrollér konteksten

Ikke fundet-fejlen er som regel en scope-fejl. En konto med flere abonnementer peger en cmdlet på det forkerte, og meddelelsen giver ressourcen skylden. Slå objektet op på dets fulde ressource-ID i stedet: ID'et bærer sit eget abonnement, så hvis det kan slås op, mangler der intet, og din standardkontekst er forkert.

To flere uoverensstemmelser læses ens. En kommerciel cloud-gateway findes ikke i en session rettet mod et offentligt eller kinesisk miljø, og ældre modulversioner overser ressourceformer, som API'et allerede returnerer. Fastlås abonnementet, match miljøet, og åbn så en sag.

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

Verificér fra begge ender, før du rydder op

Forbundet er en tilstand, ikke et bevis. Tjek tunnelstatus pr. forbindelse, BGP-peer-status, hvis du kører dynamisk routing, og effektive ruter på et arbejdsbelastningssubnet. Pres derefter en rigtig anmodning gennem et program, der afhænger af tunnelen. En forbindelse kan rapportere forbundet, mens det præfiks, du har brug for, mangler i rutetabellen.

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

Hold den gamle offentlige IP uden tilknytning i stedet for slettet, indtil tilbagerulningsvinduet lukker, og skriv peer- og firewall-ændringerne ned, så de kan tilbageføres i rækkefølge.

  • Kontekst fastlåst til det abonnement, der ejer gatewayen
  • Gammel offentlig IP bevaret, dens afhængigheder skrevet ned
  • Hver forbindelse grøn plus én rigtig anmodning igennem
  • Point-to-site-brugere flyttet til den opdaterede profil
  • DNS-post ændret, og dens tidligere værdi registreret

Relaterede artikler