Solucionar errores de puerta de enlace defectuosa (502) en Azure Application Gateway

Resumen

Obtenga información sobre cómo solucionar errores de puerta de enlace incorrecta (502) en Azure Application Gateway para que pueda restaurar rápidamente el acceso confiable a las aplicaciones web.

Síntomas

Después de configurar una puerta de enlace de aplicaciones, es posible que vea el error del servidor: 502- Servidor web recibió una respuesta no válida mientras actúa como puerta de enlace o servidor proxy. Este error puede deberse a los siguientes motivos:

• Grupo de seguridad de red (NSG), ruta definida por el usuario (UDR) o problema de DNS personalizado.
• El sondeo de estado predeterminado no puede acceder a las máquinas virtuales de back-end.
• Tiempo de espera de solicitud o problemas de conectividad con las solicitudes del usuario.
• El grupo de backend de Application Gateway no está configurado o está vacío.
• Instancias no saludables en BackendAddressPool.
• El certificado SSL del servidor de origen no coincide.

Grupo de seguridad de red, ruta definida por el usuario o problema de DNS personalizado

Causa

Si un grupo de seguridad de red (NSG), un UDR, o un DNS personalizado bloquea el acceso al backend, las instancias de Application Gateway no pueden acceder al grupo de servidores de back-end. Este problema provoca errores de sondeo, lo que da lugar a errores 502.

El NSG/UDR podría estar presente en la subred de Application Gateway o en la subred donde se implementan las máquinas virtuales de la aplicación.

Del mismo modo, la presencia de un DNS personalizado en la red virtual también podría causar problemas. Es posible que un FQDN usado para los miembros del grupo de back-end no se resuelva correctamente por el servidor DNS configurado por el usuario para la red virtual.

Solución

Para validar la configuración de NSG, UDR y DNS, siga estos pasos:

1. Compruebe los NSG asociados a la subred de Application Gateway. Asegúrese de que no se bloquee la comunicación con el back-end. Para más información, consulteGrupo de seguridad de red.

2. Compruebe el UDR asociado a la subred del Gateway de Aplicaciones. Asegúrese de que la UDR no esté redirigiendo el tráfico fuera de la subred de backend. Por ejemplo, compruebe el enrutamiento a aplicaciones virtuales de red o rutas predeterminadas que se anuncian a la subred de Application Gateway a través de ExpressRoute/VPN.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. Compruebe el NSG efectivo y la ruta con la máquina virtual del backend.

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. Compruebe la presencia de DNS personalizado en la red virtual. Compruebe DNS examinando los detalles de las propiedades de la red virtual en la salida.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. Si está presente, asegúrese de que el servidor DNS pueda resolver correctamente el FQDN del miembro del grupo de back-end.

El sondeo de estado predeterminado no puede acceder a las máquinas virtuales de back-end

Causa

Los errores 502 también pueden indicar que el sondeo de estado predeterminado no puede llegar a las máquinas virtuales de back-end.

Al provisionar una instancia de Application Gateway, configura automáticamente un sondeo de estado predeterminado en cada BackendAddressPool mediante las propiedades de BackendHttpSetting. No es necesario proporcionar ninguna entrada para establecer este sondeo. En concreto, al configurar una regla de equilibrio de carga, se asocia un BackendHttpSetting con un BackendAddressPool. Cada una de estas asociaciones tiene configurado un sondeo predeterminado y la puerta de enlace de aplicaciones inicia una conexión periódica de comprobación de estado a cada instancia de BackendAddressPool en el puerto especificado en el elemento BackendHttpSetting.

En la tabla siguiente se enumeran los valores asociados al sondeo de estado predeterminado:

Solución

