Compartir vía

Solución de problemas de estado del back-end en Application Gateway

  • Artículo

Información general

De forma predeterminada, Application Gateway sondea los servidores back-end para comprobar su estado de mantenimiento y si están listos para atender solicitudes. Los usuarios pueden crear también sondeos personalizados para mencionar el nombre de host, la ruta de acceso que se va a sondear y los códigos de estado que se van a aceptar como correctos. En cada caso, si el servidor back-end no responde correctamente, Application Gateway lo marca como incorrecto y deja de reenviarle solicitudes. Una vez que el servidor comienza a responder correctamente, Application Gateway reanuda el reenvío de las solicitudes.

Comprobación del estado del servidor back-end

Para comprobar el mantenimiento del grupo back-end, puede usar la página Estado del back-end en Azure Portal. O bien, puede utilizar Azure PowerShell, la CLI o una API REST.

El estado recuperado por cualquiera de estos métodos puede ser uno de los siguientes estados:

  • Healthy
  • Unhealthy (Incorrecto)
  • Unknown

Application Gateway reenvía una solicitud a un servidor desde el grupo de back-end si su estado es correcto. Si todos los servidores de un grupo de back-end son incorrectos o desconocidos, los clientes podrían encontrar problemas para acceder a la aplicación back-end. Lea más información para comprender los distintos mensajes notificados por estado de back-end, sus causas y su resolución.

Nota:

Si el usuario no tiene permiso para ver los estados de mantenimiento del backend, se mostrará la salida No results..

Estado de mantenimiento del backend: incorrecto

Si el estado de mantenimiento del back-end es incorrecto, la vista del portal se parecerá a la siguiente captura de pantalla:

Estado del back-end de Application Gateway: incorrecto

Si usa una consulta de Azure PowerShell, la CLI o la API de REST de Azure, obtendrá una respuesta similar al siguiente ejemplo:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Después de recibir un estado incorrecto para todos los servidores de un grupo back-end, las solicitudes no se reenvían a los servidores y Application Gateway devuelve un error "502 Puerta de enlace incorrecta" al cliente que realiza la solicitud. Para solucionar este problema, compruebe la columna Detalles de la pestaña Estado del back-end.

El mensaje que se muestra en la columna Detalles proporciona información más detallada sobre el problema y, según dicha información, podemos empezar a solucionarlo.

Nota:

La solicitud de sondeo predeterminada se envía en formato de <protocolo>://127.0.0.1:<puerto>. Por ejemplo, http://127.0.0.1:80 para un sondeo HTTP en el puerto 80. Solo los códigos de estado HTTP del 200 al 399 se consideran correctos. El protocolo y el puerto de destino se heredan de la configuración de HTTP. Si quiere que Application Gateway sondee en un protocolo, un nombre de host o una ruta de acceso diferentes, y acepte como correcto un código de estado distinto, configure un sondeo personalizado y asócielo con la configuración de HTTP.

Mensajes de error

Tiempo de espera del servidor back-end

Mensaje: el tiempo que tarda el servidor back-end en responder al sondeo de estado de Application Gateway es mayor que el umbral de tiempo de espera de la configuración del sondeo.

Causa: una vez que Application Gateway envía una solicitud de sondeo HTTP(S) al servidor back-end, espera su respuesta durante un período configurado. Si el servidor backend no responde dentro de este período (el valor de tiempo de expiración), se marca como incorrecto hasta que responda de nuevo en el período de tiempo de expiración configurado.

Resolución: compruebe por qué el servidor back-end o la aplicación no responden dentro del período de espera configurado, y compruebe también las dependencias de la aplicación. Por ejemplo, compruebe si la base de datos tiene algún problema que pueda desencadenar un retraso en la respuesta. Si tiene constancia del comportamiento de la aplicación y debe responder solo después del valor de tiempo de espera, aumente el valor de tiempo de espera en la configuración de sondeo personalizado. Debe tener un sondeo personalizado para cambiar el valor de tiempo de espera. Para información sobre cómo configurar un sondeo personalizado, consulte la página de documentación.

Para aumentar el valor de tiempo de espera, siga estos pasos:

  1. Acceda directamente al servidor back-end y compruebe el tiempo que tarda el servidor en responder en esa página. Puede usar cualquier herramienta para acceder al servidor back-end, como un explorador con herramientas de desarrollo.
  2. Cuando haya averiguado el tiempo necesario para que la aplicación responda, seleccione la pestaña Sondeos de estado y, luego, seleccione el sondeo que está asociado a la configuración de HTTP.
  3. Especifique un valor de tiempo de espera mayor que el tiempo de respuesta de la aplicación, en segundos.
  4. Guarde la configuración de sondeo personalizada y compruebe si el estado del back-end aparece ahora como correcto.

