Compartir vía

Solución de errores de puerta de enlace incorrecta en el servicio Application Gateway

  • Artículo

Aprenda a solucionar problemas de errores de puerta de enlace incorrecta (502) recibidos al usar Azure Application Gateway.

Nota:

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para empezar, 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.

Información general

Después de configurar una instancia de Application Gateway, uno de los errores que pueden encontrar los usuarios es Error de servidor: 502: el servidor web ha recibido una respuesta no válida mientras actuaba como puerta de enlace o servidor proxy. Este error puede ocurrir debido a los siguientes motivos principales:

Problema con grupo de seguridad de red, ruta definida por el usuario o DNS personalizado

Causa

Si el acceso al back-end se bloquea debido a un grupo de seguridad de red, una ruta definida por el usuario o un DNS personalizado, las instancias de Application Gateway no podrán alcanzar el grupo de back-end. Este problema provoca fallos de sondeo y genera errores 502.

Tenga en cuenta que el grupo de seguridad de red y la ruta definida por el usuario pueden estar presentes en la subred de Application Gateway o en la subred donde están implementadas las VM de la aplicación.

De forma similar, la presencia de un DNS personalizado en la red virtual también puede provocar problemas. Es posible que un FQDN utilizado para los miembros del grupo de back-end no se resuelva correctamente en el servidor DNS configurado por el usuario para la red virtual.

Solución

Valide la configuración de NSG, UDR y DNS mediante los pasos siguientes:

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

  2. Compruebe la ruta definida por el usuario asociada a la subred de Application Gateway. Asegúrese de que la ruta definida por el usuario no esté alejando el tráfico de la subred de back-end. Por ejemplo, compruebe el enrutamiento a aplicaciones virtuales de red o las rutas predeterminadas anunciadas en la subred de Application Gateway mediante ExpressRoute/VPN.

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

  3. Compruebe el grupo de seguridad de red y la ruta efectivos con la máquina virtual de back-end.

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

  4. Compruebe la presencia de DNS personalizado en la red virtual. El DNS se puede comprobar examinando los detalles de las propiedades de 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 de los miembros del grupo de back-end.

Problemas con la sonda de estado predeterminada

Causa

Los errores 502 también pueden ser indicativos frecuentes de que el sondeo de estado predeterminado no puede alcanzar las VM de backend.

Cuando se aprovisiona una instancia de Application Gateway, se configura automáticamente un sondeo de estado predeterminado para cada elemento BackendAddressPool que utiliza las propiedades de BackendHttpSetting. El usuario no tiene que escribir datos para establecer esta sonda. En concreto, cuando se configura una regla de equilibrio de carga, se crea una asociación entre un elemento BackendHttpSetting y otro BackendAddressPool. Se ha configurado un sondeo predeterminado para cada una de estas asociaciones y la instancia de Application Gateway inicia una conexión de comprobación de estado periódica en cada instancia del elemento BackendAddressPool en el puerto especificado en el elemento BackendHttpSetting.

En la tabla siguiente se enumeran los valores asociados con el sondeo de estado predeterminado.

Propiedad de sondeo Value Descripción
Dirección URL de sondeo http://127.0.0.1/ Ruta de acceso URL
Intervalo 30 Intervalo de sondeo en segundos
Tiempo de espera 30 Tiempo de espera del sondeo en segundos
Umbral incorrecto 3 Número de reintentos de sondeo. El servidor backend se marca como inactivo después de que el número de errores de sondeo consecutivos alcanza el umbral de incorrecto.

Solución

  • El valor de host de la solicitud se establecerá en 127.0.0.1. Asegúrese de que se ha configurado un sitio predeterminado y de que está escuchando en 127.0.0.1.
  • El protocolo BackendHttpSetting determina el protocolo de la solicitud.
  • La ruta de acceso URI se establecerá en /.
  • Si BackendHttpSetting especifica un puerto distinto de 80, se debe configurar que el sitio predeterminado escuche en ese puerto.
  • La llamada a protocol://127.0.0.1:port debe devolver el código de resultado HTTP 200. Este código debe devolverse dentro del periodo de espera de 30 segundos.
  • Asegúrese de que el puerto configurado esté abierto y que no haya reglas de firewall o grupos de seguridad de red de Azure que bloqueen el tráfico entrante o saliente en el puerto configurado.
  • Si usa el servicio en la nube o las VM clásicas de Azure con un FQDN o una IP pública, asegúrese de que esté abierto el punto de conexión correspondiente.
  • Si la VM se configura mediante Azure Resource Manager y se encuentra fuera de la red virtual donde se implementó la instancia de Application Gateway, se 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.

Problemas con la sonda de estado personalizada

Causa

Las sondas de estado personalizadas dotan al comportamiento de sondeo predeterminado de mayor flexibilidad. Si usa sondeos personalizados, puede configurar el intervalo de sondeo, la dirección URL, la ruta de acceso a la prueba y la cantidad de respuestas erróneas que se aceptan antes de marcar la instancia del grupo de backend como incorrecta.

Se han agregado las siguientes propiedades adicionales:

Propiedad de sondeo Descripción
Nombre Nombre del sondeo. Este nombre se usa para hacer referencia al sondeo en la configuración de HTTP de backend.
Protocolo Protocolo usado para enviar el sondeo. El sondeo utiliza el protocolo definido en la configuración de HTTP del backend
Host Nombre de host para enviar el sondeo. Solo es aplicable cuando se ha configurado un entorno multisitio en la instancia de Application Gateway. Es diferente al nombre de host de máquina virtual.
Path Ruta de acceso relativa del sondeo. La ruta de acceso válida se inicia desde '/'. La sonda se envía a <protocolo>://<host>:<puerto><ruta de acceso>
Intervalo Intervalo de sondeo en segundos. Es el intervalo de tiempo entre dos sondeos consecutivos.
Tiempo de espera Tiempo de espera del sondeo en segundos. Si no se recibe una respuesta válida dentro del período de espera, el sondeo se marca como erróneo.
Umbral incorrecto Número de reintentos de sondeo. El servidor backend se marca como inactivo después de que el número de errores de sondeo consecutivos alcanza el umbral de incorrecto.

