Ŝanĝi publikan IP de Azure VPN-pordego kaj transloki abonon
Gvidilo por anstataŭigi la publikan IP de VPN-pordego kaj transloki ĝin inter abonoj, kun la inventaro, retropaŝo kaj kuntekstaj kontroloj, kiuj tenas tunelojn funkciantaj.
En Azure tri malsamaj objektoj nomiĝas la pordega adreso. La privata adreso asigniĝas el GatewaySubnet. La publika adreso estas aparta publika IP-rimedo, al kiu montras la IP-agordo de la pordego. La abono kaj nuba medio estas la kunteksto, per kiu via ŝelo trovas unu aŭ la alian. Ŝanĝu unu kaj la aliaj du restas, kie ili estis — tial adreslaboro tiel ofte haltas duonvoje.
Mi faras tiujn ŝanĝojn en kvar etapoj: inventari la objektojn, decidi ĉu la publika IP moviĝas sur la ekzistantan pordegon aŭ la pordego rekonstruiĝas, apliki la ŝanĝon dum la malnova adreso ankoraŭ estas havebla, poste kontroli ĉiun tunelon de ambaŭ flankoj antaŭ ol forigi ion. La etapo, kiun homoj preterlasas, estas la inventaro.
Kiun el la tri objektoj vi vere ŝanĝas
Nomu la objekton antaŭ ol malfermi la portalon. VPN-pordego prenas sian privatan adreson el subreto, kiu devas nomiĝi ekzakte GatewaySubnet, kaj Azure asignas ĝin el tiu prefikso; ne ekzistas ĝenerala kampo por fiksi ĝin. La adreso ŝajnas stabila nur ĉar la subreto estas stabila. Readresu la subreton aŭ rekonstruu la pordegon kaj ĝi moviĝas kun ili.
La publika adreso estas redaktebla, sed SKU-reguloj decidas ĉu la redakto estas laŭleĝa. Basic-pordego pariĝas kun Basic dinamika publika IP, VpnGw-SKUoj bezonas Standard statikan, kaj zone redunda pordego bezonas Standard publikan IP kun la samaj zonoj. La malĝusta SKU malakceptiĝas antaŭ ol tunelo falas.
| Object | Where it lives | What a change forces |
|---|---|---|
| Private address | GatewaySubnet prefix, assigned at deployment | Subnet resize or rebuild, then routes, NSGs and peer review |
| Public address | Public IP resource referenced by the IP configuration | Gateway reprovision, peer and allowlist edits, new client profiles |
| Subscription context | Your PowerShell or CLI session | Nothing in Azure, and it clears most not-found errors |
Inventaro antaŭ ol io ajn moviĝas
Unue pruvu la abonon, ĉar sen ĝi la resto de la inventaro senvaloras. Registru la pordegon, ĝiajn IP-agordojn kaj ĉiun konekton, kiu finiĝas sur ĝi, kaj konservu la eligon apud la ŝanĝprotokolo.
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
Rimedaj IDoj gravas pli ol nomoj. Konekto tenas referencojn al la pordego kaj al loka reta pordego, kaj tiuj IDoj aperas en skriptoj, alarmoj kaj politikaj asignoj, kiujn neniu memoras. Listigu ankaŭ tion, kio staras ekster Azure: la DNS-nomo, kiu kondukas al la adreso, la permeslisto de la partnero, la filia fajroŝirmilo, kiu fiksas la malnovan IP.
Anstataŭigi la publikan IP sur la funkcianta pordego
Unue kreu la anstataŭan adreson, en la sama regiono kaj kun la zonaro, kiu kongruas al la pordego, kaj lasu la malnovan rimedon surloke. Poste rekonstruu la IP-agordon kaj puŝu la ĝisdatigon per unu alvoko. Tiu alvoko anstataŭigas la tutan agordan kolekton, do aktiva-aktiva pordego bezonas ambaŭ, alie vi retenas unu tunelon kaj perdas la alian.
$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
Tuneloj falas dum la pordego reproviziĝas. La fora flanko bezonas planadon: partnera fajroŝirmilo plu proponas la malnovan adreson ĝis iu redaktas ĝin, kaj konekto, kies fora fino atendas la antaŭan IP, restas malsupre kiom ajn sana Azure aspektas. Malaltigu la DNS-TTL antaŭ la fenestro.
Punkto-al-ejo-klientoj bezonas novan profilon, ĉar la elŝutita pakaĵo portas la finpunkton. Propra DNS-nomo antaŭ la pordego ŝparas al vi la redistribuon: konservu la nomon, ŝanĝu la rikordon.
Transloki la pordegon al alia abono
Translokigo de rimedoj movas aron, kaj la pordego sola estas ĝia malplej utila membro. La virtuala reto, publikaj IP-rimedoj, lokaj retaj pordegoj kaj konektoj veturas kune ĉar ĉiu tenas referencon al alia. La cela abono devas esti en la sama luanto, Microsoft.Network devas esti registrita tie, kaj vi bezonas skriban aliron ambaŭflanke.
Validado kuras antaŭ ol io ajn ŝanĝiĝas, do malakceptita translokigo lasas la rimedojn surloke. Tial la translokigo indas provon antaŭ rekonstruo: sukcesa translokigo portas la publikan IP kun si, do partneroj kaj permeslistoj plu funkcias, dum rekonstruita pordego malofte redonas la saman adreson.
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
Legu validadan malsukceson anstataŭ ripeti ĝin. La kutimaj kaŭzoj estas lasita dependeco, rimeda tipo, kiu ne povas moviĝi, aŭ ŝlosilo sur unu el la rimedaj grupoj. Se la translokigo neeblas, rekonstruu en la celo kaj transiru: konfirmu enkursigadon kaj aŭtentikigon el testa subreto, haltigu la malnovajn konektojn anstataŭ forigi ilin, poste forigu la malnovan vojon en posta fenestro.
Kiam la pordego ŝajnas manki, kontrolu la kuntekston
La eraro ne trovita kutime estas ampleksa eraro. Konto kun pluraj abonoj direktas cmdleton al la malĝusta, kaj la mesaĝo kulpigas la rimedon. Serĉu la objekton per ĝia plena rimeda ID: la ID portas sian propran abonon, do se ĝi solviĝas, nenio mankas kaj via defaŭlta kunteksto malĝustas.
Du pliaj malkongruoj legiĝas same. Komerca-nuba pordego ne ekzistas en sesio celanta registaran aŭ ĉinan medion, kaj pli malnovaj modulversioj maltrafas rimedajn formojn, kiujn la API jam redonas. Fiksu la abonon, kongruigu la medion, poste malfermu kazon.
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
Kontrolu de ambaŭ flankoj antaŭ purigado
Konektita estas stato, ne pruvo. Kontrolu tunelan staton po konekto, BGP-peer-staton se vi uzas dinamikan enkursigadon, kaj efektivajn vojojn sur labortega subreto. Poste pasigu unu realan peton tra aplikaĵo, kiu dependas de la tunelo. Konekto povas raporti sin konektita dum la bezonata prefikso mankas en la vojtabelo.
Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app
Tenu la malnovan publikan IP malkonektita anstataŭ forigita ĝis la retrofenestro fermiĝas, kaj skribu la partnerajn kaj fajroŝirmilajn redaktojn tiel, ke ili retroveblas laŭorde.
- Kunteksto fiksita al la abono, kiu posedas la pordegon
- Malnova publika IP konservita, ĝiaj dependecoj notitaj
- Ĉiu konekto verda kaj unu reala peto tra ĝi
- Punkto-al-ejo-uzantoj movitaj al la refreŝigita profilo
- DNS-rikordo ŝanĝita kaj ĝia antaŭa valoro notita