Compartir a través de

Configuración del back-end de Application Gateway

La configuración de back-end le permite administrar las configuraciones de las conexiones de back-end establecidas desde un recurso de puerta de enlace de aplicaciones a un servidor del grupo de back-end. Una configuración de ajustes del backend se puede asociar a una o varias reglas de enrutamiento.

Tipos de configuración de back-end en Application Gateway

Aunque los usuarios del portal solo verán la opción "Configuración de back-end", los usuarios de api tendrán acceso a dos tipos de configuración. Debe utilizar la configuración correcta, según el protocolo.

  • Configuración http de back-end: es para las configuraciones de proxy de nivel 7 que admiten protocolos HTTP y HTTPS.
  • Configuración de back-end: es para configuraciones de proxy de nivel 4 (versión preliminar) que admiten protocolos TLS y TCP.

Azure Application Gateway usa cookies administradas por la puerta de enlace para mantener las sesiones de usuario. Cuando un usuario envía la primera solicitud a Application Gateway, establece una cookie de afinidad en la respuesta con un valor hash que contiene los detalles de la sesión. Este proceso permite que las solicitudes posteriores que llevan la cookie de afinidad se enruten al mismo servidor back-end, lo que mantiene la permanencia.

Esta característica es útil cuando se desea mantener una sesión de usuario en el mismo servidor y cuando el estado de la sesión se guarda localmente en el servidor para una sesión de usuario. Si la aplicación no puede administrar la afinidad basada en cookies, no podrá usar esta característica. Para poder utilizarla, asegúrese de que los clientes admiten cookies.

Nota:

Algunos exámenes de vulnerabilidades podrían marcar la cookie de afinidad de Applicaton Gateway alegando que las marcas Secure o HttpOnly no están establecidas. Estos exámenes no tienen en cuenta que los datos de la cookie se generan mediante un hash unidireccional. La cookie no contiene ninguna información de usuario y se usa exclusivamente para el enrutamiento.

El explorador Chromiumactualización v80 trajo una orden en el que las cookies HTTP sin atributo SameSite deben tratarse como SameSite=Lax. En el caso de las solicitudes CORS (uso compartido de recursos de varios orígenes), si la cookie tiene que enviarse en un contexto de terceros, tiene que usar los atributos SameSite=None; Secure y solo se debe enviar mediante HTTPS. De lo contrario, en un escenario en que solo se utilice HTTP, el explorador no enviará las cookies en el contexto de terceros. El objetivo de esta actualización de Chrome es mejorar la seguridad y evitar los ataques de falsificación de solicitudes entre sitios (CSRF).

Para admitir este cambio, a partir del 17 de febrero de 2020, Application Gateway (y todos los tipos de SKU) insertarán otra cookie llamada ApplicationGatewayAffinityCORS además de la cookie ApplicationGatewayAffinity existente. La cookie ApplicationGatewayAffinityCORS incorpora dos atributos más ("SameSite=None; Secure") para que las sesiones persistentes se mantengan incluso en las solicitudes entre orígenes.

El nombre de cookie de afinidad predeterminado es ApplicationGatewayAffinity y puede cambiarlo. Si en la topología de red, implementa varias puertas de enlace de aplicaciones en línea, debe establecer nombres de cookies únicos para cada recurso. Si usa un nombre de cookie de afinidad personalizado, se agrega una cookie adicional con CORS como sufijo. Por ejemplo: CustomCookieNameCORS.

Nota:

Si se establece el atributo SameSite=None , es obligatorio que la cookie también contenga la marca Secure y se debe enviar a través de HTTPS. Si es necesario que la afinidad de la sesión se establezca mediante CORS, deberá migrar la carga de trabajo a HTTPS. Consulte la documentación sobre descarga de TLS y TLS de extremo a extremo para Application Gateway. Consulte la introducción a SSL, Configuración de una puerta de enlace de aplicaciones con terminación TLS y Configuración de TLS de un extremo a otro.

Purga de la conexión

El drenaje de conexiones ayuda a la correcta eliminación de miembros del grupo back-end durante las actualizaciones de servicio planeadas. Se aplica a instancias de back-end que se eliminan explícitamente del grupo back-end.