Solución

Valide que el sondeo de mantenimiento personalizado esté configurado correctamente según la tabla anterior. Además de realizar los pasos de solución de problemas anteriores, no se olvide tampoco de llevar a cabo estos:

  • Asegúrese de que la sonda se ha especificado correctamente según la guía.
  • Si la instancia de Application Gateway está configurada para un único sitio, el nombre de host debería especificarse de forma predeterminada como 127.0.0.1, salvo que se configure de otra manera en el sondeo personalizado.
  • Asegúrese de que una llamada a http://<host>:<puerto><ruta de acceso> devuelva el código de resultado HTTP 200.
  • Compruebe que los valores de Interval, Timeout y UnhealtyThreshold estén dentro de los rangos aceptables.
  • Si utiliza un sondeo HTTPS, asegúrese de que el servidor de back-end no requiera SNI; para ello, configure un certificado de reserva en dicho servidor.

Tiempo de espera de solicitud superado

Causa

Cuando se recibe una solicitud de usuario, la puerta de enlace de aplicación aplica las reglas configuradas a la solicitud y la enruta a una instancia del grupo de backend. Espera, durante un intervalo de tiempo que puede configurarse, una respuesta de la instancia de backend. De forma predeterminada, este intervalo es de 20 segundos. En Application Gateway v1, si la puerta de enlace de aplicación no recibe una respuesta de la aplicación de backend en este intervalo, la solicitud de usuario obtiene un error 502. En Application Gateway v2, si la puerta de enlace de aplicación no recibe una respuesta de la aplicación de backend en este intervalo, la solicitud se probará en un segundo miembro del grupo de backend. Si se produce un error en la segunda solicitud, la solicitud de usuario obtiene un error 504.

Solución

La instancia de Application Gateway le permite configurar esta opción mediante BackendHttpSetting que, posteriormente, puede aplicarse a diferentes grupos. Diferentes grupos de backend pueden tener distintos elementos BackendHttpSetting y un tiempo de espera de solicitud diferente configurado.

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

Valor de BackendAddressPool vacío

Causa

Si la puerta de enlace de aplicación no tiene ninguna VM ni ningún conjunto de escalado de máquinas virtuales configurado en el grupo de direcciones de backend, 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 backend no está vacío. Puede hacerlo mediante PowerShell, la CLI o el Portal.

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

El resultado del cmdlet anterior debe contener un grupo de direcciones backend que no esté vacío. El ejemplo siguiente muestra dos grupos devueltos que están configurados con un FQDN o una dirección IP para las máquinas virtuales de back-end. El estado de aprovisionamiento de BackendAddressPool debe ser "Correcto".

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 incorrectas en BackendAddressPool

Causa

Si todas las instancias de BackendAddressPool son incorrectas, la puerta de enlace de aplicación no tendrá ningún backend al que enrutar la solicitud de usuario. Esto también podría suceder si las instancias backend son correctas, pero no tienen implementada la aplicación necesaria.

Solución

Asegúrese de que las instancias son correctas y de que la aplicación está configurada de la forma adecuada. Compruebe si las instancias de backend pueden responder a un ping de otra VM de la misma red virtual. Si se configura con un punto de conexión público, asegúrese de que se pueda utilizar una solicitud de explorador a la aplicación web.

El certificado SSL ascendente 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 back-end" adecuada y cambiando la configuración del "protocolo back-end" a HTTPS, es obligatorio asegurarse de que el CNAME del certificado TLS instalado en los servidores back-end coincide con el nombre de host que va al back-end en la solicitud de encabezado del host HTTP.

Como recordatorio, el efecto de habilitar en la "Configuración HTTP de back-end" la opción de protocolo HTTPS en lugar de HTTP, será que la segunda parte de la comunicación que se produce entre las instancias de Application Gateway y los servidores back-end se cifrarán 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, deberá asegurarse de que el certificado TLS instalado en el servidor back-end se emite con un CNAME 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 que se recibió del cliente.

Por ejemplo:

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

En esa instancia de Application Gateway, debe tener un cliente de escucha para el host www.contoso.com con una regla que tenga la opción "Configuración HTTP respaldada" forzada a usar el protocolo HTTPS (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, habilitar HTTPS en la "Configuración HTTP respaldada" de la regla hará la segunda parte de la comunicación que se produce entre las instancias de Application Gateway y los servidores del back-end para usar TLS.

Si los servidores back-end no tienen un certificado TLS emitido para el CNAME www.contoso.com o *.contoso.com, la solicitud producirá un error de servidor: 502 - el servidor web recibió una respuesta no válida mientras actúa como puerta de enlace o servidor proxy porque el certificado SSL ascendente (el certificado instalado en los servidores back-end) no coincidirá con el nombre de host del encabezado de host, y, por lo tanto, se producirá un error en la negociación de TLS.

www.contoso.com -->IP de front-end de APP GW --> cliente 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 CNAME del certificado TLS instalado en el servidor back-end coincida con el nombre de host configurado en la configuración de 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, producirá un error "El certificado SSL ascendente no coincide" y producirá un error de servidor: 502 - el servidor web recibió una respuesta no válida mientras actúa como puerta de enlace o servidor proxy.

Pasos siguientes

Si los pasos anteriores no resuelven el problema, abra una incidencia de soporte técnico.