Error de resolución DNS

Mensaje: Application Gateway no pudo crear un sondeo para este backend. Esto suele ocurrir cuando el FQDN del backend no se escribe correctamente. 

Causa: si el grupo back-end es de tipo dirección IP, FQDN (nombre de dominio completo) o App Service, Application Gateway resuelve la dirección IP del FQDN especificado mediante DNS (personalizado o predeterminado de Azure). A continuación, la puerta de enlace de aplicaciones intenta conectarse al servidor en el puerto TCP mencionado en la configuración HTTP. Sin embargo, la aparición de este mensaje sugiere que Application Gateway no pudo resolver correctamente la dirección IP del nombre de dominio completo especificado.

Resolución:

  1. Compruebe que el nombre de dominio completo especificado en el grupo back-end sea correcto y que sea un dominio público y, luego, intente resolverlo desde la máquina local.
  2. Si puede resolver la dirección IP, podría haber algún problema con la configuración DNS en la red virtual.
  3. Compruebe si la red virtual está configurada con un servidor DNS personalizado. Si es así, compruebe el servidor DNS para ver por qué no puede resolver la dirección IP del nombre de dominio completo especificado.
  4. Si usa el DNS predeterminado de Azure, compruebe con su registrador de nombres de dominio que se haya completado correctamente la asignación de registro A o CNAME.
  5. Si el dominio es privado o interno, intente resolverlo desde una máquina virtual de la misma red virtual. Si puede resolverlo, reinicie Application Gateway y vuelva a comprobarlo. Para reiniciar Application Gateway, debe detenerlo e iniciarlo mediante los comandos de PowerShell descritos en estos servicios vinculados.

Error de conexión TCP

Mensaje: Application Gateway no se pudo conectar al backend. Compruebe que el back-end responde en el puerto utilizado para el sondeo. Also check whether any NSG/UDR/Firewall is blocking access to the Ip and port of this backend (Application Gateway no pudo conectarse al back-end. Compruebe que el back-end responde en el puerto usado para el sondeo. Compruebe también si NSG, UDR o el Firewall están bloqueando el acceso a la dirección IP y al puerto de este back-end).

Causa: después de la fase de resolución de DNS, Application Gateway intenta conectarse al servidor backend en el puerto TCP establecido en la configuración de HTTP. Si Application Gateway no puede establecer una sesión TCP en el puerto especificado, el sondeo se marca como incorrecto con este mensaje.

Solución: si recibe este error, siga estos pasos:

  1. Compruebe si puede conectarse al servidor back-end en el puerto mencionado en la configuración HTTP mediante un explorador o PowerShell. Por ejemplo, ejecute el siguiente comando: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Si el puerto mencionado no es el deseado, escriba el número de puerto correcto para que Application Gateway se conecte al servidor back-end.

  3. Si no puede conectarse tampoco en el puerto desde la máquina local, entonces:

    a. Compruebe la configuración del grupo de seguridad de red (NSG) del adaptador de red y la subred del servidor back-end y si se permiten conexiones entrantes al puerto configurado. Si no están permitidas, cree una regla para hacerlo. Para aprender a crear reglas de NSG, consulte la página de documentación.

    b. Compruebe si la configuración de NSG de la subred de Application Gateway permite el tráfico saliente público y privado, de modo que se pueda realizar una conexión. Consulte la página del documento que se proporciona en el paso 3A para más información sobre cómo crear reglas de NSG.

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

    c. Compruebe la configuración de las rutas definidas por el usuario (UDR) de Application Gateway y la subred del servidor back-end para ver si existe alguna anomalía de enrutamiento. Asegúrese de que la UDR no esté alejando el tráfico de la subred de back-end. Por ejemplo, busque rutas a las aplicaciones virtuales de red o rutas predeterminadas anunciadas en la subred de Application Gateway mediante Azure ExpressRoute o VPN.

    d. Para buscar un adaptador de red en las rutas y reglas actuales, puede usar los siguientes comandos de PowerShell:

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

  4. Si no encuentra ningún problema con el grupo de NSG o la UDR, compruebe el servidor back-end para ver si existen problemas relacionados con la aplicación que impidan que los clientes establezcan una sesión TCP en los puertos configurados. Puntos que hay que comprobar:

    a. Abra un símbolo del sistema (Win+R-> cmd), escriba netstat y seleccione Entrar.

    b. Compruebe si el servidor está escuchando en el puerto configurado. Por ejemplo:

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. Si no está escuchando en el puerto configurado, compruebe la configuración del servidor web. Por ejemplo: enlaces de sitio en IIS, bloqueo del servidor en NGINX y host virtual en Apache.

    d. Compruebe la configuración de firewall del sistema operativo para asegurarse de que se permite el tráfico entrante al puerto.

