Eseguire la migrazione di gateway di app Azure lication e web application firewall da V1 a V2

  • Articolo

È stata annunciata la deprecazione di gateway applicazione SKU V1 (Standard e WAF) il 28 aprile 2023. Lo SKU V1 viene ritirato il 28 aprile 2026. Per altre informazioni, vedere Eseguire la migrazione dei gateway applicazione dallo SKU V1 allo SKU V2 entro il 28 aprile 2026.

app Azure lication Gateway e Web Application Firewall (WAF) V2 offrono ora funzionalità aggiuntive, ad esempio scalabilità automatica, disponibilità, ridondanza della zona, prestazioni più elevate, operazioni più veloci e velocità effettiva migliorata rispetto alla versione 1. Inoltre, tutte le nuove funzionalità vengono rilasciate per lo SKU V2. È consigliabile creare ora un piano di migrazione.

I gateway V1 non vengono aggiornati automaticamente alla versione 2. Usare questa guida alla migrazione per pianificare ed eseguire le migrazioni.

In una migrazione sono presenti due fasi:

  1. Eseguire la migrazione della configurazione
  2. Eseguire la migrazione del traffico client

Questo articolo è utile principalmente per la migrazione della configurazione. La migrazione del traffico client varia a seconda dell'ambiente. In questo articolo vengono fornite alcune raccomandazioni generali.

Prerequisiti

  • Un account Azure con una sottoscrizione attiva. Creare un account gratuitamente.
  • Un gateway applicazione standard V1 esistente.
  • Assicurarsi di avere i moduli di PowerShell più recenti oppure di usare Azure Cloud Shell nel portale.
  • Se si esegue PowerShell in locale, è anche necessario eseguire Connect-AzAccount per creare una connessione con Azure.
  • Assicurarsi che non sia presente alcun gateway applicazione con il nome appGW V2 specificato e il nome del gruppo di risorse nella sottoscrizione V1. Questa operazione riscrive le risorse esistenti.
  • Se viene specificato un indirizzo IP pubblico, assicurarsi che si tratti di uno stato completato. Se non specificato e AppGWResourceGroupName viene fornito assicurarsi che la risorsa IP pubblica con nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.
  • Assicurarsi che nessun'altra operazione sia pianificata nel gateway V1 o nelle risorse associate durante la migrazione.

Azure Cloud Shell

Azure Cloud Shell è un ambiente di shell interattivo ospitato in Azure e usato tramite il browser. È possibile usare Bash o PowerShell con Cloud Shell per usare i servizi di Azure. È possibile usare i comandi preinstallati di Cloud Shell per eseguire il codice in questo articolo, senza dover installare alcun elemento nell'ambiente locale.

Per avviare Azure Cloud Shell:

Opzione Esempio/Collegamento
Selezionare Prova nell'angolo superiore destro di un codice o di un blocco di comandi. Selezionando Prova non viene copiato automaticamente il codice o il comando in Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Passare a https://shell.azure.com o selezionare il pulsante Avvia Cloud Shell per aprire Cloud Shell nel browser. Button to launch Azure Cloud Shell.
Selezionare il pulsante Cloud Shell nella barra dei menu nell'angolo in alto a destra del portale di Azure. Screenshot that shows the Cloud Shell button in the Azure portal

Per usare Azure Cloud Shell:

  1. Avviare Cloud Shell.

  2. Selezionare il pulsante Copia in un blocco di codice (o blocco di comandi) per copiare il codice o il comando.

  3. Incollare il codice o il comando nella sessione di Cloud Shell selezionando CTRL+MAIUSC+V in Windows e Linux oppure selezionando CMD+MAIUSC+V in macOS.

  4. Selezionare INVIO per eseguire il codice o il comando.

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Importante

Eseguire il Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet ogni volta prima di eseguire lo script di migrazione. Questo è necessario per impostare il contesto di Azure attivo sulla sottoscrizione corretta, perché lo script di migrazione potrebbe pulire il gruppo di risorse esistente se non esiste nel contesto della sottoscrizione corrente. Questo non è un passaggio obbligatorio per la versione 1.0.11 e successive dello script di migrazione.

Importante

