I Azure kalles tre forskjellige objekter for gateway-adressen. Den private adressen tildeles fra GatewaySubnet. Den offentlige adressen er en egen offentlig IP-ressurs som gatewayens IP-konfigurasjon peker på. Abonnementet og skyrmiljøet er konteksten skallet ditt bruker for å finne en av dem. Endre én, og de to andre blir stående — derfor stopper adressarbeid så ofte halvveis.

Jeg gjør disse endringene i fire trinn: inventer objektene, avgjør om den offentlige IP-en flytter på den eksisterende gatewayen eller om gatewayen bygges på nytt, utfør endringen mens den gamle adressen fortsatt er tilgjengelig, og verifiser deretter hver tunnel fra begge ender før noe slettes. Trinnet folk hopper over, er inventaret.

Hvilket av de tre objektene du faktisk endrer

Navngi objektet før du åpner portalen. En VPN-gateway tar den private adressen fra et subnett som må hete nøyaktig GatewaySubnet, og Azure tildeler den fra det prefikset; det finnes ikke noe generelt felt for å feste den. Adressen virker bare stabil fordi subnettet er stabilt. Endre adressen på subnettet eller bygg gatewayen på nytt, og den flytter med.

Den offentlige adressen kan redigeres, men SKU-regler avgjør om redigeringen er lovlig. En Basic-gateway passer med en Basic dynamisk offentlig IP, VpnGw-SKUer krever en Standard statisk, og en soneredundant gateway krever en Standard offentlig IP med de samme sonene. Feil SKU avvises før en tunnel faller.

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 noe flytter seg

Bevis abonnementet først, for resten av inventaret er verdiløst uten det. Registrer gatewayen, IP-konfigurasjonene og hver tilkobling som ender på den, og oppbevar utdataene ved siden av endringsprotokollen.

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

Ressurs-ID-er betyr mer enn navn. En tilkobling holder referanser til gatewayen og til en lokal nettverksgateway, og disse ID-ene dukker opp i skript, varsler og policytildelinger som ingen husker. List også det som ligger utenfor Azure: DNS-navnet som peker på adressen, partnerens tillatelsesliste og filialbrannmuren som fester den gamle IP-en.

Bytte den offentlige IP-en på gatewayen som kjører

Opprett erstatningsadressen først, i samme region og med sonen som passer gatewayen, og la den gamle ressursen stå. Bygg deretter IP-konfigurasjonen på nytt og send oppdateringen i ett kall. Kallet erstatter hele konfigurasjonssamlingen, så en aktiv-aktiv gateway trenger begge, ellers beholder du én tunnel og mister den andre.

$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 faller mens gatewayen klargjøres på nytt. Fjernsiden trenger planen: en partnerbrannmur tilbyr fortsatt den gamle adressen til noen redigerer den, og en tilkobling der fjernenden forventer forrige IP, blir liggende nede uansett hvor sunn Azure ser ut. Senk DNS-TTL før vinduet.

Punkt-til-område-klienter trenger en ny profil, fordi pakken som lastes ned, bærer endepunktet. Et eget DNS-navn foran gatewayen sparer deg for redistribusjonen: behold navnet, endre posten.

Flytte gatewayen til et annet abonnement

En ressursflytting flytter et sett, og gatewayen alene er det minst nyttige medlemmet. Det virtuelle nettverket, de offentlige IP-ressursene, de lokale nettverksgatewayene og tilkoblingene reiser sammen fordi hver holder en referanse til en annen. Målabonnementet må ligge i samme tenant, Microsoft.Network må være registrert der, og du trenger skrivetilgang på begge sider.

Valideringen kjører før noe endres, så en avvist flytting lar ressursene stå. Derfor fortjener flyttingen et forsøk før en gjenoppbygging: en vellykket flytting tar den offentlige IP-en med, så partnere og tillatelseslister fortsetter å virke, mens en gjenoppbygd gateway sjelden gir samme adresse tilbake.

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

Les en valideringsfeil i stedet for å prøve på nytt. De vanlige årsakene er en etterlatt avhengighet, en ressurstype som ikke kan flyttes, eller en lås på en av ressursgruppene. Hvis flyttingen er umulig, bygg på nytt i målet og kutt over: bekreft ruting og autentisering fra et testsubnett, stopp de gamle tilkoblingene i stedet for å slette dem, og fjern deretter den gamle veien i et senere vindu.

Når gatewayen ser ut til å mangle, sjekk konteksten

Ikke funnet-feilen er som regel en omfangsfeil. En konto med flere abonnementer peker en cmdlet mot det feil, og meldingen gir ressursen skylden. Slå opp objektet med full ressurs-ID i stedet: ID-en bærer sitt eget abonnement, så hvis den løses, mangler ingenting og standardkonteksten din er feil.

To flere avvik leses likt. En kommersiell sky-gateway finnes ikke i en økt rettet mot et offentlig eller kinesisk miljø, og eldre modulversjoner overser ressursformer API-et allerede returnerer. Fest abonnementet, match miljøet, og åpne deretter en sak.

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

Verifiser fra begge ender før du rydder

Tilkoblet er en tilstand, ikke bevis. Sjekk tunnelstatus per tilkobling, BGP-peer-status hvis du kjører dynamisk ruting, og effektive ruter på et arbeidslastsubnett. Send deretter én reell forespørsel gjennom et program som avhenger av tunnelen. En tilkobling kan rapportere tilkoblet mens prefikset du trenger mangler i rutetabellen.

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

Hold den gamle offentlige IP-en frakoblet i stedet for slettet til tilbakefallsvinduet stenger, og skriv ned partner- og brannmurredigeringene slik at de kan reverseres i rekkefølge.

  • Kontekst festet til abonnementet som eier gatewayen
  • Gammel offentlig IP beholdt, avhengighetene skrevet ned
  • Hver tilkobling grønn og én reell forespørsel gjennom
  • Punkt-til-område-brukere flyttet til den oppdaterte profilen
  • DNS-post endret og den forrige verdien registrert

Relaterte artikler