Error de coincidencia en el código de estado HTTP

Mensaje: el código de estado de la respuesta HTTP del back-end no coincidía con la configuración del sondeo. Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}. (El código de estado de la respuesta HTTP del back-end no coincidía con la configuración de sondeo. Se esperaba: {HTTPStatusCode0} Se recibió: {HTTPStatusCode1}).

Causa: después de haber establecido la conexión TCP y haber realizado el protocolo de enlace TLS (si TLS está habilitado), Application Gateway enviará el sondeo como una solicitud HTTP GET al servidor backend. Tal y como se ha mencionado anteriormente, el sondeo predeterminado se establece en <protocol>://127.0.0.1:<port>/, y se considera que los códigos de estado de respuesta en el intervalo de 200 a 399 son correctos. Si el servidor devuelve cualquier otro código de estado, se marcará como incorrecto con este mensaje.

Solución: en función del código de respuesta del servidor backend, puede realizar los pasos siguientes. A continuación se enumeran algunos de los códigos de estado comunes:

Error Acciones
Error de coincidencia de código de estado de sondeo: recibido 401 Compruebe si el servidor back-end necesita autenticación. Los sondeos de Application Gateway no pueden pasar credenciales para la autenticación. Permita "HTTP 401" en una coincidencia de código de estado de sondeo o sondee en una ruta de acceso en la que el servidor no requiera autenticación.
Error de coincidencia de código de estado de sondeo: recibido 403 Acceso prohibido. Compruebe si se permite el acceso a la ruta de acceso en el servidor back-end.
Error de coincidencia de código de estado de sondeo: recibido 404 Página no encontrada. Compruebe si la ruta de acceso del nombre de host es accesible en el servidor back-end. Cambie el nombre de host o el parámetro de ruta de acceso por un valor accesible.
Error de coincidencia de código de estado de sondeo: recibido 405 Las solicitudes de sondeo de Application Gateway usan el método HTTP GET. Compruebe si el servidor lo permite.
Error de coincidencia de código de estado de sondeo: recibido 500 Error interno del servidor. Compruebe el estado del servidor back-end y si los servicios se están ejecutando.
Error de coincidencia de código de estado de sondeo: recibido 503 Servicio no disponible. Compruebe el estado del servidor back-end y si los servicios se están ejecutando.

O bien, si cree que la respuesta es legítima y desea que Application Gateway acepte otros códigos de estado como correctos, puede crear un sondeo personalizado. Este enfoque es útil en situaciones en las que el sitio web de back-end necesita autenticación. Dado que las solicitudes de sondeo no incluyen ninguna credencial de usuario, generarán un error y el servidor backend devolverá un código de estado HTTP 401.

Para crear un sondeo personalizado, siga estos pasos.

Error de coincidencia del cuerpo de la respuesta HTTP

Mensaje: el cuerpo de la respuesta HTTP del back-end no coincidía con la configuración del sondeo. Received response body does not contain {string}.

Causa: al crear un sondeo personalizado, puede marcar un servidor back-end con estado Correcto si hace coincidir una cadena del cuerpo de respuesta. Por ejemplo, puede configurar Application Gateway para que acepte "no autorizado" como una cadena que coincida. Si la respuesta del servidor back-end para la solicitud de sondeo contiene la cadena no autorizado, se marcará como correcta. De lo contrario, se marcará como incorrecta y se generará este mensaje.

Solución: para resolver este problema, siga estos pasos:

  1. Acceda al servidor back-end localmente o desde una máquina cliente en la ruta de acceso de sondeo y compruebe el cuerpo de respuesta.
  2. Vea si el cuerpo de la respuesta de la configuración de sondeo personalizado de Application Gateway coincide con lo que se ha configurado.
  3. Si no coinciden, cambie la configuración de sondeo para que tenga el valor de cadena correcto para aceptar.

Más información sobre la coincidencia del sondeo de Application Gateway.

Nota:

En el caso de todos los mensajes de error relacionados con TLS, para obtener más información sobre el comportamiento de SNI y las diferencias entre las versiones 1 y 2 de la SKU, consulte la página de información general de TLS.

