Migración de Azure Application Gateway y Web Application Firewall de V1 a V2

En este artículo, aprenderá a migrar Azure Application Gateway y Web Application Firewall (WAF) de V1 a V2 mediante scripts de Azure PowerShell. La migración tiene dos fases: migración de configuración y migración del tráfico. Puede usar el script de clonación mejorado (recomendado) o el script de clonación heredado para clonar la configuración de la puerta de enlace V1 en una nueva puerta de enlace V2 y, a continuación, redirigir el tráfico de cliente con un tiempo de inactividad mínimo.

¿Por qué migrar a la SKU V2?

Application Gateway y WAF V2 ofrecen las siguientes ventajas sobre V1:

• Resistencia: redundancia de zona de disponibilidad y escalabilidad automática.
• Security: integración de Azure Key Vault, funcionalidades de WAF mejoradas y protección de bots.
• Supervisión: supervisión completa del uso de CPU, memoria y disco (V1 solo admite CPU).
• Detección y mitigación automática : detección avanzada y mitigación automatizada que identifican y resuelven problemas sin intervención manual.
• Nuevas características — todas las nuevas características se publican solo para el SKU V2.

Las puertas de enlace V1 no se actualizan automáticamente a V2. Use esta guía para planear y llevar a cabo la migración.

Este artículo se centra en la fase de migración de configuración. La migración del tráfico de cliente varía según el entorno. Consulte las recomendaciones generales más adelante en este artículo.

Requisitos previos

• Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
• Una instancia de Application Gateway V1 Estándar existente.
• Los módulos de PowerShell más recientes o puede usar Azure Cloud Shell en el portal.
• Si ejecuta PowerShell localmente, ejecute Connect-AzAccount para crear una conexión con Azure.
• No hay ninguna puerta de enlace de aplicaciones con el nombre de AppGW V2 y el nombre del grupo de recursos proporcionados en la suscripción de V1. Esta condición impide volver a escribir los recursos existentes.
• Ninguna otra operación planeada en la puerta de enlace V1 ni en ningún recurso asociado durante el proceso de migración.
• Si proporciona una dirección IP pública, asegúrese de que se encuentra en un estado exitoso. Si no proporciona una dirección IP pública, pero proporciona AppGWResourceGroupName, asegúrese de que el recurso ip público con el nombre AppGWV2Name-IP no existe en un grupo de recursos con el nombre AppGWResourceGroupName en la suscripción V1.
• Para la SKU V1, se requieren certificados de autenticación para configurar conexiones TLS con servidores back-end. La SKU V2 requiere cargar certificados raíz de confianza para el mismo propósito. Aunque V1 permite el uso de certificados autofirmados como certificados de autenticación, V2 exige generar y cargar un certificado raíz autofirmado si se usan certificados autofirmados en el back-end.

Azure Cloud Shell

Azure hospeda Azure Cloud Shell, un entorno de shell interactivo que puede usar a través del explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con servicios de Azure. Puede usar los comandos Cloud Shell preinstalados para ejecutar el código de este artículo, sin tener que instalar nada en el entorno local.

Para iniciar Azure Cloud Shell:

Opción	Ejemplo o vínculo
Seleccione Pruébelo en la esquina superior derecha de un bloque de código o de comandos. Al seleccionar Try It no se copia automáticamente el código ni el comando en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Launch Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la parte superior derecha del portal Azure.

Para usar Azure Cloud Shell:

1. Inicie Cloud Shell.

2. Seleccione el botón Copiar en un bloque de código (o bloque de comandos) para copiar el código o comando.

3. Pegue el código o comando en la sesión de Cloud Shell seleccionando Ctrl+Shift+V en Windows y Linux, o seleccionando Cmd+Shift+V en macOS.

4. Seleccione Enter para ejecutar el código o comando.

Migración de configuración

La migración de configuración se centra en configurar la nueva puerta de enlace V2 con la configuración del entorno V1 existente. Los dos scripts de Azure PowerShell facilitan la migración de configuraciones de V1 (Estándar o WAF) a puertas de enlace V2 (Standard_V2 o WAF_V2). Estos scripts ayudan a simplificar el proceso de transición mediante la automatización de las tareas clave de implementación y configuración.

