Pagpapalit ng pampublikong IP ng Azure VPN gateway at paglipat ng subscription

Sa Azure, tatlong magkaibang bagay ang tinatawag na address ng gateway. Ang pribadong address ay inilalaan mula sa GatewaySubnet. Ang pampublikong address ay hiwalay na resource ng pampublikong IP na tinutukoy ng IP configuration ng gateway. Ang subscription at cloud environment ang kontekstong ginagamit ng shell mo para hanapin ang isa sa dalawa. Palitan ang isa at mananatili ang dalawa, kaya madalas huminto sa kalagitnaan ang trabaho sa address.

Ginagawa ko ang mga pagbabagong ito sa apat na yugto: imbentaryo ng mga bagay, desisyon kung lilipat ang pampublikong IP sa umiiral na gateway o muling itatayo ang gateway, paglalapat ng pagbabago habang hawak pa ang lumang address, at pagkatapos ay pagpapatunay ng bawat tunnel mula sa dalawang dulo bago magbura ng anuman. Ang yugtong nilalaktawan ay ang imbentaryo.

Alin sa tatlong bagay ang talagang binabago mo

Pangalanan ang bagay bago buksan ang portal. Kumukuha ang VPN gateway ng pribadong address mula sa subnet na dapat eksaktong GatewaySubnet ang pangalan, at inilalaan ito ng Azure mula sa prefix na iyon; walang pangkalahatang field para i-pin ito. Mukhang stable ang address dahil lang stable ang subnet. Muling i-address ang subnet o itayo muli ang gateway at lilipat ito kasama nila.

Naiedit ang pampublikong address, ngunit ang mga patakaran ng SKU ang nagpapasya kung legal ang edit. Ang Basic gateway ay tumutugma sa Basic dynamic na pampublikong IP, kailangan ng VpnGw SKU ng Standard static, at kailangan ng zone-redundant gateway ng Standard na pampublikong IP na may parehong zone. Ang maling SKU ay tinatanggihan bago pa bumagsak ang tunnel.

Imbentaryo bago gumalaw ang anuman

Patunayan muna ang subscription, dahil walang halaga ang natitirang imbentaryo kung wala iyon. Itala ang gateway, ang mga IP configuration nito at bawat koneksyong nagtatapos dito, at itabi ang output sa tabi ng talaan ng pagbabago.

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

Mas mahalaga ang mga resource ID kaysa pangalan. May hawak na sanggunian ang koneksyon sa gateway at sa lokal na network gateway, at lumilitaw ang mga ID na iyon sa mga script, alerto at pagtatalaga ng patakaran na walang nakakaalala. Ilista rin ang nasa labas ng Azure: ang DNS name na tumuturo sa address, ang listahan ng pahintulot ng partner, at ang firewall ng sangay na nagpupin sa lumang IP.

Pagpapalit ng pampublikong IP sa tumatakbong gateway

Gumawa muna ng kapalit na address, sa parehong rehiyon at may set ng zone na tugma sa gateway, at iwanan ang lumang resource sa kinaroroonan. Pagkatapos ay itayo muli ang IP configuration at ipadala ang update sa isang tawag. Pinapalitan ng tawag na iyon ang buong koleksyon ng configuration, kaya kailangan ng active-active gateway ang dalawa, kung hindi isang tunnel ang natitira at nawala ang isa.

$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

Bumabagsak ang mga tunnel habang muling inihahanda ang gateway. Kailangan ng malayong panig ng iskedyul: patuloy na iniaalok ng firewall ng partner ang lumang address hanggang may mag-edit nito, at ang koneksyong inaasahan ng malayong dulo ang dating IP ay mananatiling down gaano man kagaling ang Azure. Ibaba ang TTL ng DNS bago ang window.

Kailangan ng mga point-to-site client ng bagong profile, dahil dala ng na-download na pakete ang endpoint. Ang custom na DNS name sa harap ng gateway ay nakakatipid sa muling pamimigay: itago ang pangalan, palitan ang record.

Paglipat ng gateway sa ibang subscription

Inililipat ng resource move ang isang set, at ang gateway mag-isa ang pinakamaliit na kapaki-pakinabang na miyembro nito. Magkasamang naglalakbay ang virtual network, mga pampublikong IP resource, lokal na network gateway at mga koneksyon dahil may hawak na sanggunian ang bawat isa sa iba. Dapat nasa parehong tenant ang target na subscription, dapat nakarehistro doon ang Microsoft.Network, at kailangan mo ng write access sa dalawang panig.

Tumatakbo ang validation bago magbago ang anuman, kaya iniiwan ng tinanggihang paglipat ang mga resource sa kinaroroonan. Kaya karapat-dapat subukan ang paglipat bago ang muling pagtatayo: dinadala ng matagumpay na paglipat ang pampublikong IP, kaya patuloy na gumagana ang mga partner at listahan ng pahintulot, samantalang ang muling itinayong gateway ay bihirang ibalik ang parehong address.

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

Basahin ang kabiguan ng validation sa halip na ulitin ito. Karaniwang sanhi ang naiwang dependency, uri ng resource na hindi mailipat, o lock sa alinman sa mga resource group. Kung imposible ang paglipat, itayo muli sa target at lumipat: kumpirmahin ang routing at authentication mula sa test subnet, itigil ang lumang koneksyon sa halip na burahin, at pagkatapos ay alisin ang lumang landas sa susunod na window.

Kapag parang nawawala ang gateway, suriin ang konteksto

Ang error na hindi mahanap ay karaniwang error sa saklaw. Ang account na may maraming subscription ay nagtuturo ng cmdlet sa mali, at sinisisi ng mensahe ang resource. Hanapin ang bagay sa pamamagitan ng buong resource ID: dala ng ID ang sariling subscription, kaya kung malutas ito, walang nawawala at mali ang default na konteksto mo.

Dalawang iba pang hindi pagkakatugma ang parehong mababasa. Walang commercial cloud gateway sa session na nakatuon sa government o China environment, at ang lumang module version ay nakakaligta ng mga anyo ng resource na ibinabalik na ng API. I-pin ang subscription, itugma ang environment, at pagkatapos ay magbukas ng kaso.

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

I-verify mula sa dalawang dulo bago maglinis

Ang konektado ay estado, hindi ebidensya. Suriin ang estado ng tunnel kada koneksyon, estado ng BGP peer kung gumagamit ng dynamic routing, at epektibong ruta sa workload subnet. Pagkatapos ay magpadala ng isang tunay na kahilingan sa aplikasyong umaasa sa tunnel. Maaaring mag-ulat ang koneksyon na konektado habang wala ang kailangan mong prefix sa routing table.

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

Panatilihing disconnected ang lumang pampublikong IP sa halip na burahin hanggang magsara ang fallback window, at isulat ang mga edit sa partner at firewall upang maibalik ito nang maayos.

• Naka-pin ang konteksto sa subscription na nagmamay-ari ng gateway
• Itinago ang lumang pampublikong IP at naisulat ang mga dependency
• Berde ang bawat koneksyon at may isang tunay na kahilingan dito
• Inilipat ang mga point-to-site user sa na-update na profile
• Binago ang DNS record at naitala ang dating halaga