El nombre común (CN) no coincide

Mensaje: (para V2) el nombre común del certificado hoja presentado por el servidor backend no coincide con el nombre de host de la sonda o la configuración de backend de la puerta de enlace de aplicaciones. aplicaciones.
(Para V1) El nombre común (CN) del certificado backend no coincide.

Causa: (para V2) esto ocurre cuando selecciona el protocolo HTTPS en la configuración de backend, y ni el nombre de host de la configuración de backend ni del sondeo personalizado (en ese orden) coinciden con el nombre común (CN) del certificado del servidor backend.
(Para V1) El FQDN del destino del grupo de backend no coincide con el nombre común (CN) del certificado del servidor backend.

Solución: la información del nombre de host es fundamental para la conexión HTTPS de backend, ya que ese valor se usa para establecer la indicación de nombre del servidor (SNI) durante el protocolo de enlace TLS. Puede corregir este problema de las siguientes maneras en función de la configuración de la puerta de enlace.

Para V2,

  • Si está utilizando una sondeo predeterminado, puede especificar un nombre de host en la configuración de backend asociada de su puerta de enlace de aplicaciones. Puede seleccionar “Invalidar con un nombre” de host específico o “Elegir nombre de host del destino” de backend en la configuración de backend.
  • Si usa un sondeo personalizado: para sondeo personalizado, puede usar el campo "host" para especificar el nombre común del certificado de servidor backend. Como alternativa, si la configuración de backend ya está configurada con el mismo nombre de host, puede elegir "Seleccionar nombre de host de la configuración de backend" en la configuración del sondeo.

Para V1, compruebe que el FQDN del destino del grupo de backend es el mismo nombre común (CN).

Sugerencias: para determinar el nombre común (CN) del certificado del servidor backend, puede usar cualquiera de estos métodos. Tenga en cuenta también que, en función de RFC 6125, si existe una SAN, la comprobación de SNI solo se realiza en ese campo. El campo de nombre común coincide si no hay ninguna SAN en el certificado.

  • Mediante el uso de un explorador o cualquier cliente: acceda al servidor backend directamente (no a través de Application Gateway) y haga clic en el candado del certificado en la barra de direcciones para ver los detalles del certificado. Lo encontrará en la sección "Emitido para". Captura de pantalla que muestra los detalles del certificado en un explorador.

  • Iniciando sesión en el servidor backend (Windows):

    1. Inicie sesión en la máquina donde se hospeda la aplicación.
    2. Seleccione Win+R o haga clic con el botón derecho en el botón Inicio y seleccione Ejecutar.
    3. Escriba certlm.msc y seleccione Entrar. También puede buscar Administrador de certificados en el menú Inicio.
    4. Busque el certificado (normalmente en Certificados- Equipo local\Personal\Certificados) y abra el certificado.
    5. En la pestaña Detalles, compruebe el asunto del certificado.

  • Al iniciar sesión en el servidor backend (Linux): ejecute este comando OpenSSL especificando el nombre de archivo de certificado correcto openssl x509 -in certificate.crt -subject -noout

El certificado de backend ha caducado

Mensaje: certificado backend no es válido. La fecha actual está dentro del intervalo de fechas "Válido desde" y "Válido hasta" en el certificado.

Causa: Un certificado expirado se considera no seguro y, por tanto, la puerta de enlace de aplicaciones marca el servidor back-end con un certificado expirado como incorrecto.

Solución: la solución depende de la parte de la cadena de certificados que ha expirado en el servidor backend.

Para la SKU V2,

  • Certificado hoja expirada (también conocido como dominio o servidor): renueve el certificado de servidor con el proveedor de certificados e instale el nuevo certificado en el servidor backend. Asegúrese de instalar la cadena de certificados completa que consta de Leaf (topmost) > Intermediate(s) > Root. En función del tipo de entidad de certificación (CA), puede realizar las siguientes acciones en la puerta de enlace.

    • CA conocida públicamente: si el emisor de certificados es una entidad de certificación conocida, no necesita realizar ninguna acción en la puerta de enlace de aplicaciones.
    • CA privada: si el certificado hoja es emitido por una CA privada, debe verificar si el certificado de CA raíz de firma ha cambiado. En tales casos, debe cargar el nuevo certificado de entidad de certificación raíz (.CER) a la configuración de backend asociada de la puerta de enlace.

  • Certificado intermedio o raíz caducado: normalmente, estos certificados tienen períodos de validez relativamente prolongados (una o dos décadas). Cuando caduque el certificado raíz/intermedio, le recomendamos que consulte con su proveedor de certificados los archivos de certificado renovados. Asegúrese de que ha instalado esta cadena de certificados actualizada y completa que consta de Leaf (topmost) > Intermediate(s) > Root en el servidor backend.

    • Si el certificado raíz permanece sin cambios o si el emisor es una CA conocida, NO necesita realizar ninguna acción en la puerta de enlace de la aplicación.
    • Al usar una ENTIDAD de certificación privada, si el propio certificado de entidad de certificación raíz o la raíz del certificado intermedio renovado ha cambiado, debe cargar el nuevo certificado raíz en la configuración de backend de la puerta de enlace de aplicaciones.