Script de clonación mejorada: recomendado

El script de clonación mejorada es la opción recomendada, que ofrece una experiencia de migración mejorada mediante:

• Eliminar la necesidad de introducir manualmente certificados SSL de front-end y certificados raíz de confianza de back-end.
• Apoyo al despliegue de puertas de enlace V2 exclusivamente privadas.

Puede descargar el script de clonación mejorada del Galería de PowerShell.

Parámetros para el script: Este script toma los parámetros siguientes:

• AppGw V1 ResourceId -Required: Este parámetro es el identificador de recurso de Azure para su puerta de enlace existente de Standard V1 o WAF V1. Para buscar este valor de cadena, vaya al portal de Azure, seleccione la puerta de enlace de aplicaciones o el recurso waf y seleccione el vínculo Properties de la puerta de enlace. El identificador de recurso se encuentra en esa página. También puede ejecutar los siguientes comandos Azure PowerShell para obtener el identificador de recurso:

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

• SubnetAddressRange -Required: la dirección de subred en notación CIDR, donde se va a implementar Application Gateway V2
• AppGwName -Optional: nombre de la puerta de enlace de aplicaciones V2. Valor predeterminado = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Optional: nombre del grupo de recursos donde se creará La puerta de enlace de aplicaciones V2. Si no se proporciona, se usa el grupo de recursos de Application Gateway V1.
• PrivateIPAddress -Opcional: dirección IP privada que se va a asignar a Application Gateway V2. Si no se proporciona, se asignará una dirección IP privada aleatoria.
• ValidateBackendHealth -Optional: Validación posterior a la migración mediante la comparación de la respuesta de ApplicationGatewayBackendHealth. Si no se establece, se omitirá esta validación.
• PublicIpResourceId -opcional: si la resourceId de la dirección IP pública ya existe, se puede asociar a la puerta de enlace de aplicación. Si no se proporciona, el nombre de dirección IP pública será {AppGwName}-IP.
• DisableAutoscale -Optional: Deshabilitación de la configuración de escalado automático para instancias de Application Gateway V2, false de forma predeterminada
• WafPolicyName -Optional: nombre de la directiva waf que se creará a partir de la configuración de WAF V1 y se asociará a la puerta de enlace de WAF V2.

Ejecución del script

Para ejecutar el script:

1. Use Connect-AzAccount para conectarse a Azure.
2. Use para importar los módulos de Az.
3. Ejecute el cmdlet Set-AzContext para establecer el contexto de Azure activo en la suscripción correcta. Este es un paso importante porque el script de migración podría limpiar el grupo de recursos existente si no existe en el contexto de la suscripción actual.

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

4. Instale el script siguiendo los pasos descritos en Instalación de script.
5. Ejecute el script con los parámetros adecuados. El script puede tardar entre cinco y siete minutos en finalizar.

   ./AzureAppGWClone.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>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   Ejemplo

   ./AzureAppGWClone.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   

Recommendations

• Después de completar el script, revise la configuración de la puerta de enlace V2 en el portal de Azure y pruebe la conectividad enviando tráfico directamente a la dirección IP de la puerta de enlace V2.
• El script relaja la validación TLS de back-end de forma predeterminada (sin cadena de certificados, expiración o validación de SNI) durante la clonación. Si se requieren certificados de autenticación o validación tls más estrictos, puede actualizar Application Gateway V2 después de la creación para agregar certificados raíz de confianza y habilitar esta característica según sea necesario.
• Para el paso a través de NTLM/Kerberos, establezca la conexión de back-end dedicada en "true" en la configuración HTTP después de la clonación.

Advertencias

• Debe proporcionar un espacio de direcciones IP para otra subred dentro de la red virtual en la que está ubicada la puerta de enlace V1. El script no puede crear la puerta de enlace V2 en una subred que ya tenga una puerta de enlace V1. Si la subred ya tiene una puerta de enlace V2, es posible que el script siga funcionando, siempre que haya suficiente espacio de direcciones IP disponible.
• Si tiene un grupo de seguridad de red o rutas definidas por el usuario asociadas a la subred de puerta de enlace V2, asegúrese de que se ajusta a los requisitos de grupo de seguridad de red y a los requisitos de UDR para que la migración se realice correctamente
• Si tiene el modo FIPS habilitado para la puerta de enlace V1, no se migrará a la nueva puerta de enlace V2.
• El nuevo WAF V2 está configurado para usar CRS 3.0 de forma predeterminada. Sin embargo, dado que CRS 3.0 está en la ruta de desuso, actualice al conjunto de reglas más reciente, DRS 2.2, después de la migración. Para obtener más información, consulte los grupos de reglas de CRS y DRS, así como sus reglas.