È ora disponibile una nuova versione stabile dello script di migrazione, la versione 1.0.11, che contiene importanti correzioni di bug e aggiornamenti. Usare questa versione per evitare potenziali problemi.

Migrazione della configurazione

In questo documento viene fornito uno script di Azure PowerShell. Esegue le operazioni seguenti per semplificare la configurazione:

  • Crea un nuovo gateway Standard_V2 o WAF_V2 in una subnet di rete virtuale specificata.
  • Copia facilmente la configurazione associata al gateway V1 Standard o WAF nel gateway Standard_V2 o WAF_V2 appena creato.

Download dello script

È possibile scaricare lo script di migrazione da PowerShell Gallery. È disponibile una nuova versione stabile (versione 1.0.11) dello script di migrazione, che include aggiornamenti e correzioni di bug principali. È consigliabile usare questa versione stabile.

Uso dello script

Nota

Eseguire il Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet ogni volta prima di eseguire lo script di migrazione. Questo è necessario per impostare il contesto di Azure attivo sulla sottoscrizione corretta, perché lo script di migrazione potrebbe pulire il gruppo di risorse esistente se non esiste nel contesto della sottoscrizione corrente. Questo non è un passaggio obbligatorio per la versione 1.0.11 e successive dello script di migrazione.

Sono disponibili due opzioni a seconda della configurazione e delle preferenze dell'ambiente PowerShell locale:

  • Se non sono installati i moduli Az di Azure o non è consigliabile disinstallare i moduli Az di Azure, l'opzione migliore consiste nell'usare l'opzione Install-Script per eseguire lo script.
  • Se è necessario mantenere i moduli Az di Azure, la scelta migliore consiste nel scaricare lo script ed eseguirlo direttamente.

Per determinare se sono installati i moduli Az di Azure, eseguire Get-InstalledModule -Name az. Se non vengono visualizzati moduli Az installati, è possibile usare il Install-Script metodo .

Per usare questa opzione, non è necessario che nel computer siano installati i moduli Az di Azure. Se sono installati, il comando seguente visualizza un errore. È possibile disinstallare i moduli Az di Azure oppure usare l'altra opzione per scaricare manualmente lo script ed eseguirlo.

Eseguire lo script con il comando seguente per ottenere la versione più recente:

Install-Script -Name AzureAppGWMigration -Force

Questo comando installa anche i moduli Az necessari.

Eseguire l'installazione usando direttamente lo script

Se sono installati alcuni moduli Az di Azure e non è possibile disinstallarli (o non disinstallarli), è possibile scaricare manualmente lo script usando la scheda Download manuale nel collegamento per il download dello script. Lo script viene scaricato come file nupkg non elaborato. Per installare lo script da questo file nupkg, vedere Download manuale dei pacchetti.

La versione 1.0.11 è la nuova versione dello script di migrazione che include importanti correzioni di bug. È consigliabile usare questa versione stabile.

Come controllare la versione dello script scaricato

Per controllare la versione dello script scaricato, i passaggi sono i seguenti:

  • Estrarre il contenuto del pacchetto NuGet.
  • Aprire il .PS1 file nella cartella e controllare nella .VERSION parte superiore per confermare la versione dello script scaricato
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Come eseguire lo script

Per eseguire lo script:

  1. Usare Connect-AzAccount per connettersi ad Azure.

  2. Usare Import-Module Az per importare i moduli Az.

  3. Eseguire il Set-AzContext cmdlet per impostare il contesto di Azure attivo sulla sottoscrizione corretta. Questo è un passaggio importante perché lo script di migrazione potrebbe pulire il gruppo di risorse esistente se non esiste nel contesto della sottoscrizione corrente.

    Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'

  4. Eseguire Get-Help AzureAppGWMigration.ps1 per esaminare i parametri obbligatori:

    AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Nota

Durante la migrazione non tentare altre operazioni sul gateway V1 o sulle risorse associate.