Para la SKU V1,

  • Renueve el certificado hoja vencido (también conocido como dominio o servidor) con su CA y cargue el mismo certificado hoja (.CER) en la configuración de backend asociada de su puerta de enlace de aplicaciones.

No se ha encontrado el certificado intermedio

Mensaje: En el certificado intermedio falta en la cadena de certificados presentada por el servidor backend. Asegúrese de que la cadena de certificados está completa y ordenada correctamente en el servidor backend.

Causa: los certificados intermedios no están instalados en la cadena de certificados del servidor backend.

Solución: se usa un certificado intermedio para firmar el certificado Hoja y, por tanto, es necesario para completar la cadena. Compruebe con la entidad de certificación (CA) los certificados intermedios necesarios e instálelos en el servidor backend. La cadena debe comenzar con el certificado de hoja, luego el (los) certificado(s) intermedio(s) y, por último, el certificado de CA raíz. Se recomienda instalar la cadena completa en el servidor back-end, incluyendo el certificado de CA raíz. Como referencia, examine el ejemplo de cadena de certificados en Hoja debe ser el más alto de la cadena.

Nota:

Un certificado autofirmado que NO es una entidad de certificación también producirá el mismo error. Esto se debe a que Application Gateway considera dicho certificado autofirmado como un certificado "Hoja" y busca su certificado intermedio de firma. Puede seguir este artículo para generar correctamente un certificado autofirmado.

Estas imágenes muestran la diferencia entre los certificados autofirmados. Captura de pantalla que muestra la diferencia entre los certificados autofirmados.

No se encontró el certificado hoja o servidor

Mensaje: En el certificado Hoja falta en la cadena de certificados presentada por el servidor backend. Asegúrese de que la cadena está completa y ordenada correctamente en el servidor backend.

Causa: Falta el certificado de hoja (también conocido como dominio o servidor) de la cadena de certificados en el servidor back-end.

Solución: puede obtener el certificado de hoja de la entidad de certificación (CA). Instale este certificado de hoja y todos sus certificados de firma (certificados de CA intermedias y raíz) en el servidor back-end. La cadena debe comenzar con el certificado de hoja, luego el (los) certificado(s) intermedio(s) y, por último, el certificado de CA raíz. Se recomienda instalar la cadena completa en el servidor back-end, incluyendo el certificado de CA raíz. Como referencia, examine el ejemplo de cadena de certificados en Hoja debe ser el más alto de la cadena.

Un certificado de servidor no lo emite una entidad de certificación conocida públicamente

Mensaje: el certificado del servidor backend no está firmado por una entidad de certificación (CA) conocida. Para utilizar certificados de CA desconocidos, su certificado raíz debe cargarse en la configuración de backend de la puerta de enlace de aplicaciones.

Causa: ha seleccionado "certificado de CA conocido" en la configuración del backend, pero el certificado raíz presentado por el servidor backend no es conocido públicamente.

Solución: cuando una autoridad de certificación (CA) privada emite un certificado Hoja, el certificado de la CA raíz firmante debe cargarse en la configuración backend asociada de la puerta de enlace de aplicaciones. Esto permite a su puerta de enlace de aplicación establecer una conexión de confianza con ese servidor backend. Para solucionarlo, vaya a la configuración de backend asociada, elija "no es una CA conocida" y cargue el certificado de la CA raíz (.CER). Para identificar y descargar el certificado raíz, puede seguir los mismos pasos que se describen en Configuración incorrecta del certificado raíz de confianza.

El certificado intermedio NO está firmado por una CA públicamente conocida.

Mensaje: el certificado intermedio no está firmado por una entidad de certificación (CA) conocida. Asegúrese de que la cadena de certificados está completa y ordenada correctamente en el servidor backend.

