Preguntas más frecuentes sobre Application Gateway

Azure Application Gateway proporciona un controlador de entrega de aplicaciones como servicio. Ofrece diversas funcionalidades de equilibrio de carga de nivel 7 para sus aplicaciones. Este servicio es altamente disponible y escalable, y está completamente administrado por Azure.

Application Gateway admite la escalabilidad automática, descarga de TLS, TLS de un extremo a otro, firewall de aplicaciones web (WAF), afinidad de sesión basada en cookies, enrutamiento basado en ruta de dirección URL, hospedaje de varios sitios y otras características. Para obtener una lista completa de las características admitidas, consulte Introducción a Application Gateway.

Application Gateway es un equilibrador de carga de nivel 7, lo que significa que solo funciona con tráfico web (HTTP, HTTPS, WebSocket y HTTP/2). Admite funcionalidades como la terminación TLS, la afinidad de sesión basada en cookies y la distribución round robin para el tráfico de equilibrio de carga. Load Balancer equilibra la carga de tráfico en el nivel 4 (TCP o UDP).

Application Gateway admite HTTP, HTTPS, HTTP/2 y WebSocket.

Consulte HTTP/2 support (Compatibilidad con HTTP/2).

Consulte Recursos backend admitidos.

La versión 1 de Application Gateway (Standard y WAF) está disponible en todas las regiones de Azure global. También está disponible en Microsoft Azure operado por 21Vianet y Azure Government.

Para conocer la disponibilidad de la versión 2 de Application Gateway (Standard_v2 y WAF_v2), consulte las regiones en las que se admite Application Gateway v2.

Application Gateway es una implementación dedicada en su red virtual.

Se admite el redireccionamiento. Consulte Introducción a la redirección de Application Gateway.

Consulte el orden de procesamiento del agente de escucha.

Si usa una dirección IP pública como punto de conexión, encontrará la información de IP y DNS en el recurso de dirección IP pública. O bien, puede encontrarlo en Azure Portal, en la página de información general de Application Gateway. Si usa direcciones IP internas, encontrará la información en la página información general. En el caso de la SKU v1, las puertas de enlace creadas después del 1 de mayo de 2023 no tendrán un nombre DNS predeterminado asociado automáticamente con el recurso de dirección IP pública. En SKU v2, abra el recurso de dirección IP pública y seleccione Configuración. El campo Etiqueta de nombre DNS (opcional) está disponible para configurar el nombre DNS.

El tiempo de espera de Keep-Alive regula cuánto tiempo espera la puerta de enlace de aplicaciones para que un cliente envíe otra solicitud HTTP en una conexión persistente antes de reutilizarla o cerrarla. El tiempo de espera de inactividad de TCP regula cuánto tiempo se mantiene abierta una conexión TCP si no hay ninguna actividad.

Para las conexiones HTTP/1.1, el tiempo de espera de Keep-Alive en la SKU v1 y v2 de Application Gateway es de 120 segundos. En el caso de las direcciones IP privadas, el valor no se puede configurar con un tiempo de espera de inactividad de TCP de 5 minutos. El tiempo de espera de inactividad de TCP es el valor predeterminado de 4 minutos en la IP virtual (VIP) de front-end tanto de la SKU v1 y v2 de Application Gateway. Puede configurar el valor de tiempo de espera de inactividad de TCP en las instancias de Application Gateway v1 y v2 para que estén en cualquier lugar entre 4 y 30 minutos. En el caso de las instancias de Application Gateway v1 y v2, debe ir a la dirección IP pública de la puerta de enlace de aplicaciones y cambiar el tiempo de espera de inactividad de TCP en el panel Configuración de la dirección IP pública en el portal. Puede establecer el valor de tiempo de espera de inactividad de TCP de la dirección IP pública mediante PowerShell al ejecutar los siguientes comandos:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Para las conexiones HTTP/2 a la dirección IP de front-end en la SKU de Application Gateway v2, el tiempo de espera de inactividad se establece en 180 segundos y no se puede configurar.

Para evitar conflictos y comportamientos inesperados, asegúrese de que el tiempo de espera de inactividad de TCP esté establecido para que sea el mismo o mayor que el tiempo de espera de mantenimiento activo.

Sí. Application Gateway reutiliza las conexiones TCP existentes con un servidor back-end.

No. No hay ninguna manera de cambiar el nombre de un recurso de Application Gateway. Por lo tanto, debe crear otro recurso con un nombre diferente.

No. No hay ninguna manera de restaurar un recurso de Application Gateway o su dirección IP pública después de eliminarlo. Debe crear un nuevo recurso.