Parametri per lo script:

  • resourceId: [String]: obbligatorio: questo parametro è l'ID risorsa di Azure per il gateway V1 standard o WAF V1 esistente. Per trovare questo valore stringa, passare alla portale di Azure, selezionare il gateway applicazione o la risorsa WAF e fare clic sul collegamento Proprietà per il gateway. L'ID risorsa si trova in tale pagina.

    È anche possibile eseguire i comandi di Azure PowerShell seguenti per ottenere l'ID risorsa:

    $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id

  • subnetAddressRange: [String]: obbligatorio: questo parametro è lo spazio di indirizzi IP allocato (o si vuole allocare) per una nuova subnet che contiene il nuovo gateway V2. Lo spazio indirizzi deve essere specificato nella notazione CIDR. Ad esempio: 10.0.0.0/24. Non è necessario creare questa subnet in anticipo, ma il CIDR deve far parte dello spazio indirizzi della rete virtuale. Lo script lo crea automaticamente se non esiste e, se esistente, usa quello esistente ( assicurarsi che la subnet sia vuota, contenga solo il gateway V2, se presente, e abbia sufficienti indirizzi IP disponibili).

  • appgwName: [String]: Facoltativo. Si tratta di una stringa specificata da usare come nome per il nuovo gateway Standard_V2 o WAF_V2. Se questo parametro non viene specificato, il nome del gateway V1 esistente viene usato con il suffisso _V2 aggiunto.

  • AppGWResourceGroupName: [String]: Facoltativo. Nome del gruppo di risorse in cui si desidera creare le risorse V2 gateway applicazione (il valore predefinito è <V1-app-gw-rgname>)

Nota