Puede aplicar esta configuración a todos los miembros del grupo de back-end habilitando la purga de conexiones en la configuración de back-end. Garantiza que todas las instancias de registro de un grupo de back-end no reciban nuevas solicitudes o conexiones al tiempo de mantenimiento de las conexiones existentes hasta el valor de tiempo de espera configurado. Este proceso también es cierto para las conexiones de WebSocket.

Tipo de configuración Importancia
Valor predeterminado cuando la purga de conexiones no está habilitada en la configuración de back-end 30 segundos
Valor definido por el usuario cuando la purga de conexiones está habilitada en la configuración de back-end De 1 a 3600 segundos

La única excepción a este proceso son las solicitudes enlazadas para anular el registro de instancias debido a la afinidad de sesión administrada por la puerta de enlace. Estas solicitudes se siguen reenviando a las instancias de registro.

Nota:

Hay una limitación en la que una actualización de configuración finalizará las conexiones en curso después de que se agote el tiempo de espera del drenaje de conexiones. Para solucionar esta limitación, debe aumentar el tiempo de espera del drenaje de conexiones en la configuración del back-end a un valor superior al tiempo máximo de descarga del cliente esperado.

Protocolo

Application Gateway admite HTTP y HTTPS en las solicitudes de enrutamiento a los servidores back-end. Si elige HTTP, el tráfico a los servidores back-end no estará cifrado. Si la comunicación sin cifrar no es aceptable, seleccione HTTPS.

Esta configuración combinada con HTTPS en el cliente de escucha admite TLS de un extremo a otro. Esto le permite transmitir de forma segura información confidencial cifrada al back-end. Cada servidor back-end del grupo con TLS de un extremo a otro habilitado debe configurarse con un certificado para permitir la comunicación segura.

Puerto

Este valor especifica el puerto en el que escuchan los servidores back-end el tráfico de la puerta de enlace de aplicación. Puede configurar los puertos comprendidos entre 1 y 65535.

Certificado raíz de confianza

Al seleccionar el protocolo HTTPS en la configuración de back-end, el recurso de puerta de enlace de aplicaciones utiliza su almacén de certificados de ca raíz de confianza predeterminado para comprobar la cadena y la autenticidad del certificado proporcionado por el servidor back-end.

De forma predeterminada, el recurso de Application Gateway incluye certificados CA populares, lo que permite conexiones TLS de back-end de manera fluida cuando una CA pública emite el certificado del servidor back-end. Sin embargo, si piensa usar una CA privada o un certificado autogenerado, debe proporcionar el certificado de CA raíz (.cer) correspondiente en esta configuración del backend.

Tiempo de espera de solicitud

Este valor es el número de segundos que la puerta de enlace de aplicación espera para recibir una respuesta del servidor back-end. El valor predeterminado es de 20 segundos. Sin embargo, es posible que desee ajustar esta configuración a las necesidades de la aplicación.

Reemplazo de la ruta de acceso del servidor back-end

Este valor le permite configurar una ruta de reenvío personalizada opcional que se usará cuando la solicitud se reenvíe al servidor back-end. Cualquier parte de la ruta de acceso entrante que coincida con la ruta de acceso personalizada del campo ruta de acceso de back-end de sustitución se copiará en la ruta de acceso reenviada. En la tabla siguiente se muestra cómo funciona esta característica:

  • Cuando la configuración de HTTP se asocia a una regla básica de enrutamiento de solicitudes:

    Solicitud original Reemplazo de la ruta de acceso del servidor back-end Solicitud que se reenvía al back-end
    /hogar/ /invalidar/ /override/home/
    /home/secondhome/ /invalidar/ /override/home/secondhome/

  • Cuando la configuración de HTTP se asocia a una regla de enrutamiento de solicitudes basada en una ruta de acceso:

    Solicitud original Regla de la ruta de acceso Reemplazo de la ruta de acceso del servidor back-end Solicitud que se reenvía al back-end
    /pathrule/inicio/ /pathrule* /invalidar/ /override/home/
    /pathrule/home/secondhome/ /pathrule* /invalidar/ /override/home/secondhome/
    /hogar/ /pathrule* /invalidar/ /override/home/
    /home/secondhome/ /pathrule* /invalidar/ /override/home/secondhome/
    /pathrule/inicio/ /pathrule/home* /invalidar/ /invalidar/
    /pathrule/home/secondhome/ /pathrule/home* /invalidar/ /override/secondhome/
    /pathrule/ /pathrule/ /invalidar/ /invalidar/