Causa: ha seleccionado "certificado de CA conocido" en la configuración del backend, pero el certificado intermedio presentado por el servidor backend no está firmado por ninguna CA conocida públicamente.

Solución: Cuando una autoridad de certificación (CA) privada emite un certificado, el certificado de la CA raíz firmante debe cargarse en la configuración backend asociada de la puerta de enlace de aplicaciones. Esto permite a su puerta de enlace de aplicación establecer una conexión de confianza con ese servidor backend. Para solucionar esto, póngase en contacto con la entidad de certificación privada para obtener el certificado de CA raíz adecuado (.CER) y cargue ese archivo CER en la configuración back-end de la puerta de enlace de aplicación seleccionando "CA no conocida públicamente". Se recomienda también instalar la cadena completa en el servidor back-end, incluyendo el certificado de CA raíz, para facilitar la comprobación.

Error de coincidencia de certificados raíz de confianza (sin certificado raíz en el servidor backend)

Mensaje: el certificado intermedio no firmado por ningún certificado raíz cargado en la puerta de enlace de aplicaciones. Asegúrese de que la cadena de certificados está completa y ordenada correctamente en el servidor backend.

Causa: Ninguno de los certificados de CA raíz cargados en la configuración de back-end asociada ha firmado el certificado intermedio instalado en el servidor back-end. El servidor back-end solo tiene instalados certificados de hoja e intermedios.

Solución: un certificado de hoja está firmado por un certificado intermedio, que está firmado por un certificado de CA raíz. Al usar un certificado de entidad de certificación privada (CA), debe cargar el certificado de CA raíz correspondiente en la puerta de enlace de aplicación. Póngase en contacto con la entidad de certificación privada para obtener el certificado de CA raíz adecuado (. ER) y cargue ese archivo CER en la configuración back-end de la puerta de enlace de aplicación.

Error de coincidencia de certificados raíz de confianza (el certificado raíz está disponible en el servidor backend)

Mensaje: The root certificate of the server certificate used by the backend does not match the trusted root certificate added to the application gateway. Asegúrese de agregar el certificado raíz correcto para incluir en la lista de elementos permitidos en el back-end.

Causa: Este error se produce cuando ninguno de los certificados raíz cargados en la configuración de back-end de la puerta de enlace de aplicaciones coincide con el certificado raíz presente en el servidor back-end.

Solución: esto se aplica a un certificado de servidor backend emitido por una entidad de certificación privada (CA) o es uno autofirmado. Identifique y cargue el certificado de CA raíz correcto en la configuración de back-end asociada.

Sugerencias: para identificar y descargar el certificado raíz, puede usar cualquiera de estos métodos.

  • Uso de un explorador: acceda directamente al servidor backend (no a través de Application Gateway) y haga clic en el candado del certificado en la barra de direcciones para ver los detalles del certificado.

    1. Elija el certificado raíz de la cadena y haga clic en Exportar. De forma predeterminada, se trata de un archivo .CRT.
    2. Abra ese archivo .CRT.
    3. Vaya a la pestaña Detalles y haga clic en "Copiar en archivo",
    4. En la página Asistente para exportación de certificados, haga clic en Siguiente,
    5. Seleccione “X.509 codificado en Base 64 (. CER) y haga clic en Siguiente,
    6. Asigne un nuevo nombre de archivo y haga clic en Siguiente,
    7. Haga clic en Finalizar para obtener un archivo .CER.
    8. Cargue este certificado raíz (.CER) de la entidad de certificación privada en la configuración de backend de Application Gateway.

  • Iniciando sesión en el servidor backend (Windows)

    1. Inicie sesión en la máquina donde se hospeda la aplicación.
    2. Seleccione Win+R o haga clic con el botón derecho en el botón Inicio y seleccione Ejecutar.
    3. Escriba certlm.msc y seleccione Entrar. También puede buscar Administrador de certificados en el menú Inicio.
    4. Localice el certificado, normalmente en Certificados - Equipo local\Personal\Certificados, y ábralo.
    5. Seleccione el certificado raíz y, luego, Ver certificado.
    6. En las propiedades del certificado, seleccione la pestaña Detalles y haga clic en “Copiar en archivo”,
    7. En la página Asistente para exportación de certificados, haga clic en Siguiente,
    8. Seleccione “X.509 codificado en Base 64 (. CER) y haga clic en Siguiente,
    9. Asigne un nuevo nombre de archivo y haga clic en Siguiente,
    10. Haga clic en Finalizar para obtener un archivo .CER.
    11. Cargue este certificado raíz (.CER) de la entidad de certificación privada en la configuración de backend de Application Gateway.