Script de clonación heredada

El script de clonación heredado facilita la transición mediante:

• Creación de una nueva Standard_V2 o WAF_V2 Application Gateway en una subred de red virtual especificada por el usuario.
• Copia automáticamente la configuración desde una puerta de enlace estándar o WAF V1 existente a la puerta de enlace V2 recién creada.
• Requerir que proporcione certificados TLS/SSL y autenticación como entrada. Este script no admite puertas de enlace V2 exclusivamente privadas. Puede descargar este script de clonación desde el Galería de PowerShell

Parámetros para el script: El script heredado toma los parámetros siguientes:

• resourceId: [String]: Required: Este parámetro es el identificador de recurso de Azure para su puerta de enlace existente Standard V1 o WAF V1. Para buscar este valor de cadena, vaya al portal de Azure, seleccione la puerta de enlace de aplicaciones o el recurso waf y seleccione el vínculo Properties de la puerta de enlace. El identificador de recurso se encuentra en esa página. También puede ejecutar los siguientes comandos Azure PowerShell para obtener el identificador de recurso:

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

• subnetAddressRange: [String]: Required: este parámetro es el espacio de direcciones IP que ha asignado (o quiere asignar) para una nueva subred que contenga la nueva puerta de enlace V2. El espacio de direcciones debe especificarse en notación CIDR. Por ejemplo: 10.0.0.0/24. No es necesario crear esta subred de antemano, pero el CIDR debe formar parte del espacio de direcciones de la red virtual. El script lo crea automáticamente si no existe y, si existe, usará el existente (asegúrese de que la subred esté vacía, solo contenga la puerta de enlace V2 si existe y tenga suficientes direcciones IP disponibles).
• appgwName: [String]: Opcional. Se trata de una cadena que se especifica para su uso como nombre de la nueva puerta de enlace Standard_V2 o WAF_V2. Si no se proporciona este parámetro, se usará el nombre de la puerta de enlace V1 existente con el sufijo _V2 anexado.
• AppGWResourceGroupName: [String]: opcional. Nombre del grupo de recursos en el que desea que se creen los recursos de Application Gateway V2 (el valor predeterminado es )

• sslCertificates: [PSApplicationGatewaySslCertificate]: Opcional. La lista separada por comas de objetos PSApplicationGatewaySslCertificate que cree para representar los certificados TLS/SSL de la puerta de enlace V1 debe cargarse en la nueva puerta de enlace V2. Para cada uno de los certificados TLS/SSL configurados para la puerta de enlace Estándar V1 o WAF V1, puede crear un objeto PSApplicationGatewaySslCertificate con el comando que se muestra aquí. Necesita la ruta de acceso del archivo del certificado TLS/SSL y la contraseña.

  Este parámetro solo es opcional si no tiene clientes de escucha HTTPS configurados para la puerta de enlace V1 o WAF. Si tiene al menos un programa de instalación del agente de escucha HTTPS, debe especificar este parámetro.

       $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
  

  Puede pasar (separados por comas) en el ejemplo anterior como valores para este parámetro en el script.

• sslCertificates de Keyvault: Optional. Puede descargar los certificados almacenados en Azure Key Vault y pasarlos al script de migración. Para descargar el certificado en forma de archivo PFX, ejecute el siguiente comando. Estos comandos acceden a SecretId y, a continuación, guardan el contenido como un archivo 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)
  

  Para cada uno de los certificados descargados desde Keyvault, puede crear un nuevo objeto PSApplicationGatewaySslCertificate mediante el comando New-AzApplicationGatewaySslCertificate que se muestra aquí. Necesita la ruta de acceso del archivo del certificado TLS/SSL y la contraseña.

  //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]: Opcional. Se trata de una lista de objetos PSApplicationGatewayTrustedRootCertificate separados por comas que se crea para representar los certificados raíz de confianza para la autenticación de las instancias de back-end de la puerta de enlace v2.

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

  Para crear una lista de objetos PSApplicationGatewayTrustedRootCertificate, consulte New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: Opcional. Dirección IP privada específica que quiere asociar a la nueva puerta de enlace V2. Debe ser de la misma red virtual que asigne a la nueva puerta de enlace V2. Si esto no se especifica, el script asigna una dirección IP privada para la puerta de enlace V2.