• El valor de host de la solicitud se establece en 127.0.0.1. Asegúrese de que un sitio predeterminado está configurado y está escuchando en 127.0.0.1.
• El protocolo BackendHttpSetting determina el protocolo de la solicitud.
• La ruta de acceso del URI se establece en /*.
• Si BackendHttpSetting especifica un puerto distinto de 80, configure el sitio predeterminado para que escuche en ese puerto.
• La llamada a protocol://127.0.0.1:port debe devolver un código de resultado HTTP de 200. Este código debe devolverse dentro del período de tiempo de espera de 30 segundos.
• Asegúrese de que el puerto configurado esté abierto y que no haya reglas de firewall ni grupos de seguridad de red de Azure bloqueando el tráfico entrante o saliente en el puerto configurado.
• Si usa máquinas virtuales clásicas de Azure o Servicios en la Nube de Azure con un FQDN o una dirección IP pública, asegúrese de abrir el correspondiente endpoint.
• Si configura la máquina virtual a través de Azure Resource Manager y está fuera de la VNet donde se implementa el Gateway de aplicación, debe configurar un Grupo de seguridad de red para permitir el acceso en el puerto deseado.

Para más información, consulte Configuración de la infraestructura de Application Gateway.

Configuración no válida o incorrecta de sondeos de estado personalizados

Causa

Los sondeos de salud personalizados proporcionan más flexibilidad que el comportamiento de sondeo por defecto. Cuando se utilizan sondeos personalizados, puede establecer el intervalo de sondeo, la URL, la ruta a probar y cuántas respuestas con error se aceptarán antes de marcar la instancia del grupo de back-end como no saludable.

En la tabla siguiente se describen las propiedades adicionales que puede establecer:

Solución

Compruebe que ha configurado correctamente el sondeo de estado personalizado, como se muestra en la tabla anterior. Además de los pasos de solución de problemas anteriores, asegúrese también de los pasos siguientes:

• Asegúrese de especificar el sondeo correctamente según la guía.
• Si configura la puerta de enlace de aplicaciones para un único sitio, especifique el nombre de host predeterminado como 127.0.0.1, a menos que configure lo contrario en el sondeo personalizado.
• Asegúrese de que una llamada a http://<host>:<port><path> devuelve un código de resultado HTTP de 200.
• Asegúrese de que los valores Interval, Timeout y UnhealthyThreshold estén dentro de los intervalos aceptables.
• Si usa un sondeo HTTPS, asegúrese de que el servidor backend no requiera SNI configurando un certificado de respaldo en el propio servidor backend.

Problemas de tiempo de espera o conectividad relacionados con solicitudes de usuario

Causa

Cuando la puerta de enlace de aplicaciones recibe una solicitud de usuario, aplica las reglas configuradas a la solicitud y la enruta a una instancia del grupo de back-end. Espera un intervalo de tiempo configurable para una respuesta de la instancia de back-end. De forma predeterminada, este intervalo es de 20 segundos. En Application Gateway v1, si la puerta de enlace de aplicaciones no recibe una respuesta de la aplicación back-end en este intervalo, la solicitud de usuario recibe un error 502. En Application Gateway v2, si la puerta de enlace de aplicaciones no recibe una respuesta de la aplicación back-end en este intervalo, la solicitud se intenta en un segundo miembro del grupo de back-end. Si se produce un error en la segunda solicitud, la solicitud de usuario recibe un error 504.

Solución

Puede configurar esta opción a través de BackendHttpSetting, que puede aplicar a grupos diferentes. Los distintos grupos de back-end pueden tener diferentes configuraciones de BackendHttpSetting y diferentes opciones de tiempo de espera de solicitud.

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

El grupo de servidores de respaldo de Application Gateway no está configurado o está vacío

Causa

Si la puerta de enlace de aplicaciones no tiene máquinas virtuales ni conjuntos de escalado de máquinas virtuales configurados en el grupo de direcciones de back-end, no puede enrutar ninguna solicitud de cliente y envía un error de puerta de enlace incorrecta.

Solución

Asegúrese de que el grupo de direcciones de back-end no esté vacío. Puede comprobar esta condición a través de PowerShell, la CLI o el portal.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

La salida del cmdlet anterior debe contener un grupo de direcciones de back-end no vacías. En el ejemplo siguiente se muestran dos grupos devueltos que están configurados con un FQDN o direcciones IP para las máquinas virtuales de back-end. El estado de aprovisionamiento de BackendAddressPool debe ser Succeeded.

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Instancias no saludables en BackendAddressPool

Causa

Si todas las instancias de BackendAddressPool no están disponibles, la puerta de enlace de aplicaciones BackendAddressPool no tiene ningún backend al que enrutar las solicitudes de usuario. Esta condición también puede producirse cuando las instancias de back-end están en buen estado, pero no tienen implementada la aplicación necesaria.

Solución

Asegúrese de que las instancias están en buen estado y que la aplicación está configurada correctamente. Compruebe si las instancias de back-end pueden responder a un ping desde otra máquina virtual de la misma red virtual. Si configura un punto de conexión público, asegúrese de que se puede atender una solicitud del explorador a la aplicación web.

El certificado SSL de origen no coincide

Causa

El certificado TLS instalado en los servidores back-end no coincide con el nombre de host recibido en el encabezado de solicitud de host.

En escenarios en los que TLS de un extremo a otro está habilitado, una configuración que se logra editando la "Configuración HTTP de Backend" adecuada y cambiando allí la configuración del "protocolo de backend" a HTTPS, es obligatorio asegurarse de que el NOMBRE DNS del certificado TLS instalado en los servidores backend coincida con el nombre de host recibido por el backend en la solicitud de encabezado del host HTTP.

Como recordatorio, el efecto de habilitar en "Configuración HTTP de back-end" la opción de protocolo HTTPS en lugar de HTTP, es que la segunda parte de la comunicación que se produce entre las instancias de Application Gateway y los servidores back-end se cifran con TLS.

Debido al hecho de que, de forma predeterminada, Application Gateway envía el mismo encabezado de host HTTP al back-end que recibe del cliente, debe asegurarse de que el certificado TLS instalado en el servidor back-end se emite con un NOMBRE DNS que coincida con el nombre de host recibido por ese servidor back-end en el encabezado de host HTTP. Recuerde que, a menos que se especifique lo contrario, este nombre de host sería el mismo que el recibido del cliente.

Por ejemplo:

Imagine que tiene una instancia de Application Gateway para atender las solicitudes https para el dominio www.contoso.com. Podría tener el dominio contoso.com delegado a una zona pública de Azure DNS y un registro DNS A en esa zona que apunte www.contoso.com a la dirección IP pública de la instancia específica de Application Gateway que va a atender las solicitudes.

En esa instancia de Application Gateway, debe tener un agente de escucha para el host www.contoso.com con una regla que tenga la "Configuración HTTP respaldada" forzada a usar HTTPS del protocolo (garantizando TLS de un extremo a otro). Esa misma regla podría haber configurado un grupo de back-end con dos máquinas virtuales que ejecutan IIS como servidores web.

Como sabemos, al habilitar HTTPS en la "Configuración HTTP del backend" de la regla, la segunda parte de la comunicación que ocurre entre las instancias del Application Gateway y los servidores del backend utiliza TLS.

Si los servidores de backend no tienen un certificado TLS emitido para el NOMBRE www.contoso.com DNS o *.contoso.com, la solicitud falla con Error del servidor: 502 - El servidor web recibió una respuesta no válida mientras actuaba como puerta de enlace o servidor proxy porque el certificado SSL ascendente (el certificado instalado en los servidores de backend) no coincide con el nombre de host en el encabezado de host y, por lo tanto, se produce un error en la negociación TLS.

www.contoso.com --> DIRECCIÓN IP de APP GW de front-end --> Agente de escucha con una regla que configura "Configuración HTTP de back-end" para usar el protocolo HTTPS en lugar de HTTP --> Grupo de back-end --> Servidor web (debe tener instalado un certificado TLS para www.contoso.com)

Solución

Es necesario que el NOMBRE DNS del certificado TLS instalado en el servidor back-end coincida con el nombre de host configurado en la configuración del back-end HTTP; de lo contrario, la segunda parte de la comunicación de un extremo a otro que se produce entre las instancias de Application Gateway y el back-end, produce un error con "El certificado SSL ascendente no coincide" y produce un error de servidor: 502: el servidor web recibió una respuesta no válida mientras actúa como puerta de enlace o servidor proxy