En la SKU de Application Gateway v1, la dirección VIP puede cambiar si se detiene e inicia la puerta de enlace de aplicaciones. Sin embargo, el nombre DNS asociado a Application Gateway no cambia durante la vigencia de la puerta de enlace. Como el nombre DNS no cambia, se debe usar un alias de CNAME y apuntarlo hacia la dirección DNS de Application Gateway. En la SKU de Application Gateway v2, las direcciones IP son estáticas, por lo que la dirección IP y el nombre DNS no cambiarán durante la vigencia de la puerta de enlace de aplicaciones.

Sí. La SKU de Application Gateway v2 admite direcciones IP públicas estáticas y direcciones IP internas estáticas. La SKU v1 es compatible con direcciones IP internas estáticas.

Solo se admite una dirección IP pública por protocolo de IP en puerta de enlace de aplicación. Si la puerta de enlace de aplicación está configurada como DualStack, puede admitir dos direcciones IP públicas, una para IPv4 y otra para IPv6.

Consulte Application Gateway subnet size considerations (Consideraciones de tamaño de subred de Application Gateway).

Sí. Además de tener varias instancias de una determinada implementación de Application Gateway, puede aprovisionar otro recurso de Application Gateway único para una subred existente que contenga un recurso de Application Gateway diferente.

Una sola subred no admite las SKU v1 y v2 de Application Gateway.

Sí, pero solo en escenarios concretos. Para más información, consulte Configuración de la infraestructura de Application Gateway.

Sí. Consulte Modifications to a request (Modificaciones a una solicitud).

Las nuevas implementaciones de SKU v1 de Application Gateway pueden tardar hasta 20 minutos en aprovisionarse. Los cambios de tamaño o recuento de instancias no provocan interrupciones y Application Gateway permanece activa durante este tiempo.

La mayoría de las implementaciones que usan la SKU v2 tardan aproximadamente 6 minutos en aprovisionarse. Sin embargo, el proceso puede tardar más en función del tipo de implementación. Por ejemplo, las implementaciones en varias zonas de disponibilidad con muchas instancias pueden tardar más de 6 minutos.

Las actualizaciones iniciadas en Application Gateway se aplican a un dominio de actualización cada vez. A medida que se actualizan las instancias de cada dominio de actualización, las instancias restantes de otros dominios de actualización siguen sirviendo al tráfico¹. Las conexiones activas se purgan correctamente de las instancias que se actualizan durante un máximo de 5 minutos para ayudar a establecer la conectividad con las instancias de un dominio de actualización diferente antes de que comience la actualización. Durante la actualización, Application Gateway se ejecuta temporalmente con una capacidad máxima reducida, que viene determinada por el número de instancias configuradas. El proceso de actualización continúa con el siguiente conjunto de instancias solo si el conjunto actual de instancias se actualizó correctamente.

¹ Se recomienda configurar un número mínimo de instancias de 2 para las implementaciones de SKU de Application Gateway v1 para asegurarse de que al menos una instancia puede atender el tráfico mientras se aplican las actualizaciones.

Application Gateway admite proxy de protocolo TLS/TCP a través de su proxy de nivel 4 en versión preliminar.

El proxy de nivel 7 de Application Gateway con protocolos HTTP(S) no admitirá protocolos de correo electrónico como SMTP, IMAP y POP3. Sin embargo, para algunos servicios de correo electrónico compatibles, como Outlook Web Access (OWA), ActiveSync y tráfico de Detección automática que usa protocolos HTTP(S), puede usar el proxy de nivel 7 y su tráfico debe fluir a través. (Nota: Es posible que se requieran exclusiones en las reglas de WAF al usar una SKU de WAF).

Sí. Para obtener más información, consulte Migrar Azure Application Gateway y Web Application Firewall de v1 a v2.

Sí. La SKU de Application Gateway v1 sigue siendo compatible. Se recomienda encarecidamente pasar a v2 para aprovechar las actualizaciones de características de esa SKU. Para obtener más información sobre las diferencias entre las características v1 y v2, consulte el Escalado automático y Application Gateway v2 con redundancia de zona. Puede migrar manualmente las implementaciones de la SKU de Application Gateway v1 a v2 siguiendo nuestro documento de migración de la v1 a la v2.

No. Application Gateway v2 no admite solicitudes de proxy con autenticación NTLM o Kerberos.

Los nombres de encabezado de solicitud pueden contener caracteres alfanuméricos y guiones. Los nombres de encabezado de solicitud que contienen otros caracteres se descartan cuando se envía una solicitud al destino de back-end. Los nombres de encabezado de respuesta solo pueden contener caracteres alfanuméricos y símbolos específicos definidos en RFC 7230.