• publicIpResourceId: [String]: Opcional. El identificador de recurso de una dirección IP pública existente (SKU estándar) en la suscripción que quiere asignar a la nueva puerta de enlace V2. Si se proporciona el nombre del recurso de IP pública, asegúrate de que existe en estado correcto. Si esto no se especifica, el script asigna una nueva dirección IP pública en el mismo grupo de recursos. El nombre es el mismo de la puerta de enlace V2 con -IP anexado. Si se proporciona AppGWResourceGroupName y no se proporciona una dirección IP pública, asegúrese de que el recurso ip público con el nombre AppGWV2Name-IP no existe en un grupo de recursos con el nombre AppGWResourceGroupName en la suscripción V1.

• validateMigration: [switch]: Opcional. Usa este parámetro para habilitar que el script realice algunas validaciones de comparación de la configuración básica tras la creación de la puerta de enlace V2 y la copia de la configuración. De forma predeterminada, no se realiza ninguna validación.

• enableAutoScale: [switch]: Opcional. Usa este parámetro para habilitar que el script habilite el escalado automático en la nueva puerta de enlace V2 después de crearla. De forma predeterminada, el escalado automático está deshabilitado. Puede habilitarlo manualmente más adelante en la puerta de enlace V2 recién creada.

Ejecución del script

Para ejecutar el script:

1. Use Connect-AzAccount para conectarse a Azure.
2. Use para importar los módulos de Az.
3. Ejecute el cmdlet Set-AzContext para establecer el contexto de Azure activo en la suscripción correcta. Este es un paso importante porque el script de migración podría limpiar el grupo de recursos existente si no existe en el contexto de la suscripción actual.

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

4. Instale el script siguiendo los pasos descritos en Instalación de script.
5. Ejecute para examinar los parámetros obligatorios:
6. Ejecute el script con los parámetros adecuados. El script puede tardar entre cinco y siete minutos en finalizar.

      ./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
   

   Ejemplo

      ./AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
      -validateMigration -enableAutoScale
   

Advertencias y limitaciones

• La nueva puerta de enlace V2 tiene nuevas direcciones IP públicas y privadas. No es posible mover fácilmente las direcciones IP asociadas a la puerta de enlace V1 existente a V2. Sin embargo, puede asignar una dirección IP pública o privada existente (sin asignar) a la nueva puerta de enlace V2.
• Debe proporcionar un espacio de direcciones IP para otra subred dentro de la red virtual en la que está ubicada la puerta de enlace V1. El script no puede crear la puerta de enlace V2 en una subred que ya tenga una puerta de enlace V1. Si la subred ya tiene una puerta de enlace V2, es posible que el script siga funcionando, siempre que haya suficiente espacio de direcciones IP disponible.
• Si tiene un grupo de seguridad de red o rutas definidas por el usuario asociadas a la subred de puerta de enlace V2, asegúrese de que cumplen los requisitos de NSG y los requisitos de UDR para una migración correcta.
• Actualmente, no se admiten directivas de punto de conexión de servicio de red virtual en una subred de Application Gateway.
• Para migrar una configuración de TLS/SSL, debe especificar todos los certificados TLS/SSL que se usan en la puerta de enlace V1.
• Si tiene el modo FIPS habilitado para la puerta de enlace V1, no se migrará a la nueva puerta de enlace V2.
• WAF V2 está creado en el modo de configuración de WAF antiguo; se requiere la migración a la política de WAF.
• El nuevo WAF V2 está configurado para usar CRS 3.0 de forma predeterminada. Sin embargo, dado que CRS 3.0 está en la ruta de desuso, actualice al conjunto de reglas más reciente, DRS 2.2, después de la migración. Para obtener más información, consulte los grupos de reglas y las reglas del CRS y DRS.