La hoja debe estar más arriba en la cadena.

Mensaje: el certificado de hoja no es el certificado más alto de la cadena presentado por el servidor backend. Asegúrese de que la cadena de certificados está ordenada correctamente en el servidor backend.

Causa: el certificado de hoja (también conocido como dominio o servidor) no está instalado en el orden correcto en el servidor back-end.

Solución: la instalación de certificados en el servidor back-end debe incluir una lista ordenada de certificados que componen el certificado de hoja y todos sus certificados de firma (certificados de CA intermedios y raíz). La cadena debe comenzar con el certificado de hoja, luego el (los) certificado(s) intermedio(s) y, por último, el certificado de CA raíz. Se recomienda instalar la cadena completa en el servidor back-end, incluyendo el certificado de CA raíz.

Se muestra un ejemplo de instalación de un certificado de servidor junto con sus certificados de CA raíz e intermedio, indicados como profundidades (0, 1, 2, etc.) en OpenSSL. Puede comprobar lo mismo para el certificado del servidor backend mediante los siguientes comandos de OpenSSL.
s_client -connect <FQDN>:443 -showcerts
o
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Captura de pantalla que muestra una cadena típica de certificados.

Error en la verificación del certificado

Mensaje: no se pudo comprobar la validez del certificado de backend. Para averiguar el motivo, compruebe el diagnóstico de OpenSSL para el mensaje asociado al código de error {errorCode}.

Causa: este error se produce cuando Application Gateway no puede comprobar la validez del certificado.

Solución: para resolver este problema, compruebe que el certificado del servidor se creó correctamente. Por ejemplo, puede usar OpenSSL para comprobar el certificado y sus propiedades e intentar volver a cargarlo en la configuración HTTP de Application Gateway.

Estado de mantenimiento del backend: desconocido

Actualizaciones de las entradas DNS del grupo de back-end

Mensaje: no se pudo recuperar el estado de mantenimiento del back-end. Esto sucede cuando un NSG, UDR o Firewall en la subred de puerta de enlace de aplicación bloquea el tráfico en los puertos 65503-65534 en el caso de la SKU v1 y los puertos 65200-65535 en el caso de la SKU v2 o si el nombre de dominio completo (FQDN) configurado en el grupo de back-end no se pudo resolver en una dirección IP. Para obtener más información, visite https://aka.ms/UnknownBackendHealth.

Causa: para destinos backend basados en FQDN (nombre de dominio completo), Application Gateway almacena en caché y usa la última dirección IP correcta conocida si no obtiene una respuesta para la búsqueda DNS posterior. Una operación PUT en una puerta de enlace en este estado borraría por completo su caché DNS. Como resultado, no habrá ninguna dirección de destino a la que pueda llegar la puerta de enlace.

Resolución: compruebe y corrija los servidores DNS para asegurarse de que atiende una respuesta para la búsqueda DNS del FDQN especificado. También debe comprobar si los servidores DNS son accesibles a través de Virtual Network de Application Gateway.

Otros motivos

Si el estado del backend se muestra como Desconocido, la vista del portal se parecerá a la siguiente captura de pantalla:

Estado del back-end de Application Gateway: desconocido

Este comportamiento puede producirse por uno o varios de los siguientes motivos:

  1. El grupo de seguridad de red de la subred de Application Gateway está bloqueando el acceso de entrada a los puertos 65503-65534 (SKU v1) o 65200-65535 (SKU v2) desde "Internet".
  2. El UDR en la subred de Application Gateway está establecido en la ruta predeterminada (0.0.0.0/0), y el próximo salto no se especifica como Internet.
  3. La ruta predeterminada se anuncia mediante una conexión de ExpressRoute o VPN a una red virtual a través de BGP.
  4. El servidor DNS personalizado está configurado en una red virtual que no puede resolver nombres de dominio públicos.
  5. Application Gateway está en un estado incorrecto.