Sí. El Explorador Chromium actualización v80 introdujo un mandato en las cookies HTTP sin el atributo SameSite que se tratará como SameSite=Lax. Esto significa que el explorador no enviará la cookie de afinidad de Application Gateway en un contexto de terceros.

Para admitir este escenario, Application Gateway inserta otra cookie denominada ApplicationGatewayAffinityCORS además de la cookie ApplicationGatewayAffinity existente. Estas cookies son similares, pero la cookie de ApplicationGatewayAffinityCORS tiene dos atributos más agregados: SameSite=None y Secure. Estos atributos mantienen las sesiones permanentes incluso para las solicitudes entre orígenes. Para obtener más información, consulte la sección Afinidad basada en cookies.

Un agente de escucha activo es un agente de escucha que está asociado a una regla y que envía tráfico a un grupo de back-end. Cualquier cliente de escucha que solo redirija el tráfico no es un cliente de escucha activo. Los cliente de escucha asociados a las reglas de redireccionamiento no se consideran activos. Si la regla de redireccionamiento es una regla basada en rutas de acceso, todas las rutas de acceso de esa regla de redireccionamiento deben redirigir el tráfico o, de lo contrario, el agente de escucha se considera activo. Para más información sobre el límite de componentes individuales, consulte límites, cuotas y restricciones de suscripción y servicio de Azure.

La SKU v1 de Application Gateway admite escenarios de alta disponibilidad cuando se tienen implementadas dos o más instancias. Azure distribuye estas instancias entre dominios de actualización y de errores para asegurarse de que las instancias no produzcan un error todas al mismo tiempo. La SKU v1 admite escalabilidad mediante la incorporación de varias instancias de la misma puerta de enlace para compartir la carga.

La SKU v2 garantiza automáticamente que las nuevas instancias se distribuyan entre dominios de error y dominios de actualización. Si elige la redundancia de zona, las instancias más recientes también se distribuyen entre las zonas de disponibilidad para ofrecer resistencia ante errores de zona.

Use Azure Traffic Manager para distribuir el tráfico entre varias puertas de enlace de aplicaciones en diferentes centros de datos.

Sí. Puede configurar el drenaje de conexiones para cambiar los miembros de un grupo de servidores back-end sin interrupciones. Para más información, consulte la sección Purga de conexiones de Application Gateway.

Sí, la SKU v2 de Application Gateway admite la escalabilidad automática. Para obtener más información, consulte Escalado automático y Application Gateway con redundancia de zona.

No. Las instancias se distribuyen entre varios dominios de actualización y dominios de error.

Sí.

Sí.

Sí. Application Gateway se implementa siempre en una subred de red virtual. Esta subred solo puede contener instancias de Application Gateway. Para obtener más información, consulte Requisitos de red virtual y subred.

Si tiene conectividad IP, Application Gateway puede comunicarse con instancias fuera de la red virtual en la que se encuentra. Application Gateway también se puede comunicar con instancias fuera de la red virtual en la que se encuentra. Si planea usar direcciones IP internas como miembros de grupo de back-end, use el emparejamiento de redes virtuales o Azure VPN Gateway.

Como cualquier solucionador de DNS, el recurso de Application Gateway respeta el valor de tiempo de vida (TTL) del registro DNS del servidor backend. Después de que expire el TTL, la puerta de enlace realiza una búsqueda para actualizar esa información de DNS. Durante esta búsqueda, si la puerta de enlace de aplicaciones encuentra un problema al obtener una respuesta (o no se encuentra ningún registro DNS), la puerta de enlace sigue usando el último valor DNS correcto conocido para atender el tráfico. Para más información, consulte Funcionamiento de una puerta de enlace de aplicaciones.

Las instancias de la puerta de enlace de aplicaciones usan la configuración DNS de la red virtual para la resolución de nombres. Después de cambiar cualquier configuración del servidor DNS, debe reiniciar (Detener e iniciar) la puerta de enlace de aplicaciones para que se asignen los nuevos servidores DNS. Hasta entonces, las resoluciones de nombres basadas en FQDN para la conectividad saliente podrían producir un error.

No. Pero se pueden implementar otras instancias de Application Gateway en la subred.

Puede mover una puerta de enlace de aplicaciones solo entre subredes dentro de la misma red virtual. Se admite con v1 con un front-end público y privado (asignación dinámica) y v2 solo con un front-end público. No se puede mover la puerta de enlace de aplicaciones a otra subred si la configuración de IP de front-end privada está asignada estáticamente. La puerta de enlace de aplicaciones debe estar en un estado Detenido para realizar esta acción. Al detener o iniciar v1, se cambia la dirección IP pública. Esta operación solo se puede realizar mediante Azure PowerShell y la CLI de Azure ejecutando los siguientes comandos:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Para más información, consulte Set-AzApplicationGatewayIPConfiguration.

