Cambiare l'IP pubblico di un gateway VPN Azure e spostare la sottoscrizione

In Azure tre oggetti diversi rispondono al nome di indirizzo del gateway. L'indirizzo privato viene allocato da GatewaySubnet. L'indirizzo pubblico è una risorsa IP pubblica separata verso cui punta la configurazione IP del gateway. La sottoscrizione e l'ambiente cloud sono il contesto con cui la shell trova l'uno o l'altro. Cambiane uno e gli altri due restano dov'erano, ed è per questo che il lavoro sugli indirizzi si ferma tante volte a metà.

Eseguo queste modifiche in quattro fasi: inventariare gli oggetti, decidere se l'IP pubblico si sposta sul gateway esistente o se il gateway viene ricostruito, applicare la modifica mentre il vecchio indirizzo è ancora disponibile, e poi verificare ogni tunnel da entrambe le estremità prima di eliminare qualcosa. La fase che si salta è l'inventario.

Quale dei tre oggetti stai cambiando davvero

Nomina l'oggetto prima di aprire il portale. Un gateway VPN prende l'indirizzo privato da una subnet che deve chiamarsi esattamente GatewaySubnet, e Azure lo assegna da quel prefisso; non esiste un campo generale per fissarlo. L'indirizzo sembra stabile solo perché la subnet è stabile. Ri-indirizza la subnet o ricostruisci il gateway e si sposta con loro.

L'indirizzo pubblico è modificabile, ma le regole di SKU decidono se la modifica è lecita. Un gateway Basic si abbina a un IP pubblico dinamico Basic, le SKU VpnGw richiedono uno Standard statico e un gateway con ridondanza di zona richiede un IP pubblico Standard con le stesse zone. La SKU sbagliata viene rifiutata prima che un tunnel cada.

Inventario prima che qualcosa si muova

Dimostra prima la sottoscrizione, perché il resto dell'inventario non vale nulla senza. Registra il gateway, le sue configurazioni IP e ogni connessione che termina su di esso, e conserva l'output accanto al registro della modifica.

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

Gli ID delle risorse contano più dei nomi. Una connessione contiene riferimenti al gateway e a un gateway di rete locale, e quegli ID compaiono in script, avvisi e assegnazioni di criteri che nessuno ricorda. Elenca anche ciò che sta fuori da Azure: il nome DNS che risolve all'indirizzo, la lista di permessi del partner, il firewall della filiale che fissa il vecchio IP.

Sostituire l'IP pubblico sul gateway in esecuzione

Crea prima l'indirizzo sostitutivo, nella stessa area e con l'insieme di zone che corrisponde al gateway, e lascia la vecchia risorsa al suo posto. Poi ricostruisci la configurazione IP e invia l'aggiornamento con una sola chiamata. Quella chiamata sostituisce l'intera raccolta di configurazioni, quindi un gateway attivo-attivo ne richiede due, altrimenti tieni un tunnel e perdi l'altro.

$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

I tunnel cadono mentre il gateway viene riprovisionato. Il lato remoto ha bisogno della pianificazione: un firewall partner continua a offrire il vecchio indirizzo finché qualcuno non lo modifica, e una connessione il cui estremo remoto attende l'IP precedente resta giù per quanto Azure sembri sano. Abbassa il TTL DNS prima della finestra.

I client point-to-site richiedono un nuovo profilo, perché il pacchetto scaricato porta l'endpoint. Un nome DNS personalizzato davanti al gateway ti risparmia la ridistribuzione: mantieni il nome, cambia il record.

Spostare il gateway in un'altra sottoscrizione

Lo spostamento di risorse trasferisce un insieme, e il gateway da solo ne è il membro meno utile. La rete virtuale, le risorse IP pubbliche, i gateway di rete locale e le connessioni viaggiano insieme perché ognuno detiene un riferimento a un altro. La sottoscrizione di destinazione deve stare nello stesso tenant, Microsoft.Network deve esservi registrato, e serve accesso in scrittura su entrambi i lati.

La convalida viene eseguita prima di qualsiasi modifica, quindi uno spostamento rifiutato lascia le risorse al loro posto. Per questo lo spostamento merita un tentativo prima di una ricostruzione: uno spostamento riuscito porta con sé l'IP pubblico, così i peer e le liste di permessi continuano a funzionare, mentre un gateway ricostruito raramente restituisce lo stesso indirizzo.

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

Leggi l'errore di convalida invece di ripeterlo. Le cause abituali sono una dipendenza lasciata indietro, un tipo di risorsa che non può essere spostato o un blocco su uno dei gruppi di risorse. Se lo spostamento è impossibile, ricostruisci nella destinazione e passa: conferma routing e autenticazione da una subnet di test, ferma le vecchie connessioni invece di eliminarle, poi rimuovi il vecchio percorso in una finestra successiva.

Quando il gateway sembra mancare, controlla il contesto

L'errore non trovato è di solito un errore di ambito. Un account con più sottoscrizioni punta un cmdlet su quella sbagliata, e il messaggio incolpa la risorsa. Cerca invece l'oggetto per il suo ID di risorsa completo: l'ID porta la propria sottoscrizione, quindi se si risolve non manca nulla e il tuo contesto predefinito è sbagliato.

Altri due disallineamenti si leggono allo stesso modo. Un gateway di cloud commerciale non esiste in una sessione rivolta a un ambiente governativo o cinese, e le versioni più vecchie dei moduli non vedono forme di risorsa che l'API già restituisce. Fissa la sottoscrizione, allinea l'ambiente, poi apri un caso.

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

Verifica da entrambe le estremità prima di pulire

Connesso è uno stato, non una prova. Controlla lo stato del tunnel per connessione, lo stato del peer BGP se usi il routing dinamico e le route effettive su una subnet di carico. Poi passa una richiesta reale attraverso un'applicazione che dipende dal tunnel. Una connessione può dichiararsi connessa mentre il prefisso che ti serve manca dalla tabella di routing.

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

Mantieni il vecchio IP pubblico dissociato invece che eliminato finché la finestra di fallback non si chiude, e annota le modifiche a peer e firewall così da poterle annullare in ordine.

• Contesto fissato alla sottoscrizione proprietaria del gateway
• Vecchio IP pubblico conservato e le sue dipendenze annotate
• Ogni connessione verde e una richiesta reale attraverso
• Utenti point-to-site passati al profilo aggiornato
• Record DNS modificato e il suo valore precedente annotato