Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 ven la opción "Configuración de back-end", los usuarios de API tienen 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.
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, 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 análisis de vulnerabilidades pueden señalar la cookie de afinidad de Application Gateway porque no se establecen las marcas Secure o HttpOnly. 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.
La actualización v80 del explorador Chromium establece un mandato por el que las cookies HTTP sin el atributo SameSite se tratan 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 otra cookie 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.
Drenaje de conexiones
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 anulación 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 de drenaje de conexión en la configuración de backend a un valor superior al tiempo máximo de descarga esperado por el cliente.
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
Cuando se selecciona el protocolo HTTPS en la configuración del backend, el recurso de la 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 backend.
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 Autoridad Certificadora privada o un certificado autogenerado con una validación TLS completa, debe proporcionar el certificado de CA raíz (.cer) correspondiente en la configuración del backend.
Configuración de validación HTTPS del back-end
Cuando se selecciona HTTPS en la configuración de back-end de Azure Application Gateway, la puerta de enlace realiza una validación completa del protocolo de enlace TLS al establecer una conexión segura con servidores de back-end. Estas validaciones incluyen lo siguiente:
- Comprobación de la cadena de certificados para asegurarse de que el certificado es de confianza.
- Comprobar el nombre del firmante del certificado con la indicación de nombre del servidor (SNI) enviada por Application Gateway.
- Comprobar la expiración del certificado para confirmar si el certificado sigue siendo válido.
La configuración de validación predeterminada garantiza la comunicación TLS segura entre la puerta de enlace y los servicios back-end. En determinados escenarios, puede ser necesario ajustar una o varias de estas opciones de validación. Para adaptarse a diversos requisitos de los clientes, Application Gateway ofrece las siguientes opciones configurables. Puede usar una o ambas opciones según sea necesario.
| Propiedades | Valores |
|---|---|
| validateCertChainAndExpiry | Tipo: booleano (true o false). La configuración predeterminada es true. Esto comprueba u omite tanto la cadena de certificados como las verificaciones de vencimiento. |
| validateSNI | Tipo: booleano (true o false). La configuración predeterminada es true. Comprueba si el nombre común del certificado proporcionado por el servidor back-end coincide con el valor indicación de nombre de servidor (SNI) enviado por Application Gateway. |
| sniName | Tipo: String. Esta propiedad solo es necesaria cuando validateSNI se establece como true. Puede especificar un valor SNI para que coincida con el nombre común del certificado en el back-end. De forma predeterminada, la puerta de enlace de aplicaciones usa el encabezado de host de la solicitud entrante como SNI. |
Nota:
- Se recomienda mantener todas las validaciones habilitadas para entornos de producción. Solo se recomienda deshabilitar algunas o todas las validaciones con fines de prueba y desarrollo, como cuando se usan certificados autofirmados.
- Esta configuración no se aplica a la funcionalidad de sondeo de prueba al agregar un sondeo de estado personalizado. Como resultado, puede ver diferencias en los resultados al comparar con sondeos de estado periódicos.
- No se admite actualmente para el proxy de TLS.
- PowerShell y la CLI serán admitidos pronto.
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, puede ajustar esta configuración a las necesidades de la aplicación. Los valores aceptables son de 1 segundo a 86400 segundos (24 horas).
Reemplazar la ruta de acceso de 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 de back-end Solicitud que se reenvía al back-end /hogar/ /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 Reemplazar la ruta de acceso de back-end Solicitud que se reenvía al back-end /pathrule/inicio/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /hogar/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/inicio/ /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 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"
- "Reemplazo del nombre de host"
Seleccionar el 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.
Conexión de back-end dedicada
Azure Application Gateway, de forma predeterminada, reutiliza las conexiones back-end inactivas para optimizar el uso de recursos de las conexiones TCP tanto para Application Gateway como para el servidor back-end. Para admitir funciones de seguridad en rutas de acceso de datos de clientes que requieren conexiones de back-end únicas por cliente, Azure Application Gateway V2 proporciona conexiones dedicadas a los servidores back-end.
Esta funcionalidad establece una asignación directa de uno a uno entre las conexiones front-end y back-end, lo que garantiza la conectividad persistente para cada cliente individual.
Importante
Revise las consideraciones siguientes antes de habilitar la conexión de back-end dedicada en Application Gateway:
- Compatibilidad con NTLM/Kerberos: La autenticación de paso directo de NTLM y Kerberos requiere una asignación uno a uno entre las conexiones front-end y back-end para conservar la integridad de la sesión. Encienda la Conexión dedicada de back-end para admitir estos protocolos.
- Clientes heredados: los clientes heredados, como MSIE6 o las aplicaciones que usan firmas anteriores del agente de usuario, no pueden admitir completamente las características HTTP modernas y los comportamientos de administración de conexiones. Para mejorar la confiabilidad y ayudar a evitar problemas como respuestas incompletas o dañadas, Azure Application Gateway aplica un control de compatibilidad adicional de forma predeterminada. Cuando la característica Conexión de back-end dedicada está habilitada, este control de compatibilidad puede dar lugar a diferencias en el comportamiento de conexión de los clientes heredados con NTLM, lo que podría provocar incoherencias de conectividad. Para lograr una confiabilidad óptima y un comportamiento predecible, se recomienda usar clientes modernos compatibles con estándares o actualizar clientes heredados siempre que sea posible.
- Planificación de capacidad: La conexión dedicada al backend lleva a un aumento en el número de conexiones al backend y, por lo tanto, podría requerir más recursos para admitir el incremento de conexiones concurrentes en el Application Gateway y los servidores backend. En Application Gateway, aumente el recuento de instancias o habilite la escalabilidad automática para dar cabida a la carga.
- Consumo de puertos SNAT: cuando el back-end es un servidor remoto, cada conexión de cliente consume un puerto SNAT dedicado, lo que aumenta el riesgo de agotamiento de puertos SNAT. Para obtener instrucciones, consulte procedimientos recomendados de arquitectura.
- Compatibilidad con protocolos: la conexión de back-end dedicada no se admite con HTTP/2.
Resolución de errores 4xx con conexiones backend dedicadas
Cuando las conexiones de back-end dedicadas están habilitadas para una configuración de back-end y la aplicación back-end devuelve códigos de estado 4xx, use las instrucciones siguientes para diagnosticar y resolver el problema.
Verifique la configuración del Nombre Principal de Servicio (SPN): los mecanismos de autenticación, como NTLM y Kerberos, requieren Nombres Principales de Servicio registrados correctamente. Asegúrese de que los SPN están configurados y únicos correctamente en el directorio para permitir la autenticación correcta. Para más información, consulte la documentación de Kerberos.
Revise los registros del servidor back-end para ver los códigos de subestado: Application Gateway solo muestra el estado HTTP principal (por ejemplo, 401 No autorizado). Para identificar la causa subyacente, revise los registros del servidor back-end para obtener información de subestado más detallada. Para obtener instrucciones, consulte la configuración de autenticación de Windows.