CLI de Azure

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Consulte Grupos de seguridad de red en la subred de Application Gateway.

Consulte User-defined routes supported in the Application Gateway subnet (Rutas definidas por el usuario en la subred de Application Gateway).

No. Las directivas de punto de conexión de servicio para las cuentas de almacenamiento no se admiten en la subred de Application Gateway y la configuración bloquea el tráfico de infraestructura de Azure.

Consulte Límites de Application Gateway.

Sí. Application Gateway admite una dirección IP interna y una dirección IP externa por cada instancia de Application Gateway.

Sí. El emparejamiento de redes virtuales ayuda a equilibrar la carga del tráfico en otras redes virtuales.

Sí, siempre que se permita el tráfico.

Se admite la arquitectura de microservicios. Para sondear en puertos diferentes, debe configurar varias opciones de backend.

No.

See Order of processing rules (Orden de procesamiento de reglas).

El campo Host especifica el nombre al que se debe enviar el sondeo cuando se ha configurado la funcionalidad de multisitio en Application Gateway. De lo contrario, use 127.0.0.1. Este valor es distinto del nombre de host de máquina virtual. Su formato es <protocolo>://<host>:<puerto><ruta de acceso>.

Sí. Consulte la Restricción del acceso a determinadas direcciones IP de origen.

Sí, puede usar agentes de escucha orientados al público y privado con el mismo número de puerto para admitir simultáneamente clientes públicos y privados. Si un grupo de seguridad de red (NSG) está asociado a la subred de la puerta de enlace de aplicaciones, es posible que se necesite una regla de entrada específica en función de su configuración. Más información.

Application Gateway v2 admite frontend IPv4 e IPv6. Actualmente, la compatibilidad con IPv6 solo está disponible para las nuevas puertas de enlace de aplicaciones. Para admitir IPv6, la red virtual debe ser de doble pila. Application Gateway v1 no admite redes virtuales de pila doble.

Las SKU de Application Gateway v1 se pueden ejecutar en un modo de operación aprobado por FIPS 140-2, que comúnmente se denomina "modo FIPS". El modo FIPS llama a un módulo criptográfico validado FIPS 140-2 que garantiza algoritmos compatibles con FIPS para cifrado, hash y firma cuando está habilitado. Para asegurarse de que el modo FIPS está habilitado, la configuración de FIPSMode debe configurarse a través de PowerShell, la plantilla de Azure Resource Manager o la API REST después de inscribir la suscripción para habilitar la configuración de FIPSmode.

Nota: Como parte del cumplimiento de FedRAMP, el Gobierno de Estados Unidos exige que los sistemas funcionen en un modo aprobado por el FIPS después de agosto de 2024.

Pasos para habilitar el modo FIPS en la SKU V1:

Paso 1: Registre la característica ‘AllowApplicationGatewayEnableFIPS’ para inscribir la suscripción para la configuración del modo FIPS.

Para registrarse con Azure PowerShell, abra un símbolo del sistema de Cloud Shell y escriba lo siguiente:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Para registrarse mediante Azure Portal:

• Inicie sesión en Azure Portal y busque Características en versión preliminar.
• Escriba AllowApplicationGatewayEnableFIPS en el cuadro de filtro. Seleccione Permitir modo FIPS en Application Gateway V1, y a continuación, seleccione Registrar.

Paso 2: Establezca la propiedad enableFips en True mediante PowerShell, la plantilla de Azure Resource Manager o la API de REST.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Cambiar el modo FIPS no afecta a la disponibilidad general de los conjuntos de cifrado en puertas de enlace V1. Sin embargo, cuando se usa la criptografía de curva elíptica para cifrados, con el modo FIPS deshabilitado puede usar curve25519, NistP256 y NistP384, mientras que con el modo FIPS habilitado solo se permiten NistP256 y NistP384 y se deshabilita curve25519. Puesto que curve25519 deja de estar disponible en el modo FIPS, asegúrese de que los clientes admiten NistP256 o NistP384 para la comunicación segura antes de habilitar FIPS.

Actualmente, Application Gateway v2 solo admite la configuración de interfaz de IP privada (no IP pública) a través de una vista previa pública. Para obtener más información, consulte Implementación de Private Application Gateway (versión preliminar).

Para soporte de disponibilidad general actual, Application Gateway v2 admite las siguientes combinaciones:

• IP privada e IP pública
• Solo IP pública

