I Azure blir tre ulike objekt kalla gateway-adressa. Den private adressa blir tildelt frå GatewaySubnet. Den offentlege adressa er ein eigen offentleg IP-ressurs som IP-konfigurasjonen til gatewayen peikar på. Abonnementet og skymiljøet er konteksten skalet ditt brukar for å finne ein av dei. Endre éin, og dei to andre blir ståande — difor stoppar adressearbeid så ofte halvvegs.

Eg gjer desse endringane i fire trinn: inventer objekta, avgjer om den offentlege IP-en flyttar på den eksisterande gatewayen eller om gatewayen blir bygd på nytt, utfør endringa medan den gamle adressa enno er tilgjengeleg, og verifiser deretter kvar tunnel frå begge endar før noko blir sletta. Trinnet folk hoppar over, er inventaret.

Kva av dei tre objekta du faktisk endrar

Namngje objektet før du opnar portalen. Ein VPN-gateway tek den private adressa frå eit subnett som må heite nøyaktig GatewaySubnet, og Azure tildeler henne frå det prefikset; det finst ikkje noko generelt felt for å feste henne. Adressa verkar berre stabil fordi subnettet er stabilt. Endre adressa på subnettet eller bygg gatewayen på nytt, og ho flyttar med.

Den offentlege adressa kan redigerast, men SKU-reglar avgjer om redigeringa er lovleg. Ein Basic-gateway passar med ein Basic dynamisk offentleg IP, VpnGw-SKUar krev ein Standard statisk, og ein soneredundant gateway krev ein Standard offentleg IP med dei same sonene. Feil SKU blir avvist før ein tunnel fell.

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 noko flyttar seg

Prov abonnementet først, for resten av inventaret er verdlaust utan det. Registrer gatewayen, IP-konfigurasjonane og kvar tilkoping som endar på han, og oppbevar utdataa ved sida 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-ar tyder meir enn namn. Ei tilkoping held referansar til gatewayen og til ein lokal nettverksgateway, og desse ID-ane dukkar opp i skript, varsel og policytildelingar som ingen hugsar. List også det som ligg utanfor Azure: DNS-namnet som peikar på adressa, tillatingslista til partnaren og filialbrannmuren som festar den gamle IP-en.

Bytte den offentlege IP-en på gatewayen som køyrer

Opprett erstatningsadressa først, i same region og med sona som passar gatewayen, og lat den gamle ressursen stå. Bygg deretter IP-konfigurasjonen på nytt og send oppdateringa i eitt kall. Kallet erstattar heile konfigurasjonssamlinga, så ein aktiv-aktiv gateway treng begge, elles held du på éin tunnel og mistar 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

Tunnelar fell medan gatewayen blir klargjord på nytt. Fjernsida treng planen: ein partnerbrannmur tilbyr framleis den gamle adressa til nokon redigerer han, og ei tilkoping der fjernenden ventar på førre IP, blir liggjande nede uansett kor sunn Azure ser ut. Senk DNS-TTL før vindauget.

Punkt-til-område-klientar treng ein ny profil, fordi pakken som blir lasta ned, ber endepunktet. Eit eige DNS-namn framfor gatewayen sparer deg for redistribusjonen: hald namnet, endre posten.

Flytte gatewayen til eit anna abonnement

Ei ressursflytting flyttar eit sett, og gatewayen åleine er det minst nyttige medlemmet. Det virtuelle nettverket, dei offentlege IP-ressursane, dei lokale nettverksgatewayane og tilkoplingane reiser saman fordi kvar held ein referanse til ein annan. Målabonnementet må liggje i same tenant, Microsoft.Network må vere registrert der, og du treng skrivetilgang på begge sider.

Valideringa køyrer før noko blir endra, så ei avvist flytting lèt ressursane stå. Difor fortener flyttinga eit forsøk før ein gjenoppbygging: ei vellukka flytting tek den offentlege IP-en med, så partnarar og tillatingslister held fram med å verke, medan ein gjenoppbygd gateway sjeldan gjev same 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 ein valideringsfeil i staden for å prøve på nytt. Dei vanlege årsakene er ein etterlaten avhengnad, ein ressurstype som ikkje kan flyttast, eller ein lås på ei av ressursgruppene. Viss flyttinga er umogeleg, bygg på nytt i målet og kutt over: stadfest ruting og autentisering frå eit testsubnett, stopp dei gamle tilkoplingane i staden for å slette dei, og fjern deretter den gamle vegen i eit seinare vindauge.

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

Ikkje funnen-feilen er som regel ein omfangsfeil. Ein konto med fleire abonnement peikar ein cmdlet mot det feil, og meldinga gjev ressursen skulda. Slå opp objektet med full ressurs-ID i staden: ID-en ber sitt eige abonnement, så viss han blir løyst, manglar ingenting og standardkonteksten din er feil.

To fleire avvik blir lesne likt. Ein kommersiell sky-gateway finst ikkje i ei økt retta mot eit offentleg eller kinesisk miljø, og eldre modulversjonar overser ressursformer API-et allereie returnerer. Fest abonnementet, match miljøet, og opne deretter ei 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 frå begge endar før du ryddar

Tilkopla er ein tilstand, ikkje prov. Sjekk tunnelstatus per tilkoping, BGP-peer-status viss du køyrer dynamisk ruting, og effektive ruter på eit arbeidslastsubnett. Send deretter éi reell førespurnad gjennom eit program som er avhengig av tunnelen. Ei tilkoping kan rapportere tilkopla medan prefikset du treng manglar i rutetabellen.

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

Hald den gamle offentlege IP-en fråkopla i staden for sletta til tilbakefallsvindauget stengjer, og skriv ned partnar- og brannmurredigeringane slik at dei kan reverserast i rekkjefølgje.

  • Kontekst fest til abonnementet som eig gatewayen
  • Gammal offentleg IP halden, avhengnadene skrivne ned
  • Kvar tilkoping grøn og éi reell førespurnad gjennom
  • Punkt-til-område-brukarar flytta til den oppdaterte profilen
  • DNS-post endra og den førre verdien registrert

Relaterte artiklar