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 "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:

• Problema de grupo de seguridad de red (NSG), ruta definida por el usuario (UDR) o sistema de nombres de dominio (DNS) personalizado
• El sondeo de estado predeterminado no puede acceder a las máquinas virtuales de back-end
• Se ha superado el tiempo de espera de la solicitud del backend
• El grupo de back-end 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.

Es posible que tenga un NSG o una UDR, ya sea en la subred de la puerta de enlace de aplicación o en la subred donde están implementadas las máquinas virtuales (VM) de la aplicación.

Del mismo modo, la presencia de un DNS personalizado en la red virtual (VNet) también puede causar problemas. Es posible que el servidor DNS configurado por el usuario para la red virtual no resuelva correctamente un nombre de dominio completo (FQDN) usado para los miembros del grupo de back-end.

Solución

Valide las configuraciones de NSG, UDR y DNS. Para ello, 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 la UDR asociada a la subred de Application Gateway. Asegúrese de que la UDR no esté redirigiendo el tráfico fuera de la subred de backend. Por ejemplo, compruebe si hay enrutamiento hacia dispositivos virtuales de red o rutas predeterminadas anunciadas a la subred de Application Gateway mediante Azure ExpressRoute o Azure VPN. Ejecute los siguientes comandos en Azure PowerShell.

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

3. Compruebe los NSG y las rutas efectivas de la máquina virtual de back-end. Ejecute los siguientes comandos en Azure PowerShell.

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

4. Compruebe la presencia de DNS personalizado en la red virtual. Compruebe la configuración de DNS consultando los detalles de las propiedades de la VNet 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

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

Cuando aprovisiona una instancia de Application Gateway, se configura automáticamente un sondeo de estado predeterminado para cada BackendAddressPool mediante las propiedades del 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 Application Gateway inicia periódicamente una conexión de comprobación de estado con cada instancia del 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

Use las siguientes instrucciones para solucionar los problemas de la sonda de estado predeterminada.

• 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 BackendHttpSetting protocolo 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 de que no haya reglas de cortafuegos ni NSG de Azure que bloqueen 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 mediante Azure Resource Manager (ARM) y está fuera de la red virtual donde se implementa Application Gateway, configure un NSG para permitir el acceso en el puerto que desee.

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 la guía de solución de problemas anterior, siga también esta guía.

• 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 lo configure en caso 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 Intervallos valores , Timeouty UnhealthyThreshold están dentro de los intervalos aceptables.
• Si usa un sondeo HTTPS en la SKU v2, Application Gateway también envía el nombre de host del sondeo como valor de SNI. Asegúrese de que el nombre de host coincida con el nombre alternativo del sujeto (SAN) del certificado del backend, o con su nombre común (CN) si el certificado no tiene SAN, como se describe en RFC 6125. Application Gateway no envía SNI cuando el nombre de host es una dirección IP, incluido el valor predeterminado 127.0.0.1. Para ver los pasos para comparar el nombre de host de sondeo con el certificado, consulte Resolución F en Solución de errores HTTP 502 en Azure Application Gateway. Si no puede cambiar el certificado de back-end, ajuste la configuración de validación HTTPS de back-end para usar un valor SNI específico o omitir la validación del nombre del firmante.

Se ha superado el tiempo de espera de la solicitud al backend

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 dentro de este intervalo, la solicitud del usuario recibe un error 502. En Application Gateway v2, si Application Gateway no recibe una respuesta de la aplicación de back-end dentro de este intervalo, la solicitud se vuelve a intentar con un segundo miembro del grupo de back-end. Si también se produce un error en la segunda solicitud, la solicitud de usuario obtiene un error 504 en su lugar. Si los usuarios reciben errores 504 en lugar de errores 502, consulte Solucionar errores HTTP 504 en Azure Application Gateway.

Si la aplicación back-end tarda habitualmente más tiempo que el intervalo configurado para responder (por ejemplo, una consulta o informe de larga duración), aumente el tiempo de espera de la solicitud en la configuración HTTP de back-end usada por ese grupo de back-end.

Solución

El tiempo de espera de la solicitud es una propiedad de la configuración HTTP de back-end, por lo que los distintos grupos de back-end pueden tener valores de tiempo de espera de solicitud diferentes. Auméntelo con el portal de Azure, CLI de Azure o Azure PowerShell. El intervalo aceptado es de 1 a 86400 segundos. Para obtener más información, consulte Tiempo de espera de solicitud.

Portal de Azure

Siga estos pasos:

1. En el portal de Azure, vaya a la puerta de enlace de aplicaciones.
2. En Configuración, seleccione Configuración del backend.
3. Seleccione la configuración de back-end usada por el grupo de back-end afectado.
4. Aumente el valor tiempo de espera de solicitud (segundos) para permitir más tiempo para que el back-end responda.
5. Haga clic en Guardar.

CLI de Azure

Ejecute el siguiente comando en la CLI de Azure:

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Ejecute el comando siguiente en Azure PowerShell:

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

El grupo de back-end 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 Azure PowerShell, CLI de Azure o el portal. Consulte el ejemplo siguiente para comprobar el grupo de direcciones de back-end a través de Azure PowerShell.

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.

[{
    "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 de seguridad de la capa de transporte (TLS) instalado en los servidores back-end no coincide con el nombre de host recibido en el encabezado de solicitud de host HTTP.

En los escenarios en los que está habilitado TLS de extremo a extremo, realice esta configuración editando los ajustes adecuados de HTTP Backend. Cambie la configuración de Backend protocol a HTTPS cuando sea necesario. Asegúrese de que el DNS NAME del certificado TLS instalado en los servidores de back-end coincida con el nombre de host que se envía al back-end en el encabezado Host de la solicitud HTTP.

Cuando complete este paso, la segunda parte de la comunicación que se produce con Application Gateway y los servidores back-end se cifran con TLS.

De forma predeterminada, Application Gateway envía el mismo encabezado de host HTTP al back-end que recibe del cliente. Asegúrese de que el certificado TLS instalado en el servidor back-end se emite con un DNS NAME que coincide con el nombre de host recibido por ese servidor back-end en el encabezado de host HTTP. Este nombre de host debe ser el mismo que el recibido del cliente.

Solución

Para conocer los pasos para alinear el nombre de host de sondeo y SNI con la SAN o CN del certificado, consulte Resolución F en Solución de errores HTTP 502 en Azure Application Gateway. Para saber cómo las configuraciones de back-end Elegir el nombre de host del destino de back-end y Invalidar con un nombre de dominio específico se asignan al nombre del certificado que espera Application Gateway, consulte El nombre común (CN) no coincide.