Preguntas más frecuentes sobre Application Gateway

Nota

Este artículo se ha actualizado para usar el módulo Az de Azure PowerShell. El módulo Az de PowerShell es el módulo de PowerShell que se recomienda para interactuar con Azure. Para empezar a trabajar con el módulo Az de PowerShell, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Las siguientes preguntas son preguntas frecuentes sobre Azure Application Gateway.

General

¿Qué es una Puerta de enlace de aplicaciones?

Azure Application Gateway proporciona un controlador de entrega de aplicaciones (ADC) 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.

¿Qué características admite Application Gateway?

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.

¿En qué se diferencian Application Gateway y Azure Load Balancer?

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

¿Qué protocolos admite Application Gateway?

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

¿Admite Application Gateway HTTP/2?

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

¿Qué recursos son compatibles como parte de un grupo de back-end?

Consulte supported backend resources (recursos de back-end compatibles).

¿En qué regiones está disponible Application Gateway?

La versión 1 de Application Gateway (Standard y WAF) está disponible en todas las regiones de Azure global. También está disponible en Azure China 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.

¿Se trata de una implementación dedicada para mi suscripción o compartida entre los clientes?

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

¿Admite Application Gateway el redireccionamiento de HTTP a HTTPS?

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

¿En qué orden se procesan los agentes de escucha?

¿Dónde se encuentra la dirección IP y el DNS de Application Gateway?

Si usa una dirección IP pública como punto de conexión, encontrará la información de la dirección IP y del DNS en el recurso de dirección IP pública. O bien la encontrará en el 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 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.

¿Cuáles son los valores de tiempo de espera de conexión persistente y tiempo de espera de inactividad de TCP?

El tiempo de espera de conexión persistente rige cuánto tiempo esperará Application Gateway 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 rige cuánto tiempo se mantiene abierta una conexión TCP en caso de que no haya ninguna actividad.

El tiempo de espera de conexión persistente en la SKU de Application Gateway v1 es 120 segundos, mientras que en la SKU v2 es 75 segundos. 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 entre los 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 instancia de Application Gateway y cambiar el tiempo de espera de inactividad de TCP en la hoja "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

¿Cambia la dirección IP o el nombre DNS durante la vigencia de Application Gateway?

En la SKU de la versión 1 de Application Gateway, la IP virtual puede cambiar si se detiene o 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 la versión 2 de Application Gateway, puede establecer la dirección IP como estática, por lo que el nombre de IP y DNS no cambiará durante la vigencia de la puerta de enlace de aplicaciones.

¿Admite Application Gateway direcciones IP estáticas?

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

¿Admite Application Gateway varias direcciones IP públicas en la puerta de enlace?

Solo se admite una dirección IP pública en una instancia de Application Gateway.

¿Cómo de grande debe ser la subred para Application Gateway?

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

¿Puedo implementar más de un recurso de Application Gateway para una sola subred?

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.

¿Admite Application Gateway v2 rutas definidas por el usuario?

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

¿Admite Application Gateway encabezados x-forwarded-for?

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

¿Cuánto tiempo se tarda en implementar Application Gateway? ¿Mi instancia de Application Gateway funcionará mientras se actualiza?

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, pueden tardar más tiempo en función del tipo de implementación. Por ejemplo, las implementaciones en varias instancias de Availability Zones con muchas instancias pueden tardar más de 6 minutos.

¿Puedo usar Exchange Server como un back-end con Application Gateway?

No. Application Gateway no admite protocolos de correo electrónico como SMTP, IMAP y POP3.

¿Hay instrucciones disponibles para migrar de la SKU v1 a la SKU v2?

¿Se seguirá admitiendo la SKU de Application Gateway v1?

Sí. La SKU de Application Gateway v1 se seguirá admitiendo. Sin embargo, se recomienda que cambie a la versión 2 para aprovechar las ventajas de las actualizaciones de características en esa SKU. Para obtener más información, consulte Escalabilidad automática y Application Gateway v2 con redundancia de zona.

¿Admite Application Gateway V2 solicitudes de proxy con autenticación NTLM?

No. Application Gateway V2 no admite solicitudes de proxy con autenticación NTLM.

Sí, la actualización v80 del explorador Chromium incluye un mandato en el que las cookies HTTP sin el atributo SameSite se tratan 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 llamada ApplicationGatewayAffinityCORS además de la cookie ApplicationGatewayAffinity existente. Estas cookies son similares, aunque la cookie ApplicationGatewayAffinityCORS tiene dos atributos más: SameSite=None y Secure. Estos atributos mantienen las sesiones permanentes incluso para las solicitudes entre orígenes. Consulte la sección afinidad basada en cookies para obtener más información.