Para restringir el tráfico solo a direcciones IP privadas con la funcionalidad actual, siga este proceso:

1. Cree una puerta de enlace de aplicaciones con dirección IP de front-end pública y privada.

2. No cree ningún cliente de escucha para la dirección IP pública de front-end. Application Gateway no escuchará ningún tráfico en la dirección IP pública si no se crea ningún cliente de escucha para ello.

3. Cree y adjunte un grupo de seguridad de red para la subred de Application Gateway con la siguiente configuración en orden de prioridad:

   1. Permita el tráfico desde Origen como etiqueta de servicio GatewayManager, Destino como Cualquiera y el destino Puerto como 65200-65535. Este intervalo de puertos es necesario para la comunicación de la infraestructura de Azure. Estos puertos están protegidos (bloqueados) por la autenticación de certificados. Las entidades externas, incluidos los administradores de usuarios de la puerta de enlace, no pueden iniciar cambios en esos puntos de conexión sin los certificados adecuados en su lugar.

   2. Permita el tráfico de Origen como etiqueta de servicio AzureLoadBalancer y el destino Puerto como Cualquiera.

   3. Deniegue todo el tráfico entrante desde el Origen como etiqueta de servicio de Internet y el destino de Puerto como Cualquiera. Asigne a esta regla la mínima prioridad en las reglas de entrada.

   4. Mantenga las reglas predeterminadas como AllowVNetInBound para que no se bloquee el acceso en una dirección IP privada.

   5. No puede bloquearse la conectividad saliente de Internet. De lo contrario, se enfrentan a problemas con el registro y las métricas.

Configuración de NSG de ejemplo para el acceso de solo IP privada:

Puede usar Azure PowerShell o la CLI de Azure para detener e iniciar Application Gateway. Cuando se detiene y se inicia Application Gateway, la facturación también se detiene y se inicia. Cualquier operación PUT realizada en una puerta de enlace de aplicaciones detenida (como agregar etiqueta, sondeo de estado o agente de escucha) desencadena un inicio. Se recomienda detener la puerta de enlace de aplicaciones después de actualizar la configuración.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway admite certificados autofirmados, certificados de entidad de certificación (CA), certificados de validación extendida (EV), certificados de varios dominios (SAN) y certificados comodín.

Application Gateway admite los siguientes conjuntos de cifrado:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Para obtener información sobre cómo personalizar opciones de TLS, consulte Configuración de versiones de directivas TLS y conjuntos de cifrado en Application Gateway.

Sí. Application Gateway admite la descarga TLS y TLS de un extremo a otro, que vuelve a cifrar el tráfico hacia el backend.

Sí. Puede configurar Application Gateway para denegar TLS1.0, TLS1.1 y TLS1.2. De forma predeterminada, SSL 2.0 y 3.0 ya están deshabilitadas y no se pueden configurar.

Sí. En Application Gateway, puede configurar conjuntos de cifrado. Para definir una directiva personalizada, habilite al menos uno de los siguientes conjuntos de cifrado:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway usa SHA256 para la administración de backend.

Application Gateway admite hasta 100 certificados TLS/SSL.

Sí, Application Gateway admite certificados con extensiones OCSP y la asociación de OCSP para certificados de servidor.

Application Gateway admite hasta 100 certificados de autenticación.

Sí, la SKU v2 de Application Gateway admite Key Vault. Para obtener más información, consulte Terminación TLS con certificados de Key Vault.

Para el enrutamiento (basado en host) basado en varios dominios, puede crear agentes de escucha multisitio, configurar agentes de escucha que usen HTTPS como el protocolo y asociar agentes de escucha a las reglas de enrutamiento. Para más información, consulte Hosting multiple sites by using Application Gateway (Hospedaje de varios sitios mediante Application Gateway).

No. Use solo caracteres alfanuméricos en la contraseña del archivo .pfx.

Los miembros del explorador de entidades de certificación (CA) han publicado recientemente informes con detalles sobre varios certificados que han emitido los proveedores de CA que usan nuestros clientes, Microsoft y la comunidad tecnológica al completo que no cumplen con los estándares del sector para las entidades de certificación de confianza pública. Los informes relativos a las CA no conformes se pueden encontrar aquí:

• Error 1649951
• Error 1650910

Según los requisitos de cumplimiento del sector, los proveedores de CA comenzaron a revocar ca no compatibles y emitir ca compatibles, lo que requiere que los clientes vuelvan a emitir sus certificados. Microsoft se asocia estrechamente con estos proveedores para minimizar el posible impacto en los servicios de Azure. Sin embargo, los certificados o certificados auto emitidos que se usan en los escenarios Bring Your Own Certificate (BYOC) todavía corren el riesgo de revocarse inesperadamente.