Usar sondeo personalizado

Esta opción asocia un sondeo personalizado con una configuración de HTTP. Solo puede asociar un sondeo personalizado con una configuración de HTTP. Si no asocia explícitamente un sondeo personalizado, se empleará el sondeo predeterminado para supervisar el estado del back-end. Es recomendable crear un sondeo personalizado para un mayor control sobre la supervisión del estado de los servidores back-end.

Nota:

El sondeo personalizado no supervisa el estado del grupo back-end a menos que la configuración HTTP correspondiente esté explícitamente asociada a un cliente de escucha.

Configuración del nombre de host

Application Gateway permite que la conexión establecida con el back-end use un nombre de host diferente al utilizado por el cliente para conectarse a Application Gateway. Aunque esta configuración puede ser útil en algunos casos, tenga cuidado cuando invalide el nombre de host de forma que sea diferente entre la puerta de enlace de aplicación y el cliente en comparación con el destino de back-end.

En entornos de producción, es un procedimiento recomendado utilizar el mismo nombre de host para la conexión del cliente a la puerta de enlace de aplicación y para la conexión de la puerta de enlace de aplicación al destino de back-end. Esta práctica evita posibles problemas con direcciones URL absolutas, direcciones URL de redirección y cookies enlazadas al host.

Antes de configurar el Application Gateway que se desvía de esto, revise las implicaciones de dicha configuración, como se describe con más detalle en el Centro de arquitectura: Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web backend.

Hay dos aspectos de una configuración HTTP que influyen en el Hostencabezado HTTP que usa Application Gateway conectarse al back-end:

  • "Seleccionar el nombre de host de la dirección de back-end"
  • "Sustitución del nombre de host"

Selección del nombre de host de la dirección de back-end

Esta funcionalidad establece dinámicamente el encabezado host de la solicitud en el nombre de host del grupo back-end. Usa una dirección IP o FQDN.

Esta característica resulta útil cuando el nombre de dominio del back-end es diferente del nombre DNS de la puerta de enlace de aplicaciones y el back-end se basa en un encabezado de host específico para resolver en el punto de conexión correcto.

Un ejemplo podría ser el uso de servicios multiinquilino como back-end. Un servicio de aplicaciones es un servicio multiinquilino que usa un espacio compartido con una sola dirección IP. Por lo tanto, solo se puede acceder a una instancia de App Service mediante los nombres de host que se establecen en la configuración del dominio personalizado.

De forma predeterminada, el nombre de dominio personalizado es example.azurewebsites.net. Para acceder a la instancia de App Service con una puerta de enlace de aplicación mediante un nombre de host que no está explícitamente registrado en dicha instancia o mediante el FQDN de la puerta de enlace de aplicación, puede reemplazar el nombre de host de la solicitud original por el nombre de host de la instancia de App Service. Para ello, habilite la opción Seleccionar nombre de host de la dirección de back-end.

Para un dominio personalizado cuyo nombre DNS personalizado existente está asignado al servicio de aplicaciones, la configuración recomendada no es habilitar la opción de elegir nombre de host desde la dirección de back-end.

Nota:

Esta configuración no es necesaria para App Service Environment, que es una implementación dedicada.

Sustitución del nombre de host

Esta funcionalidad reemplaza el encabezado host de la solicitud entrante en la puerta de enlace de aplicaciones por el nombre de host que especifique.

Por ejemplo, si www.contoso.com se especifica en la configuración Nombre de host , la solicitud original *https://appgw.eastus.cloudapp.azure.com/path1 se cambia a *https://www.contoso.com/path1 cuando la solicitud se reenvía al servidor back-end.

Pasos siguientes