Configuración HTTP de Application Gateway
La puerta de enlace de aplicación enruta el tráfico a los servidores backend mediante la configuración que especifique aquí. Después de crear una configuración de HTTP, debe asociarla con una o varias reglas de enrutamiento de solicitudes.
Afinidad basada en cookies
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, ésta establece una cookie de afinidad en la respuesta con un valor hash que contiene los detalles de la sesión, de modo que las solicitudes posteriores que lleven la cookie de afinidad se dirijan al mismo servidor backend para mantener 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 Chromium actualizació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.
Tenga en cuenta que el nombre predeterminado de la cookie de afinidad es ApplicationGatewayAffinity, aunque 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 contenga también la marca Secure y se envíe mediante 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 la descarga de TLS y TLS de un extremo a otro para Application Gateway aquí: Introducción, Tutorial: Configuración de una puerta de enlace de aplicaciones con terminación SSL mediante de Azure Portal, Configuración de SSL de un extremo a otro con Application Gateway mediante el portal.
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 las instancias de back-end que son
- se ha quitado explícitamente del grupo de back-end o
- notificado como incorrecto por los sondeos de estado.
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. Esto también es cierto para las conexiones de WebSocket.
| Tipo de configuración | Value |
|---|---|
| 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 esto 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.
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.
Port
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
Si selecciona HTTPS como protocolo back-end, Application Gateway requiere un certificado raíz de confianza para confiar en el grupo back-end para SSL de un extremo a otro. De forma predeterminada, la opción Usar certificado de entidad de certificación conocida está establecida como No. Si planea usar un certificado autofirmado o un certificado firmado por una entidad de certificación interna, debe proporcionar a Application Gateway el certificado público coincidente usado por el grupo de backend. Este certificado se debe cargar directamente en el Application Gateway con formato .CER.
Si tiene previsto usar un certificado en el grupo back-end firmado por una entidad de certificación pública de confianza, puede establecer la opción Usar certificado de entidad de certificación reconocida en Sí y omitir la carga de un certificado público.
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.
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 Reemplazar la ruta de acceso del back-end Solicitud que se reenvía al back-end /home/ /override/ /override/home/ /home/secondhome/ /override/ /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 Reemplazar la ruta de acceso del back-end Solicitud que se reenvía al back-end /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
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 la aplicación y el cliente en comparación con el destino backend.
En producción, se recomienda mantener el nombre de host usado por el cliente en la puerta de enlace de aplicación como el mismo nombre de host que usa la puerta de enlace de aplicación en el destino de back-end. Esto evita posibles problemas con direcciones URL absolutas, URL de redireccionamiento y cookies enlazadas a host.
Antes de configurar Application Gateway que se desvía de esto, revise las implicaciones de dicha configuración, como se describe con más detalle en Centro de arquitectura: Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web back-end
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. Una instancia de App Service 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 es no habilitar la selección del nombre de host de la dirección de back-end.
Nota:
Esta opció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 se especifica www.contoso.com en el valor Nombre de host, la solicitud original *https://appgw.eastus.cloudapp.azure.com/path1 cambia a *https://www.contoso.com/path1 cuando la solicitud se reenvía al servidor back-end.