Assicurarsi che non sia presente alcun gateway applicazione con il nome appGW V2 specificato e il nome del gruppo di risorse nella sottoscrizione V1. Questa operazione riscrive le risorse esistenti.

  • sslCertificates: [PSApplicationGatewaySslCertificate]: facoltativo. Un elenco delimitato da virgole di oggetti PSApplicationGatewaySslCertificate creati per rappresentare i certificati TLS/SSL dal gateway V1 deve essere caricato nel nuovo gateway V2. Per ogni certificato TLS/SSL configurato per il gateway V1 standard o WAF V1, è possibile creare un nuovo oggetto PSApplicationGatewaySslCertificate tramite il New-AzApplicationGatewaySslCertificate comando illustrato qui. È necessario il percorso del file di certificato TLS/SSL e della password.

    Questo parametro è facoltativo solo se non sono configurati listener HTTPS per il gateway V1 o WAF. Se è disponibile almeno una configurazione del listener HTTPS, è necessario specificare questo parametro.

    $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password

    È possibile passare $mySslCert1, $mySslCert2 (delimitato da virgole) nell'esempio precedente come valori per questo parametro nello script.

  • sslCertificates da KeyVault: facoltativo. È possibile scaricare i certificati archiviati in Azure Key Vault e passarlo allo script di migrazione. Per scaricare il certificato come file PFX, eseguire questo comando. Questi comandi accedono a SecretId e quindi salvano il contenuto come file PFX.

     $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

    Per ogni certificato scaricato dall'insieme di credenziali delle chiavi, è possibile creare un nuovo oggetto PSApplicationGatewaySslCertificate tramite il comando New-AzApplicationGatewaySslCertificate illustrato qui. È necessario il percorso del file di certificato TLS/SSL e della password.

    //Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

  • trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: facoltativo. Elenco delimitato da virgole di oggetti PSApplicationGatewayTrustedRootCertificate creati per rappresentare i certificati radice attendibili per l'autenticazione delle istanze back-end dal gateway v2.

    $certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath

    Per creare un elenco di oggetti PSApplicationGatewayTrustedRootCertificate, vedere New-AzApplicationGatewayTrustedRootCertificate.

  • privateIpAddress: [String]: Facoltativo. Indirizzo IP privato specifico da associare al nuovo gateway V2. Deve trovarsi dalla stessa rete virtuale allocata per il nuovo gateway V2. Se non viene specificato, lo script alloca un indirizzo IP privato per il gateway V2.

  • publicIpResourceId: [String]: facoltativo. ResourceId della risorsa dell'indirizzo IP pubblico esistente (SKU standard) nella sottoscrizione da allocare al nuovo gateway V2. Se viene specificato il nome della risorsa IP pubblico, assicurarsi che esista nello stato riuscito. Se non viene specificato, lo script alloca un nuovo indirizzo IP pubblico nello stesso gruppo di risorse. Il nome è il nome del gateway V2 con -IP aggiunto. Se viene specificato AppGWResourceGroupName e non viene specificato un indirizzo IP pubblico, assicurarsi che la risorsa IP pubblica con nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.

  • validateMigration: [switch]: facoltativo. Usare questo parametro per abilitare lo script per eseguire alcune convalide di confronto di configurazione di base dopo la creazione del gateway V2 e la copia della configurazione. Per impostazione predefinita, non viene eseguita alcuna convalida.

  • enableAutoScale: [switch]: facoltativo. Usare questo parametro per abilitare la scalabilità automatica nello script nel nuovo gateway V2 dopo la creazione. Per impostazione predefinita, la scalabilità automatica è disabilitata. È sempre possibile abilitarlo manualmente in un secondo momento nel gateway V2 appena creato.

  1. Eseguire lo script usando i parametri appropriati. Il completamento dell'operazione può richiedere da cinque a sette minuti.

    Esempio

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Avvertenze\Limitazioni

  • Il nuovo gateway V2 ha nuovi indirizzi IP pubblici e privati. Non è possibile spostare facilmente gli indirizzi IP associati al gateway V1 esistente in V2. Tuttavia, è possibile allocare un indirizzo IP pubblico (non allocato) esistente o privato al nuovo gateway V2.
  • È necessario fornire uno spazio indirizzi IP per un'altra subnet all'interno della rete virtuale in cui si trova il gateway V1. Lo script non può creare il gateway V2 in una subnet che dispone già di un gateway V1. Se la subnet dispone già di un gateway V2, lo script potrebbe funzionare, purché sia disponibile spazio di indirizzi IP sufficiente.
  • Se si dispone di un gruppo di sicurezza di rete o di route definite dall'utente associate alla subnet del gateway V2, assicurarsi che siano conformi ai requisiti del gruppo di sicurezza di rete e alla route definita dall'utente per una corretta migrazione
  • I criteri degli endpoint servizio di rete virtuale non sono attualmente supportati in una subnet del gateway applicazione.
  • Per eseguire la migrazione di una configurazione TLS/SSL, è necessario specificare tutti i certificati TLS/SSL usati nel gateway V1.
  • Se la modalità FIPS è abilitata per il gateway V1, non viene eseguita la migrazione al nuovo gateway V2. La modalità FIPS non è supportata nella versione 2.
  • Se si dispone di un gateway IP privato solo V1, lo script genera un indirizzo IP privato e pubblico per il nuovo gateway V2. Il gateway privato solo V2 è attualmente in anteprima pubblica. Quando diventa disponibile a livello generale, i clienti possono usare lo script per trasferire il proprio gateway IP privato solo V1 a un gateway IP privato solo V2.
  • L'autenticazione NTLM e Kerberos non è supportata da gateway applicazione V2. Lo script non è in grado di rilevare se il gateway gestisce questo tipo di traffico e può comportare una modifica che causa un'interruzione dai gateway da V1 a V2 se in esecuzione.
  • WAFv2 viene creato in modalità di configurazione WAF precedente; è necessaria la migrazione ai criteri WAF.

Migrazione del traffico

Prima di tutto, verificare che lo script sia stato creato correttamente un nuovo gateway V2 con la configurazione esatta migrata dal gateway V1. È possibile verificarlo dal portale di Azure.

Inviare anche una piccola quantità di traffico attraverso il gateway V2 come test manuale.