Rendimiento

¿Cómo admite Application Gateway la alta disponibilidad y la escalabilidad?

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.

¿Cómo se puede lograr un escenario de recuperación ante desastres a través de centros de datos con Application Gateway?

Use Traffic Manager para distribuir el tráfico a través de varias instancias de Application Gateway en distintos centros de datos.

¿Application Gateway admite la escalabilidad automática?

Sí, la SKU v2 de Application Gateway admite la escalabilidad automática. Para más información, consulte Autoscaling and Zone-redundant Application Gateway (Escalabilidad automática y Application Gateway con redundancia de zona).

¿El escalado o la reducción vertical manual o automático provocan algún tiempo de inactividad?

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

¿Es compatible Application Gateway con la funcionalidad de drenaje de conexiones?

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

¿Puedo cambiar el tamaño de la instancia de mediano a grande sin que haya una interrupción?

Sí.

Configuración

¿Se implementa Application Gateway siempre en una red virtual?

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

¿Puede Application Gateway comunicarse con instancias fuera de su red virtual o de su suscripción?

Siempre que tenga 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.

¿Puedo implementar algo más en la subred de la puerta de enlace de aplicaciones?

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

¿Puedo cambiar la red virtual o la subred de una instancia existente de Application Gateway?

Solo puede mover una instancia de Application Gateway entre subredes dentro de la misma red virtual. Se admite en la versión V1 con front-end público y privado, y en la versión V2 solo con front-end público. También es importante tener en cuenta que la instancia de Application Gateway debe estar en estado Detenido para realizar esta acción. Tenga en cuenta que al detener o iniciar la versión V1 se cambiará la dirección IP pública. Esta operación solo se puede realizar mediante Azure PowerShell y la CLI de Azure con 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>

¿Se admiten grupos de seguridad de red en la subred de Application Gateway?

¿Admite la subred de Application Gateway rutas definidas por el usuario?

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

¿Pueden utilizarse directivas de punto de conexión de servicio en la subred de Application Gateway?

No. Las directivas de punto de conexión de servicio de las cuentas de almacenamiento no pueden utilizarse en la subred de Application Gateway. Si se configuran, se bloqueará el tráfico de la infraestructura de Azure.

¿Cuáles son los límites de Application Gateway? ¿Puedo aumentar estos límites?

¿Puedo usar Application Gateway para tráfico externo e interno al mismo tiempo?

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

¿Admite Application Gateway el emparejamiento de redes virtuales?

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

¿Me puedo comunicar con servidores locales cuando están conectados mediante ExpressRoute o túneles VPN?

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

¿Puede un grupo de back-end prestar servicio a muchas aplicaciones en puertos diferentes?

Se admite la arquitectura de microservicios. Para realizar sondeos en puertos diferentes, debe establecer varias opciones de configuración de HTTP.

¿Admiten los sondeos personalizados caracteres comodín o regex en los datos de respuesta?

No.

¿Cómo se procesan las reglas de enrutamiento en Application Gateway?

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

¿Qué significa el campo Host de los sondeos personalizados?

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 <protocol>://<host>:<port><path>.

¿Se puede permitir el acceso de Application Gateway a solo unas cuantas direcciones IP de origen?

¿Puedo usar el mismo puerto para los agentes de escucha públicos y privados?

No.

¿Application Gateway admite IPv6?

Application Gateway V2 no es compatible actualmente con IPv6. Puede funcionar en una red virtual de pila dual solo mediante IPv4, pero la subred de puerta de enlace debe ser solo IPv4. Application Gateway v1 no admite redes virtuales de pila dual.

¿Cómo usar Application Gateway V2 solo con una dirección IP de front-end privada?

Actualmente, Application Gateway V2 no admite solo el modo IP privada. Admite las siguientes combinaciones

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

Pero si desea usar Application Gateway V2 con solo IP privada, puede seguir el siguiente proceso:

  1. Cree una Application Gateway con la 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 él.

  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:

    a. Permita el tráfico desde el origen como etiqueta de servicio de GatewayManager y el destino como cualquier y puerto de destino 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

    b. Permita el tráfico desde el origen como AzureLoadBalancer etiqueta de servicio y el puerto de destino y destino como cualquiera

    c. Denegar todo el tráfico entrante desde el origen como etiqueta del servicio de Internet y el puerto de destino y destino como cualquiera. Asigne a esta regla la mínima prioridad en las reglas de entrada

    d. Mantenga las reglas predeterminadas y permita la entrada de VirtualNetwork para que el acceso en la dirección IP privada no esté bloqueado

    e. No puede bloquearse la conectividad saliente de Internet. De lo contrario, se producirán problemas con el registro, las métricas, etc.