Solución:

  1. compruebe si el grupo de seguridad de red está bloqueando el acceso a los puertos 65503-65534 (SKU v1) o 65200-65535 (SKU v2) desde Internet:

    a. En la pestaña Overview (Información general) de Application Gateway, seleccione el vínculo Virtual Network/Subnet (Red virtual/subred). b. En la pestaña Subnets de la red virtual, seleccione la subred en la que se ha implementado Application Gateway. c. Compruebe si hay un grupo de seguridad de red configurado. d. Si se ha configurado un grupo de seguridad de red, busque ese recurso de grupo de seguridad de red en la pestaña Search (Buscar) o en All resources (Todos los recursos). e. En la sección Inbound Rules (Reglas de entrada), agregue una regla de entrada para permitir el intervalo de puertos de destino 65503-65534 para la SKU v1 o 65200-65535 para SKU v2 con Origen como la etiqueta de servicio GatewayManager. f. Seleccione Save (Guardar) y compruebe que puede ver el back-end como correcto. Como alternativa, puede hacerlo en PowerShell o la CLI.

  2. Compruebe si el UDR tiene una ruta predeterminada (0.0.0.0/0) donde el próximo salto no esté establecido como Internet:

    a. Siga los pasos 1a y 1b para determinar la subred. b. Compruebe si hay una UDR configurada. Si lo hay, busque el recurso en la barra de búsqueda o en All resources (Todos los recursos). c. Compruebe si hay rutas predeterminadas (0.0.0.0.0/0) con el próximo salto no establecido como Internet. Si el valor es Virtual Appliance (Aplicación virtual) o Virtual Network Gateway (Puerta de enlace de red virtual), debe asegurarse de que la aplicación virtual o el dispositivo local puedan enrutar correctamente el paquete de vuelta al destino de Internet sin modificarlo. Si los sondeos se enrutan a través de una aplicación virtual y se modifican, el recurso backend muestra un código de estado 200 y el estado de mantenimiento de Application Gateway puede mostrarse como Desconocido. Esto no indica un error. El tráfico debe seguir enrutando a través de Application Gateway sin problema. d. En caso contrario, cambie el próximo salto a Internet, seleccione Guardar y compruebe el mantenimiento del back-end.

  3. La ruta predeterminada anunciada por la conexión ExpressRoute o VPN a la red virtual a través de BGP (Protocolo de puerta de enlace de borde):

    a. Si tiene una conexión ExpressRoute o VPN a la red virtual a través de BGP y está anunciando una ruta predeterminada, debe asegurarse de que el paquete se redirige de vuelta al destino de Internet sin modificarlo. Para comprobarlo, use la opción Connection Troubleshoot (Solución de problemas de conexión) en el portal de Application Gateway. b. Elija el destino manualmente, que será cualquier dirección IP enrutable a Internet como 1.1.1.1. Establezca el puerto de destino en cualquier cosa y compruebe la conectividad. c. Si el próximo salto es una puerta de enlace de red virtual, es posible que haya una ruta predeterminada anunciada a través de ExpressRoute o VPN.

  4. Si hay un servidor DNS personalizado configurado en la red virtual, compruebe que los servidores pueden resolver los dominios públicos. La resolución de nombres de dominios públicos podría ser necesaria en escenarios en los que Application Gateway deba ponerse en contacto con dominios externos como los servidores OCSP (protocolo de estado de certificado en línea) o para comprobar el estado de revocación del certificado.

  5. Para comprobar que Application Gateway está en un estado correcto y en ejecución, vaya a la opción Resource Health (Estado de los recursos) en el portal y compruebe si es Healthy (Correcto). Si ve el estado Unhealthy (Incorrecto) o Degraded (Degradado), póngase en contacto con el soporte técnico.

  6. Si el tráfico privado y de Internet van a través de una instancia de Azure Firewall hospedada en un centro virtual protegido (mediante el Centro de Azure Virtual WAN):

    a. Para asegurarse de que la puerta de enlace de aplicación puede enviar tráfico directamente a Internet, configure la siguiente ruta definida por el usuario:

    Prefijo de dirección: 0.0.0.0/0
    Próximo salto: Internet

    b. Para asegurarse de que la puerta de enlace de aplicación puede enviar tráfico al grupo de back-end a través de una instancia de Azure Firewall en el centro de Virtual WAN, configure la siguiente ruta definida por el usuario.

    Prefijo de dirección: subred del grupo de back-end
    Próximo salto: dirección IP privada de Azure Firewall

Nota:

Si la puerta de enlace de aplicaciones no puede acceder a los puntos de conexión de CRL, podría marcar el estado de mantenimiento del backend como "desconocido". Para evitar estos problemas, compruebe que la subred de la puerta de enlace de aplicación puede acceder a crl.microsoft.com y a crl3.digicert.com. Esto se puede lograr configurando los grupos de seguridad de red para que envíen tráfico a los puntos de conexión de CRL.

Pasos siguientes

Más información sobre el registro y el diagnóstico de Application Gateway.