Para comprobar si los certificados utilizados por su aplicación fueron revocados, consulte el anuncio de DigiCert y el Rastreador de revocación de certificados. Si se revocaron los certificados, o se revocarán, deberá solicitar nuevos certificados del proveedor de CA utilizado en las aplicaciones. Para evitar que la disponibilidad de la aplicación se interrumpa debido a que los certificados se revocan inesperadamente o para actualizar un certificado que se ha revocado, consulte Revocación de entidades de certificación no compatibles que puedan afectar a los servicios de Azure del cliente.

Para obtener información específica de Application Gateway:

Si usa un certificado emitido por uno de los ICA revocados, es posible que se interrumpa la disponibilidad de la aplicación. En función de la aplicación, es posible que reciba varios mensajes de error, entre los que se incluyen, entre otros:

• Certificado no válido o certificado revocado
• Se agotó el tiempo de espera de la conexión
• HTTP 502

Para evitar cualquier interrupción en su aplicación debido a este problema, o para volver a emitir una CA que ha sido revocada, debe realizar las siguientes acciones:

1. Póngase en contacto con su proveedor de certificados para volver a emitir los certificados.
2. Una vez que se vuelvan a emitir, actualice los certificados en Application Gateway o WAF con la cadena completa de confianza (hoja, intermedio y certificado raíz). En función de dónde use el certificado, ya sea en el agente de escucha o en la configuración HTTP de la puerta de enlace de aplicaciones, siga estos pasos para actualizar los certificados. Para obtener más información, consulte los vínculos de documentación mencionados.
3. Actualice los servidores de aplicaciones backend para que usen el certificado que se volvió a emitir. En función del servidor backend que use, los pasos de actualización del certificado pueden variar. Compruebe la documentación del proveedor.

Para actualizar el certificado en el cliente de escucha:

1. En Azure Portal, abra el recurso de Application Gateway.
2. Abra la configuración del agente de escucha asociada al certificado.
3. Seleccione Renovar o editar el certificado seleccionado.
4. Cargue el nuevo certificado PFX con la contraseña y seleccione Guardar.
5. Acceda al sitio web y compruebe si funciona según lo esperado. Para más información, consulte Renovar certificados de Application Gateway.

Si hace referencia a certificados desde Key Vault en el agente de escucha de Application Gateway, se recomiendan los pasos siguientes para obtener un cambio rápido:

1. En el Azure Portal, vaya a la configuración de Key Vault asociada a la puerta de enlace de aplicaciones.
2. Agregue o importe el certificado vuelto a emitir en el almacén. Para obtener más información, consulte Inicio rápido: crear un almacén de claves mediante Azure Portal.
3. Una vez importado el certificado, vaya a la configuración del agente de escucha de Application Gateway y, en Elija un certificado de Key Vault, seleccione la lista desplegable Certificado y el certificado agregado recientemente.
4. Seleccione Guardar. Para obtener más información sobre la terminación de TLS en Application Gateway con certificados de Key Vault, consulte Terminación de TLS con certificados de Key Vault.

Para actualizar el certificado en la configuración HTTP:

Si usa la SKU v1 del servicio Application Gateway/WAF, debe cargar el nuevo certificado como certificado de autenticación de backend.

1. En Azure Portal, abra el recurso de Application Gateway.
2. Abra la configuración HTTP asociada al certificado.
3. Seleccione Agregar certificado, cargue el certificado vuelto a emitir y seleccione Guardar.
4. Para quitar el certificado antiguo más adelante, seleccione el botón de opciones ... situado junto al certificado anterior. Seleccione Eliminar y, después Guardar. Para más información, consulte la Configuración de TLS de un extremo a otro con Application Gateway mediante el portal.

Si usa la SKU v2 del servicio Application Gateway o WAF, no tiene que cargar el certificado nuevo en la configuración HTTP, ya que la SKU v2 usa los "certificados raíz de confianza" y no es necesario realizar ninguna acción en este caso.

Sí. Tanto el enrutamiento de nivel 7 como el de nivel 4 a través de Application Gateway usan la misma configuración IP de front-end. De este modo, puede dirigir a todos los clientes a una sola dirección IP (pública o privada) y el mismo recurso de puerta de enlace los enrutará en función de los protocolos de escucha configurados y los puertos.

Aunque también se puede atender el tráfico HTTP(S) a través de protocolos de proxy L4, no se recomienda hacerlo. La solución de proxy L7 de Application Gateway ofrece un mayor control y seguridad sobre los protocolos HTTP(S) a través de características avanzadas como Reescrituras, Afinidad de sesión, Redireccionamiento, WebSockets, WAF y mucho más.