Ejemplo de configuración de NSG para acceso de IP privada solamente: Configuración de Application Gateway V2 NSG solo para acceso IP privado

Configuración: TLS

¿Qué certificados admite Application Gateway?

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.

¿Qué conjuntos de cifrado admite Application Gateway?

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.

¿Admite Application Gateway el recifrado del tráfico dirigido al back-end?

Sí. Application Gateway admite la descarga de TLS y TLS de un extremo a otro, lo cual permite volver a cifrar el tráfico dirigido al back-end.

¿Puedo configurar la directiva TLS para controlar las versiones del protocolo TLS?

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.

¿Puedo configurar los conjuntos de cifrado y el orden de las directivas?

Sí. En Application Gateway, puede configurar conjuntos de cifrado. Para definir una directiva personalizada, se debe habilitar 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 back-end.

Cuántos certificados TLS/SSL admite Application Gateway?

Application Gateway admite hasta 100 certificados TLS/SSL.

¿Cuántos certificados de autenticación de recifrado de back-end admite Application Gateway?

Application Gateway admite hasta 100 certificados de autenticación.

¿Se integra Application Gateway con Azure Key Vault de forma nativa?

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.

¿Cómo configuro agentes de escucha HTTPS para sitios .com y .NET?

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

¿Se pueden usar caracteres especiales en la contraseña del archivo .pfx?

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

DigiCert emitió mi certificado EV y el certificado intermedio se ha revocado. ¿Cómo renuevo mi certificado en Application Gateway?

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 relacionados con las entidades de certificación no compatibles se pueden encontrar aquí: 

Según los requisitos de cumplimiento de la industria, los proveedores de entidades de certificación comenzaron a revocar las CA que no eran compatibles y a emitir CA compatibles, por lo que los clientes deben emitir de nuevo sus certificados. Microsoft colabora estrechamente con estos proveedores para minimizar el potencial impacto en los servicios de Azure; no obstante, los certificados autoemitidos o los certificados que se usan en los escenarios de "Bring Your Own Certificate" (BYOC) siguen en riesgo de revocarse inesperadamente.

Para comprobar si los certificados usados por la aplicación se han revocado, consulte el Anuncio de DigiCert y el seguimiento de revocación de certificados. Si los certificados se han revocado o se van a revocar, deberá solicitar nuevos certificados del proveedor de CA que usan sus aplicaciones. Para evitar que se interrumpa la disponibilidad de la aplicación debido a la revocación inesperada de certificados o a la actualización de un certificado que se ha revocado, consulte la publicación sobre actualizaciones de Azure para obtener vínculos de corrección para varios servicios de Azure que admiten BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Para obtener información específica de Application Gateway, consulte lo siguiente:

Si usa un certificado emitido por uno de los ICA revocados, la disponibilidad de la aplicación podría interrumpirse y, en función de la aplicación, puede recibir distintos mensajes de error, entre los que se incluyen los siguientes:

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

Para evitar cualquier interrupción de la aplicación debido a este problema, o para volver a emitir una CA que se ha revocado, 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 haya vuelto a emitir, actualice los certificados en la instancia de Azure Application Gateway o WAF con la cadena de confianza completa (certificado de hoja, intermedio o raíz). Ya sea que use el certificado en el cliente de escucha o en la configuración HTTP de Application Gateway, siga los pasos que se indican a continuación para actualizar los certificados y consulte los vínculos de la documentación mencionados para obtener más información.
  3. Actualice los servidores de aplicaciones back-end para que usen el certificado que se volvió a emitir. Según el servidor back-end que use, los pasos de actualización del certificado podrían variar. Consulte la documentación de su 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 cliente de escucha que está asociado con el certificado.
  3. Haga clic en "Renovar o editar el certificado seleccionado".
  4. Cargue el nuevo certificado PFX con la contraseña y haga clic en Guardar.
  5. Acceda al sitio web y compruebe si el sitio funciona según lo previsto. Para obtener más información, consulte la documentación aquí.

Si hace referencia a los certificados de Azure Key Vault en el cliente de escucha de Application Gateway, se recomienda seguir los siguientes pasos para realizar un cambio rápido:

  1. En Azure Portal, vaya a la configuración de Azure Key Vault que se ha asociado con la instancia de Application Gateway
  2. Agregue o importe el certificado reemitido en el almacén. Consulte esta documentación para obtener más información sobre el procedimiento.
  3. Una vez que se haya importado el certificado, vaya a la configuración del cliente de escucha de Application Gateway y, en "Elegir un certificado de Key Vault", haga clic en la lista desplegable "Certificado" y elija el certificado agregado recientemente.
  4. Haga clic en Guardar. Para obtener más información sobre la terminación TLS en Application Gateway con certificados de Key Vault, consulte la documentación aquí.