Di seguito sono riportati alcuni scenari in cui il gateway applicazione corrente (Standard) può ricevere traffico client e le raccomandazioni per ognuna:

  • Zona DNS personalizzata (ad esempio, contoso.com) che punta all'indirizzo IP front-end (usando un record A) associato al gateway V1 standard o WAF V1.

    È possibile aggiornare il record DNS in modo che punti all'indirizzo IP front-end o all'etichetta DNS associata al gateway applicazione Standard_V2. A seconda della durata (TTL) configurata nel record DNS, la migrazione del traffico client al nuovo gateway V2 potrebbe richiedere del tempo.

  • Una zona DNS personalizzata (ad esempio, contoso.com) che punta all'etichetta DNS (ad esempio: myappgw.eastus.cloudapp.azure.com usando un record CNAME) associata al gateway V1.

    Sono disponibili due opzioni:

    • Se si usano indirizzi IP pubblici nel gateway applicazione, è possibile eseguire una migrazione controllata e granulare usando un profilo Gestione traffico per instradare in modo incrementale il traffico (metodo di routing del traffico ponderato) al nuovo gateway V2.

      A tale scopo, è possibile aggiungere le etichette DNS dei gateway applicazione V1 e V2 al profilo di Gestione traffico e CNAMEing del record DNS personalizzato (ad esempio, www.contoso.com) al dominio Gestione traffico (ad esempio, contoso.trafficmanager.net).

    • In alternativa, è possibile aggiornare il record DNS di dominio personalizzato in modo che punti all'etichetta DNS del nuovo gateway applicazione V2. A seconda della durata (TTL) configurata nel record DNS, la migrazione del traffico client al nuovo gateway V2 potrebbe richiedere del tempo.

  • I client si connettono all'indirizzo IP front-end del gateway applicazione.

    Aggiornare i client per usare gli indirizzi IP associati al gateway applicazione V2 appena creato. È consigliabile non usare direttamente gli indirizzi IP. Prendere in considerazione l'uso dell'etichetta del nome DNS (ad esempio, yourgateway.eastus.cloudapp.azure.com) associata al gateway applicazione che è possibile usare CNAME nella propria zona DNS personalizzata, ad esempio contoso.com.

Considerazioni sui prezzi

I modelli di determinazione dei prezzi sono diversi per gli SKU gateway applicazione V1 e V2. La versione 2 viene addebitata in base al consumo. Per informazioni sui prezzi, vedere gateway applicazione prezzi prima della migrazione.

Linee guida per l'efficienza dei costi

Lo SKU V2 include una serie di vantaggi, ad esempio un aumento delle prestazioni di 5 volte, una maggiore sicurezza con l'integrazione di Key Vault, aggiornamenti più rapidi delle regole di sicurezza in WAF_V2, regole personalizzate WAF, associazioni di criteri e protezione bot. Offre anche scalabilità elevata, routing del traffico ottimizzato e integrazione senza problemi con i servizi di Azure. Queste funzionalità possono migliorare l'esperienza utente complessiva, evitare rallentamenti durante i periodi di traffico elevato ed evitare violazioni dei dati costose.

Sono disponibili cinque varianti nello SKU V1 in base al livello e alle dimensioni: Standard_Small, Standard_Medium, Standard_Large, WAF_Medium e WAF_Large.

SKU V1 Prezzo fisso/mo V2 Fixed Price/mo Elemento consigliato
Standard Medio 102.2 179.8 Lo SKU V2 può gestire un numero maggiore di richieste rispetto a un gateway V1, quindi è consigliabile consolidare più gateway V1 in un singolo gateway V2 per ottimizzare i costi. Assicurarsi che il consolidamento non superi i limiti gateway applicazione. È consigliabile consolidare 3:1.
WAF Medium 183.96 262.8 Uguale a per Standard Medium
Standard Large 467.2 179.58 Per queste varianti, nella maggior parte dei casi, il passaggio a un gateway V2 può offrire un vantaggio migliore rispetto alla versione 1.
WAF di grandi dimensioni 654.08 262.8 Uguale a per Standard Large

Nota

I calcoli illustrati di seguito sono basati su Stati Uniti orientali e per un gateway con 2 istanze nella versione 1. Il costo della variabile nella versione 2 si basa su una delle 3 dimensioni con utilizzo più elevato: nuove connessioni (50/sec), connessioni persistenti (2500 connessioni persistenti/min), velocità effettiva (1 CU può gestire 2,22 Mbps).

Gli scenari descritti di seguito sono esempi e sono solo a scopo illustrativo. Per informazioni sui prezzi in base all'area geografica, vedere la pagina Prezzi.

Per ulteriori dubbi sui prezzi, collaborare con il CSAM o contattare il team di supporto per assistenza.

Domande frequenti

Domande comuni sulla migrazione sono disponibili qui

Passaggi successivi

Informazioni su gateway applicazione V2