Instalación del script

Dispone de dos opciones en función de sus preferencias y de la configuración del entorno de PowerShell local:

• Si no tiene instalados los módulos de Azure Az o no le importa desinstalar los módulos de Azure Az, la mejor opción es usar la opción Install-Script para ejecutar el script.
• Si necesita mantener los módulos de Azure Az, descargue el script y ejecútelo directamente. Para determinar si tiene instalados los módulos de Azure Az, ejecute Get-InstalledModule -Name az. Si no ve ningún módulo de Az instalado, puede usar el método .

Instalación con el método Install-Script (recomendado)

Para usar esta opción, no debe tener instalados los módulos de Azure Az en el equipo. En caso de que lo estén, el comando siguiente mostrará un error. Puede desinstalar los módulos de Azure Az o usar la otra opción para descargar el script manualmente y ejecutarlo.

Ejecute el script con el siguiente comando para obtener la última versión:

• Para la clonación mejorada del script de retención de direcciones IP públicas:

• Para el script de clonación mejorada:

• Para el script de clonación heredado:

Este comando también instala los módulos de Az necesarios.

Instalación directamente con el script

Si tiene algunos módulos de Az instalados Azure y no puede desinstalarlos (o no desea desinstalarlos), puede descargar manualmente el script mediante la pestaña Descargar en el vínculo de descarga del script.

El script se descarga como un archivo nupkg sin procesar. Para instalar el script desde este archivo nupkg, consulte Descarga manual del paquete.

Para el script de clonación heredado, la versión 1.0.11 es la nueva versión del script de migración que incluye correcciones de errores principales. Asegúrese de usar la versión estable más reciente de Galería de PowerShell

Comprobación de la versión del script descargado

Para comprobar la versión del script descargado, los pasos son los siguientes:

1. Extraiga el contenido del paquete de NuGet.
2. Abre el archivo en la carpeta y comprueba el en la parte superior para confirmar la versión del script descargado

<#PSScriptInfo
.VERSION 1.0.10
.GUID aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Migración del tráfico

Requisitos previos

• En primer lugar, asegúrese de que el script ha creado correctamente una puerta de enlace V2 con la configuración exacta migrada a través de la puerta de enlace V1. Puede comprobarlo desde el portal de Azure.
• Como prueba manual, envíe una pequeña cantidad de tráfico a través de la puerta de enlace V2.

Script para conservación de IP pública

Después de migrar correctamente la configuración y probar exhaustivamente la nueva puerta de enlace V2, este paso se centra en redirigir el tráfico activo. Proporcionamos un script de Azure PowerShell diseñado para retainar la dirección IP pública de V1.

• Intercambia la dirección IP pública: este script reserva la dirección IP pública básica de V1, la convierte en Estándar y la asocia a la puerta de enlace V2. Esto redirige eficazmente todo el tráfico entrante a la puerta de enlace V2.
• Tiempo de inactividad esperado: esta operación de intercambio de IP suele dar lugar a un breve tiempo de inactividad de aproximadamente 1 a 5 minutos. Planifique en consecuencia.
• Después de ejecutar un script correcto, la dirección IP pública se mueve de Application Gateway V1 a Application Gateway V2, con Application Gateway V1 recibiendo una nueva dirección IP pública.

Puede descargar este script de retención de IP pública desde la Galería de PowerShell

Parámetros para el script:

Este script requiere los siguientes parámetros obligatorios:

• ResourceId V1: El identificador de recurso de la Puerta de Enlace de Aplicaciones V1, cuya dirección IP pública se reservará y se asociará a V2.
• ResourceId V2: el identificador de recurso de la puerta de enlace de aplicaciones V2 a la que se asignará la dirección IP pública V1. La puerta de enlace V2 se puede crear manualmente o usar cualquiera de los scripts de clonación.

Después de descargar e instalar el script

Ejecute AzureAppGWIPMigrate.ps1 con los parámetros necesarios:

   ./AzureAppGWIPMigrate.ps1
    -v1resourceId <V1 application gateway Resource ID>
    -v2resourceId <V2 application gateway Resource ID>