Para actualizar el certificado en la configuración HTTP:

Si usa la SKU v1 del servicio Application Gateway o WAF, tendrá que cargar el certificado nuevo como certificado de autenticación del servidor back-end.

  1. En Azure Portal, abra el recurso de Application Gateway.
  2. Abra la configuración HTTP que está asociada con el certificado.
  3. Haga clic en "Agregar certificado", cargue el certificado reemitido y haga clic en Guardar.
  4. Puede quitar el certificado antiguo más adelante al hacer clic en el botón de opciones "..." situado junto al certificado anterior, seleccione Eliminar y haga clic en Guardar. Para más información, consulte la documentación aquí.

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.

Configuración: controlador de entrada para AKS

¿Qué es un controlador de entrada?

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 Azure Application Gateway se use como entrada para una instancia de Azure Kubernetes Service también llamada "clúster de AKS".

¿Puede una única instancia del controlador de entrada administrar varias puertas de enlace de aplicaciones?

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

¿Por qué el clúster de AKS con una red kubenet no funciona con AGIC?

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, se producirá un error en los registros de AGIC que lo especifiquen, en cuyo caso tendrá que 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.

¿Puedo conectar mi clúster de AKS y Application Gateway en redes virtuales independientes?

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

¿Qué características no se admiten en el complemento de AGIC?

Consulte las diferencias entre una implementación de AGIC a través de Helm y una como complemento de AKS aquí

¿Cuándo debo usar el complemento en lugar de la implementación de Helm?

Consulte las diferencias entre una implementación de AGIC a través de Helm frente a una como complemento de AKS aquí, en particular las tablas que documentan qué escenarios son compatibles con una implementación de AGIC a través de Helm frente a una complemento de AKS. En general, la implementación a través de Helm le permitirá probar las características en versión beta y las versiones candidatas para lanzamiento antes de una versión oficial.

¿Puedo controlar qué versión de AGIC se va a implementar con el complemento?

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

Configuración: autenticación mutua

¿Qué es la autenticación mutua?

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 Application Gateway. 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í.

¿Está disponible la autenticación mutua entre Application Gateway y sus grupos de back-end?

No, la autenticación mutua solo se produce actualmente entre el cliente de front-end y Application Gateway. Actualmente no se admite la autenticación mutua de back-end.

Diagnósticos y registro

¿Qué tipos de registros proporciona Application Gateway?

Application Gateway proporciona tres registros:

  • ApplicationGatewayAccessLog: el registro de acceso contiene todas las solicitudes enviadas al front-end de Application Gateway. 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 información de rendimiento para cada instancia de Application Gateway. 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 instancias de Application Gateway que configure con WAF, el registro del firewall contiene las solicitudes que se registran mediante el modo de detección o el modo de prevención.

Todos los registros se recopilan cada 60 segundos. Para más información, consulte Mantenimiento del back-end, registro de diagnóstico y métricas de Application Gateway.

¿Cómo se puede saber si mis miembros del grupo de back-end están en buenas condiciones?

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

¿Qué es la directiva de retención para los registros de diagnóstico?

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.

¿Cómo se pueden obtener los registros de auditoría de Application Gateway?

En el portal, en la hoja de menú de una instancia de Application Gateway, haga clic en Registro de actividad para acceder al registro de auditoría.

¿Se pueden establecer alertas con Application Gateway?

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

¿Cómo se pueden analizar las estadísticas de tráfico de Application Gateway?

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.

¿Qué puede provocar que el estado del back-end devuelva un valor desconocido?

Por lo general, se ve un estado desconocido cuando el acceso al back-end está bloqueado por un grupo de seguridad de red (NSG), un DNS personalizado o un enrutamiento definido por el usuario (UDR) en la subred de Application Gateway. Para más información, consulte Mantenimiento del back-end, registro de diagnóstico y métricas de Application Gateway.

¿Se admiten registros de flujo de NSG en NSG asociados a una subred de Application Gateway v2?

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

¿Dónde almacena Application Gateway los datos de los clientes?

Application Gateway no mueve ni almacena los datos de los clientes fuera de la región en los que se implementan.

Pasos siguientes

Para más información sobre Application Gateway, consulte ¿Qué es Azure Application Gateway?.