Las propiedades de recursos de las características de nivel 4 son diferentes de las de nivel 7. En consecuencia, al usar la API de REST o la CLI, debe usar las siguientes propiedades.

• REST API
• CLI

No. No se pueden vincular de forma cruzada las propiedades de nivel 4 y de nivel 7. Por lo tanto, una regla de enrutamiento solo le permitirá vincular un agente de escucha de nivel 4 a una configuración back-end de nivel 4.

No puede usar el mismo nombre para L7 (agentes de escucha http) y L4 (agentes de escucha). Esto se aplica a otras propiedades L4, como backendSettingsCollection y routingRules.

Totalmente. De forma similar al proxy de nivel 7, puede agregar un punto de conexión privado al grupo de back-end de la puerta de enlace de aplicaciones. Este punto de conexión privado debe implementarse en una subred adyacente de la misma red virtual de la puerta de enlace de aplicaciones.

No usa Keepalive para las conexiones de back-end. Para cada solicitud entrante en la conexión del cliente de escucha de front-end, Application Gateway inicia una nueva conexión de back-end para cumplir esa solicitud.

El servidor back-end ve la dirección IP de la puerta de enlace de aplicaciones. Actualmente, no se admite “la conservación” de IP del cliente a través de la cual se indica a la aplicación back-end la dirección IP del cliente original.

La misma configuración de directiva TLS/SSL es aplicable tanto para la capa 7 (HTTPS) como para la capa 4 (TLS). Ahora puede usar el perfil SSL (para la directiva TLS específica del cliente de escucha y la autenticación mutua) para los agentes de escucha TLS. Sin embargo, actualmente un perfil SSL se puede asociar a un agente de escucha TLS a través de la CLI, PowerShell o la API de REST solo.

No. No se admite el enrutamiento de un cliente al mismo servidor back-end en este momento. Las conexiones se distribuirán de forma "round robin" a los servidores de un grupo de back-end.

Sí, la característica de escalado automático funcionará también para picos y reducciones en el tráfico para el protocolo TLS o TCP.

Las funcionalidades de firewall de aplicaciones web (WAF) no son aptas para el uso de nivel 4.

No. La compatibilidad con UDP no está disponible en este momento.

La misma lista de intervalo de puertos permitido y excepciones se aplican también al proxy de nivel 4.

Actualmente no se admite el uso de un puerto común para los agentes de escucha TLS/TCP.

Kubernetes permite la creación de los recursos deployment y service para exponer un grupo de pods internamente en el clúster. Para exponer el mismo servicio externamente, se define un recurso Ingress que proporciona equilibrio de carga, terminación TLS y hospedaje virtual basado en nombres. Para satisfacer este recurso Ingress, se requiere un controlador de entrada que realice escuchas de los cambios en los recursos Ingress y que configure las directivas del equilibrador de carga.

El controlador de entrada de Application Gateway (AGIC) permite que Application Gateway se use como entrada para una instancia de Azure Kubernetes Service también llamada "clúster de AKS".

No se admite la configuración directa de Application Gateway.

Si es necesario cambiar la configuración en Application Gateway, realice el cambio mediante la configuración expuesta en el controlador de entrada u otros objetos de Kubernetes, como mediante anotaciones admitidas. Después de que una instancia de Application Gateway esté vinculada al controlador de entrada de Application Gateway (AGIC), casi todas las configuraciones de esa puerta de enlace se sincronizarán y controlarán mediante el controlador de entrada. Si intenta configurar directamente Application Gateway de forma imperativa o a través de la infraestructura como código, esos cambios se sobrescribirán finalmente mediante el controlador de entrada.

Actualmente, una instancia de un controlador de entrada solo se puede asociar a una puerta de enlace de aplicaciones.

AGIC intenta asociar automáticamente el recurso de tabla de rutas a la subred de Application Gateway, pero podría no hacerlo debido a la falta de permisos de AGIC. Si AGIC no puede asociar la tabla de rutas a la subred de Application Gateway, aparece un error en los registros de AGIC. En este caso, debe asociar manualmente la tabla de rutas creada por el clúster de AKS a la subred de Application Gateway. Para más información, consulte la Rutas definidas por el usuario compatibles.

Sí, siempre que las redes virtuales estén emparejadas y no tengan espacios de direcciones superpuestos. Si ejecuta AKS con kubenet, asegúrese de asociar la tabla de rutas generada por AKS a la subred de Application Gateway.