Ejemplo

 ./AzureAppGWIPMigrate.ps1 `
 -v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
 -v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

Una vez completado el intercambio de IP, compruebe las operaciones del plano de control y del plano de datos en la puerta de enlace V2. Todas las acciones del plano de control excepto Eliminar están deshabilitadas en la puerta de enlace V1.

Recomendaciones de migración de tráfico

A continuación se muestran algunos escenarios en los que la puerta de enlace de aplicaciones actual (Estándar) puede recibir tráfico de cliente y nuestras recomendaciones para cada una de ellas:

• Zona DNS personalizada (por ejemplo, contoso.com) que apunta a la dirección IP de front-end (mediante un registro A) asociada a la puerta de enlace Estándar V1 o WAF V1. Puede actualizar el registro DNS para que apunte a la etiqueta DNS o IP de front-end asociada a la puerta de enlace de aplicación Standard_V2. Según el TTL configurado en el registro DNS, puede tardar un tiempo en migrar todo el tráfico de cliente a la nueva puerta de enlace V2.
• Zona DNS personalizada (por ejemplo, contoso.com) que apunta a la etiqueta DNS (por ejemplo: myappgw.eastus.cloudapp.azure.com con un registro CNAME) asociada a la puerta de enlace V1. Tiene dos opciones:
  • Si usa direcciones IP públicas en la puerta de enlace de aplicaciones, puede llevar a cabo una migración pormenorizada controlada mediante un perfil de Traffic Manager para enrutar el tráfico de forma incremental (método de enrutamiento de tráfico ponderado) a la nueva puerta de enlace V2. Para hacerlo, agregue las etiquetas DNS de las puertas de enlace de aplicaciones V1 y V2 al perfil de Traffic Manager y asigne el registro CNAME del DNS personalizado (por ejemplo, ) en el dominio Traffic Manager (por ejemplo, contoso.trafficmanager.net).
  • También puede actualizar el registro DNS del dominio personalizado para que apunte a la etiqueta DNS de la nueva puerta de enlace de aplicaciones V2. Según el TTL configurado en el registro DNS, puede tardar un tiempo en migrar todo el tráfico de cliente a la nueva puerta de enlace V2.
• Los clientes se conectan a la dirección IP de front-end de la puerta de enlace de aplicaciones. Actualice los clientes para que usen la dirección IP asociada a la puerta de enlace de aplicaciones V2 recién creada. Se recomienda que no use direcciones IP directamente. Considere la posibilidad de usar la etiqueta de nombre DNS (por ejemplo, yourgateway.eastus.cloudapp.azure.com) asociada a la puerta de enlace de aplicaciones cuyo registro CNAME pueda asignar a su propia zona DNS personalizada (por ejemplo, contoso.com).

Después de la migración

Después de que la migración del tráfico se realice correctamente y compruebe completamente que la aplicación se ejecuta correctamente a través de la puerta de enlace V2, puede retirar y eliminar de forma segura el recurso de Application Gateway V1 antiguo para evitar costos innecesarios.

Consideraciones sobre precios

Los modelos de precios son diferentes para las SKU V1 y V2 de Application Gateway. V2 se cobra en función del consumo. Consulte Precios de Application Gateway antes de migrar para obtener información sobre precios.

Guía de rentabilidad

La SKU V2 incluye una serie de ventajas, como un incremento en el rendimiento de 5 veces, una seguridad mejorada con integración con Key Vault, actualizaciones más rápidas de reglas de seguridad en WAF_V2, reglas personalizadas de WAF, asociaciones de políticas y protección contra bots. También ofrece alta escalabilidad, enrutamiento de tráfico optimizado e integración sin problemas con los servicios de Azure. Estas características pueden mejorar la experiencia general del usuario, evitar ralentizaciones durante momentos de tráfico pesado y evitar infracciones de datos costosas.

Hay cinco variantes disponibles en la SKU V1 en función del nivel y el tamaño: Standard_Small, Standard_Medium, Standard_Large, WAF_Medium y WAF_Large.

Para obtener más información sobre los precios, trabaje con su CSAM o póngase en contacto con nuestro equipo de soporte técnico para obtener ayuda.

Preguntas frecuentes

Para preguntas comunes sobre la migración, consulte Preguntas más frecuentes sobre la migración de V1 a V2.

Pasos siguientes

Información sobre Application Gateway V2