Para conocer las diferencias entre AGIC implementado a través de Helm frente a implementado como complemento de AKS, consulte Diferencia entre la implementación de Helm y el complemento de AKS.

Para conocer las diferencias entre AGIC implementado a través de Helm frente a implementado como complemento de AKS, consulte Diferencia entre la implementación de Helm y el complemento de AKS, especialmente las tablas que documentan qué escenarios admite AGIC implementados a través de Helm en lugar de un complemento de AKS. En general, la implementación a través de Helm permite probar las características beta y los candidatos de lanzamiento antes de una versión oficial.

No. El complemento AGIC es un servicio administrado, lo que significa que Microsoft actualiza automáticamente el complemento a la versión estable más reciente.

La autenticación mutua es bidireccional entre un cliente y un servidor. La autenticación mutua con Application Gateway permite actualmente a la puerta de enlace comprobar el cliente que envía la solicitud, que es la autenticación del cliente. Normalmente, el cliente es el único que autentica la puerta de enlace de aplicaciones. Dado que Application Gateway ahora también puede autenticar el cliente, se convierte en la autenticación mutua, donde Application Gateway y el cliente se autentican mutuamente entre sí.

No, la autenticación mutua solo está actualmente entre el cliente de frontend y la puerta de enlace de aplicaciones. Actualmente no se admite la autenticación mutua de backend.

Application Gateway proporciona tres registros:

• ApplicationGatewayAccessLog: el registro de acceso contiene cada solicitud enviada a la interfaz de la puerta de enlace de aplicaciones. Los datos incluyen la dirección IP del autor de la llamada, la dirección URL solicitada, la latencia de la respuesta, el código de devolución y los bytes de entrada y salida. y contiene un registro por cada instancia de Application Gateway.
• ApplicationGatewayPerformanceLog: el registro de rendimiento captura la información de rendimiento de cada puerta de enlace de aplicaciones. La información incluye el rendimiento en bytes, el número total de solicitudes atendidas, el recuento de solicitudes con error y el recuento de instancias de back-end correctas e incorrectas.
• ApplicationGatewayFirewallLog: para las puertas de enlace de aplicaciones que configura con WAF, el registro del firewall contiene solicitudes que se registran a través del modo de detección o del modo de prevención.

Todos los registros se recopilan cada 60 segundos. Para obtener más información, consulte Estado del backend, registros de diagnóstico y métricas para Application Gateway.

Compruebe el estado mediante el cmdlet de PowerShell Get-AzApplicationGatewayBackendHealth o el portal. Para más información, consulte Diagnósticos de Application Gateway.

Los registros de diagnóstico se envían a la cuenta de almacenamiento del cliente. Los clientes pueden establecer la directiva de retención según sus preferencias. Los registros de diagnóstico también se pueden enviar a un centro de eventos o a registros de Azure Monitor. Para más información, consulte Diagnósticos de Application Gateway.

En el portal, en el panel de menús de una puerta de enlace de aplicaciones, seleccione Registro de actividad para acceder al registro de auditoría.

Sí. En Application Gateway, las alertas se configuran en métricas. Para más información, consulte Application Gateway metrics (Métricas de Application Gateway) y Receive alert notifications (Recepción de notificaciones de alerta).

Puede ver y analizar los registros de acceso de varias maneras. Use registros de Azure Monitor, Excel, Power BI, etc.

También puede usar una plantilla de Resource Manager que instala y ejecuta el popular analizador de registros GoAccess para los registros de acceso de Application Gateway. GoAccess proporciona valiosas estadísticas de tráfico HTTP, como visitantes únicos, archivos solicitados, hosts, sistemas operativos, exploradores y códigos de estado HTTP. Para más información, en GitHub, consulte el archivo Léame en la carpeta de plantillas de Resource Manager.

Normalmente, verá un estado desconocido cuando un NSG, un DNS personalizado o un enrutamiento definido por el usuario bloquean el acceso al back-end en la subred de Application Gateway. Para obtener más información, consulte el Estado de back-end, registro de diagnóstico y métricas de Application Gateway.

Debido a las limitaciones actuales de la plataforma, si tiene un NSG en la subred de Application Gateway v2 (Standard_v2, WAF_v2) y si ha habilitado los registros de flujo de NSG en ella, verá un comportamiento no determinista. Actualmente no se admite este escenario.

Application Gateway no mueve ni almacena datos de cliente fuera de la región en la que se implementa.

Pasos siguientes

• Para más información sobre Application Gateway, consulte ¿Qué es Azure Application Gateway?
• Para obtener información sobre la terminación de TLS y TLS de un extremo a otro con Application Gateway, consulte Habilitar TLS de un extremo a otro en Azure Application Gateway.