Planeamiento e implementación de una instancia de Azure Application Gateway

  • 10 minutos

Azure Application Gateway es un equilibrador de carga de tráfico web (OSI capa 7) que permite administrar el tráfico a las aplicaciones web. Los equilibradores de carga tradicionales operan en la capa de transporte (OSI capa 4: TCP y UDP) y enrutan el tráfico en función de la dirección IP y puerto de origen a una dirección IP y puerto de destino.

Application Gateway puede tomar decisiones de enrutamiento basadas en atributos adicionales de una solicitud HTTP, por ejemplo los encabezados de host o la ruta de acceso del URI. Por ejemplo, puede enrutar el tráfico en función de la dirección URL entrante. Por tanto, si /images se encuentra en la dirección URL entrante, puede redirigir el tráfico a un conjunto específico de servidores (conocido como un grupo) configurados para imágenes. Si /video está en la dirección URL, ese tráfico se enruta a otro grupo optimizado para vídeos.

Diagrama que muestra un ejemplo de una instancia de Azure Application Gateway.

Este tipo de enrutamiento se conoce como equilibrio de carga de capa de aplicación (OSI capa 7). Azure Application Gateway puede hacer enrutamiento basado en dirección URL y mucho más.

Componentes de Application Gateway

Una puerta de enlace de aplicaciones sirve como el único punto de contacto para los clientes. Se encarga de distribuir el tráfico entrante de las aplicaciones entre varios grupos de servidores back-end, como máquinas virtuales de Azure, conjuntos de escalado de máquinas virtuales, Azure App Service y servidores externos y locales.

Diagrama que muestra los componentes de la puerta de enlace de aplicación de Azure.

Infraestructura

La infraestructura de Application Gateway incluye la red virtual, las subredes, los grupos de seguridad de red y las rutas definidas por el usuario.

Frontend IP address (Dirección IP de front-end)

Puede configurar la puerta de enlace de aplicaciones para que tenga una dirección IP pública, una dirección IP privada o ambas. Se necesita una dirección IP pública si hospeda un back-end al que los clientes deben acceder desde Internet mediante una dirección IP virtual (VIP) accesible desde Internet.

No se necesita ninguna dirección IP pública para un punto de conexión interno que no está expuesto a internet. Una configuración de front-end privada es útil para las aplicaciones internas de línea de negocio que no están expuestas a Internet. También es útil para los servicios y niveles de una aplicación de varios niveles dentro de un límite de seguridad que no están expuestos a internet, pero requieren distribución de carga round robin, permanencia de sesión o terminación TLS.

Solo se admiten una dirección IP pública y una dirección IP privada. Puede elegir la dirección IP de front-end cuando cree la puerta de enlace de aplicaciones.

Nota:

El front-end de Application Gateway admite direcciones IP de doble pila (versión preliminar pública). Puede crear hasta cuatro direcciones IP de front-end. Dos son direcciones IPv4 (públicas y privadas) y dos son direcciones IPv6 (públicas y privadas).

  • Para una dirección IP pública, puede crear una nueva dirección IP pública o usar una ya existente en la misma ubicación que la puerta de enlace de aplicación. Para más información, consulte esta comparación entre direcciones IP públicas estáticas y dinámicas.
  • Para una dirección IP privada, puede especificar una dirección IP privada de la subred en la que se creó la puerta de enlace de aplicación. Para implementaciones de SKU v2 de Application Gateway, se debe definir una dirección IP estática al agregar una dirección IP privada a la puerta de enlace. Para implementaciones de SKU v1 de Application Gateway, si no especifica una dirección IP, se selecciona automáticamente una dirección IP disponible de la subred. El tipo de dirección IP que seleccione (estática o dinámica) no se podrá cambiar más adelante.

Una dirección IP de front-end está asociada a un cliente de escucha que comprueba las solicitudes entrantes en esta dirección IP.

Puede crear clientes de escucha privados y públicos con el mismo número de puerto. Sin embargo, tenga en cuenta cualquier grupo de seguridad de red (NSG) asociado a la subred de Application Gateway. En función de la configuración del grupo de seguridad de red, es posible que necesite una regla de entrada permitida con direcciones IP de destino como direcciones IP de front-end públicas y privadas de la puerta de enlace de aplicaciones. Cuando se usa el mismo puerto, la puerta de enlace de aplicaciones cambia el destino del flujo de entrada a las direcciones IP de front-end de la puerta de enlace.

Regla de entrada:

  • Origen: según sus necesidades.
  • Destino: direcciones IP de front-end públicas y privadas de la puerta de enlace de aplicaciones.
  • Puerto de destino: según los cliente de escucha configurados.
  • Protocolo: TCP

Regla de salida: Ningún requisito específico

Clientes de escucha

Un cliente de escucha es una entidad lógica que comprueba las solicitudes de conexión entrantes mediante el puerto, protocolo, host y dirección IP. Al configurar el cliente de escucha, debe especificar valores que coincidan con los valores correspondientes de la solicitud entrante de la puerta de enlace.

Cuando crea una puerta de enlace de aplicaciones mediante Azure Portal, también puede crear un cliente de escucha predeterminado eligiendo el protocolo y el puerto de este cliente. Puede elegir si habilita compatibilidad con HTTP2 en el cliente de escucha o no. Después de crear la puerta de enlace de aplicaciones, puede editar la configuración de ese cliente de escucha predeterminado (appGatewayHttpListener) o crear otros clientes nuevos.

Tipo de cliente de escucha

Un cliente de escucha es una entidad lógica que comprueba si hay solicitudes de conexión entrantes. Un cliente de escucha acepta una solicitud si el protocolo, el puerto, el nombre de host y la dirección IP asociados a la solicitud coinciden con los mismos elementos asociados a la configuración del cliente de escucha.

Antes de usar una puerta de enlace de aplicaciones, debe agregar al menos un cliente de escucha. Puede haber varios clientes de escucha asociados a una puerta de enlace de aplicaciones, y se pueden usar con el mismo protocolo.

Una vez que un cliente de escucha detecta las solicitudes entrantes de clientes, la puerta de enlace de aplicaciones enruta estas solicitudes a los miembros del grupo de servidores back-end configurado en esta regla.

Los clientes de escucha admiten los siguientes puertos y protocolos.

Puertos

Un puerto es donde un cliente de escucha realiza escuchas de la solicitud de cliente. Puede configurar puertos para las SKU v1 y v2 según se indica a continuación.

SKU Intervalo de puertos admitidos Excepción
V2 1 a 64999 22
V1 1 a 65502 3389

Protocolos

Application Gateway admite cuatro protocolos: HTTP, HTTPS, HTTP/2 y WebSocket:

Nota:

La compatibilidad con el protocolo HTTP/2 está disponible únicamente para los clientes que se conectan a los agentes de escucha de la puerta de aplicaciones. La comunicación con grupos de servidores back-end es a través de HTTP/1.1. De forma predeterminada, HTTP/2 está deshabilitado. Pero puede elegir habilitarlo.

  • Especifique entre los protocolos HTTP y HTTPS en la configuración del cliente de escucha.
  • La compatibilidad con los protocolos WebSockets y HTTP/2 se proporciona de forma nativa, y la compatibilidad con WebSocket está habilitada de forma predeterminada. No hay ninguna opción de configuración que permita al usuario habilitar o deshabilitar la compatibilidad con WebSocket. Use WebSockets con clientes de escucha HTTP y HTTPS.

Use un cliente de escucha HTTPS para la terminación TLS. Un cliente de escucha HTTPS descarga el trabajo de cifrado y descifrado en la puerta de enlace de aplicaciones, por lo que los servidores web no se ven afectados por la sobrecarga.

Reglas de enrutamiento de solicitudes

Si crea una puerta de enlace de aplicaciones mediante Azure Portal, creará una regla predeterminada (rule1). Esta regla enlaza el cliente de escucha predeterminado (appGatewayHttpListener) con el grupo de servidores back-end predeterminado (appGatewayBackendPool) y la configuración HTTP de back-end predeterminada (appGatewayBackendHttpSettings). Después de crear la puerta de enlace, puede modificar la configuración de la regla predeterminada o crear reglas.

Tipo de regla

Cuando se crea una regla, puede elegir entre básica y basada en ruta de acceso.

  • Elija la opción básica si quiere reenviar todas las solicitudes del cliente de escucha asociado (por ejemplo, blog.contoso.com/*) a un único grupo back-end.
  • Elija la opción basada en ruta de acceso si quiere enrutar las solicitudes desde determinadas rutas de acceso de dirección URL hasta grupos back-end específicos. El patrón basado en rutas de acceso se aplica solo a la ruta de acceso de la dirección URL, no a sus parámetros de consulta.

Cliente de escucha asociado

Asocie un cliente de escucha a la regla para que la regla de enrutamiento de solicitudes que está asociada con él se evalúe para determinar el grupo back-end al que enrutar la solicitud.

Grupo back-end asociado

Asocie la regla al grupo back-end que contiene los destinos de back-end que se encargan de las solicitudes que recibe el cliente de escucha.

  • En una regla básica, se permite un único grupo back-end. Todas las solicitudes del cliente de escucha asociado se reenviarán a ese grupo back-end.
  • En el caso de una regla basada en ruta de acceso, agregue varios grupos back-end que se correspondan con cada ruta de acceso de dirección URL. Aquellas solicitudes que coincidan con la ruta de acceso de dirección URL especificada se reenvían al grupo back-end correspondiente. Agregue también un grupo back-end predeterminado. Las solicitudes que no coincidan con ninguna ruta de acceso URL de la regla se reenviarán a ese grupo.

Configuración HTTP del back-end asociado

Agregue una configuración HTTP de back-end para cada regla. Las solicitudes se enrutan desde la puerta de enlace de aplicación hasta los destinos de back-end mediante el número de puerto, el protocolo y cualquier otra información que se especifique en esta configuración.

En una regla básica, solo se permite una configuración HTTP de back-end. Todas las solicitudes del cliente de escucha asociado se reenvían a los destinos de back-end correspondientes mediante esta configuración HTTP.

En el caso de una regla basada en ruta de acceso, agregue varias configuraciones HTTP de back-end que se correspondan con cada ruta de acceso de dirección URL. Las solicitudes que coincidan con la ruta de acceso de dirección URL de esta configuración se reenvían a los destinos de back-end correspondientes mediante la configuración HTTP que se corresponda con cada ruta de acceso de dirección URL. Agregue también una configuración de HTTP predeterminada. Las solicitudes que no coincidan con ninguna ruta de acceso de dirección URL de esta regla se reenvían al grupo back-end predeterminado mediante la configuración HTTP predeterminada.

Configuración de redireccionamiento

Si se configura el redireccionamiento para una regla básica, todas las solicitudes del cliente de escucha asociado se reenviarán al destino. Esto es un redireccionamiento global. Si se configura el redireccionamiento para una regla basada en ruta de acceso, solo se redirigirán aquellas solicitudes de una determinada área del sitio. Un ejemplo es un área de carro de la compra que se indica mediante /cart/. Esto es un redireccionamiento basado en ruta de acceso.

Agente de escucha

Elige el cliente de escucha como destino de redireccionamiento para redirigir el tráfico desde un cliente de escucha a otro en la puerta de enlace. Esta configuración es necesaria si se desea habilitar el redireccionamiento de HTTP a HTTPS. Redirige el tráfico desde el cliente de escucha de origen que comprueba las solicitudes HTTP entrantes al cliente de escucha de destino que comprueba las solicitudes HTTPS entrantes. También puede decidir incluir la cadena de consulta y la ruta de acceso de la solicitud original en la solicitud que se reenviará al destino de redireccionamiento.

Recorte de pantalla que muestra un ejemplo de una página de configuración de redireccionamiento.

Sitio externo

Elija un sitio externo cuando desee redirigir el tráfico del cliente de escucha asociado con esta regla a un sitio externo. Puede decidir incluir la cadena de consulta de la solicitud original en la solicitud que se reenviará al destino de redireccionamiento. No se puede reenviar la ruta de acceso al sitio externo que se encontraba en la solicitud original.

Reescritura de encabezados HTTP y URL

Mediante las reglas de reescritura, puede agregar, quitar o actualizar encabezados de solicitud y respuesta HTTP(S), así como parámetros de ruta de acceso URL y cadena de consulta, dado que los paquetes de solicitud y respuesta se mueven entre el cliente y los grupos back-end a través de la puerta de enlace de aplicaciones.

Los parámetros de URL y encabezado se pueden establecer en valores estáticos o en otros encabezados y variables de servidor. Como consecuencia, sirve de ayuda en casos de uso importantes, como la extracción de direcciones IP de cliente, la eliminación de información confidencial sobre el back-end, la adición de más seguridad, etc.

Configuración de HTTP

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.

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 de hash que contiene los detalles de la sesión, de modo que las solicitudes posteriores que lleven la cookie de afinidad se enrutarán al mismo servidor back-end para mantener la adherencia.

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.

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,
  • se quitan durante las operaciones de escalado 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 Valor
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 cancelar el registro de instancias debido a la afinidad de la sesión administrada por la puerta de enlace y que se seguirán reenviando a las instancias de cancelación del 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 que usará el grupo back-end. 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, la invalidación del nombre de host para que sea diferente entre el cliente y la puerta de enlace de aplicación y la puerta de enlace de aplicación en el destino de back-end debe realizarse con cuidado.

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 de otra forma, revise las implicaciones de ese tipo 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 de back-end.

Hay dos aspectos de una configuración HTTP que influyen en el encabezado HTTP de host que Application Gateway usa para 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 multiempresa como back-end. Un servicio de aplicaciones es un servicio multiempresa 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.

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/path1cambia a *https://www.contoso.com/path1 cuando la solicitud se reenvía al servidor de back-end.

Grupo de back-end

Puede apuntar un grupo de servidores back-end a cuatro tipos de miembros de back-end: una máquina virtual específica, un conjunto de escalado de máquinas virtuales, una dirección IP o FQDN, o una instancia de App Service.

Después de crear un grupo de servidores back-end, debe asociarlo con una o varias reglas de enrutamiento de solicitudes. También debe configurar sondeos de estado para cada grupo de servidores back-end de la puerta de enlace de aplicaciones. Cuando se cumple una condición de la regla de enrutamiento de solicitudes, la puerta de enlace de aplicaciones reenvía el tráfico a los servidores correctos (los que determinen los sondeos de estado) del grupo de back-end correspondiente.

Sondeos de estado

Azure Application Gateway supervisa el estado de todos los servidores del grupo de back-end y detiene automáticamente el envío de tráfico a cualquier servidor que considere incorrecto. Los sondeos siguen supervisando este tipo de servidor incorrecto y la puerta de enlace comienza a enrutar el tráfico a él una vez más en cuanto los sondeos lo detectan como correctos.

El sondeo predeterminado usa el número de puerto de la configuración de back-end asociada y otras configuraciones preestablecidas. Puede usar sondeos personalizados para configurarlos de la manera.

Comportamiento de sondeos

Dirección IP de origen

La dirección IP de origen de los sondeos depende del tipo de servidor back-end:

  • Si el servidor del grupo de back-end es un punto de conexión público, la dirección de origen será la dirección IP pública de front-end de la puerta de enlace de aplicaciones.
  • Si el grupo de back-end es un punto de conexión privado, la dirección de origen proviene del espacio de direcciones IP privadas de la subred de puerta de enlace de aplicación.

Operaciones de sondeo

Una puerta de enlace comienza a activar sondeos inmediatamente después de configurar una regla asociándola con un valor de back-end y un grupo de back-end (y el agente de escucha, por supuesto). En la ilustración se muestra que la puerta de enlace sondea de forma independiente todos los servidores del grupo de back-end. Las solicitudes entrantes que comienzan a llegar solo se envían a los servidores en buen estado. Un servidor back-end se marca como incorrecto de forma predeterminada hasta que se recibe una respuesta de sondeo correcta.

Diagrama que muestra un ejemplo de las operaciones de sondeo de puerta de enlace de aplicación de Azure.

Los sondeos necesarios se determinan en función de la combinación única del servidor back-end y la configuración de back-end. Por ejemplo, considere una puerta de enlace con un único grupo de back-end con dos servidores y dos configuraciones de back-end, cada una con números de puerto diferentes. Cuando estas configuraciones de back-end distintas están asociadas al mismo grupo de back-end mediante sus respectivas reglas, la puerta de enlace crea sondeos para cada servidor y la combinación de la configuración de back-end. Puede verlo en la página Estado de back-end.

Recorte de pantalla que muestra un ejemplo de la configuración del estado del back-end.

Además, todas las instancias de la puerta de enlace de aplicaciones sondea los servidores back-end independientemente entre sí.

Nota:

El informe de estado de back-end se actualiza en función del intervalo de actualización del sondeo correspondiente y no depende de la solicitud del usuario.

Sondeo de estado predeterminado

Una puerta de enlace de aplicaciones configura automáticamente un sondeo de estado predeterminado cuando no hay ningún sondeo personalizado configurado. El comportamiento de supervisión consiste en realizar una solicitud HTTP GET a las direcciones IP o a los nombres de dominio completo configurados en el grupo back-end. En el caso de los sondeos predeterminados si las opciones de HTTP del back-end se configuran para HTTPS, el sondeo usa HTTPS también para comprobar el mantenimiento de los servidores de back-end.

Por ejemplo, va a configurar la puerta de enlace de aplicación para usar los servidores back-end A, B y C para recibir el tráfico de red HTTP en el puerto 80. La supervisión de estado predeterminada comprueba los tres servidores cada 30 segundos para ver que la respuesta de HTTP es correcta con un tiempo de espera de 30 segundos para cada solicitud. Una respuesta HTTP correcta tiene un código de estado entre 200 y 399. En este caso, la solicitud HTTP GET para el sondeo de estado tendrá el aspecto http://127.0.0.1/. Consulte también Códigos de respuesta HTTP en Application Gateway.

Si se produce un error en la comprobación de sondeo predeterminado para el servidor A, Application Gateway deja de reenviar solicitudes a este servidor. El sondeo predeterminado sigue comprobando el servidor A cada 30 segundos. Cuando el servidor A responde correctamente a una solicitud de un sondeo de estado predeterminado, Application Gateway comienza a reenviar las solicitudes al servidor de nuevo.

Configuración de sondeo de estado predeterminado

Propiedad de sondeo Valor Descripción
Dirección URL de sondeo <protocolo>://127.0.0.1:<puerto>/ El protocolo y el puerto se heredan de la configuración de HTTP de back-end a la que está asociado el sondeo.
Intervalo 30 Cantidad de tiempo en segundos que se debe esperar antes de que se envíe el siguiente sondeo de estado.
Tiempo de espera 30 Cantidad de tiempo en segundos que la puerta de enlace de la aplicación espera una respuesta de sondeo antes de marcar dicho sondeo como incorrecto. Si un sondeo devuelve un estado correcto, el back-end correspondiente se marca inmediatamente como correcto.
Umbral incorrecto 3 Controla cuántos sondeos se van a enviar si se produce un error en el sondeo de estado normal. En la SKU v1, estos sondeos de estado adicionales se envían en sucesión rápida para determinar el estado del back-end rápidamente y no esperar al intervalo de sondeo. En el caso de la SKU v2, los sondeos de estado esperan el intervalo. El servidor backend se marca como inactivo después de que el número de errores de sondeo consecutivos alcanza el umbral de incorrecto.

El sondeo predeterminado solo examina <protocolo>://127.0.0.1:<puerto> para determinar el estado de mantenimiento. Si necesita configurar el sondeo de estado para ir a una dirección URL personalizada o modificar alguna otra configuración, debe usar sondeos personalizados.

Sondeo de estado personalizado

Los sondeos personalizados permiten un control más específico sobre la supervisión de estado. Cuando se usan sondeos personalizados, puede configurar un nombre de host personalizado, la ruta de acceso de dirección URL, el intervalo de sondeo y la cantidad de respuestas erróneas que se aceptan antes de marcar la instancia del grupo back-end como en mal estado, etc.

Configuración de sondeo de estado personalizado

La siguiente tabla proporciona definiciones de las propiedades de un sondeo de mantenimiento personalizado.

Propiedad de sondeo Descripción
Nombre Nombre del sondeo. Este nombre se usa para identificar y hacer referencia al sondeo en la configuración HTTP de back-end.
Protocolo Protocolo usado para enviar el sondeo. Esto tiene que coincidir con el protocolo definido en la configuración HTTP de back-end a la que está asociado
Host Nombre de host con el que enviar el sondeo. En la SKU v1, este valor solo se usa para el encabezado de host de la solicitud de sondeo. En la SKU v2, se usa para el encabezado de host y SNI.
Path Ruta de acceso relativa del sondeo. Las rutas de acceso válidas comienzan por '/'
Port Si se define, se usa como puerto de destino. De lo contrario, usa el mismo puerto que la configuración HTTP a la que está asociada. Esta propiedad solo está disponible en la SKU v2.
Intervalo Intervalo de sondeo en segundos. Este valor 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 mal estado.

Sondeo de búsqueda de coincidencia

De forma predeterminada, una respuesta HTTP (S) con el código de estado entre 200 y 399 se considera correcta. Los sondeos de estado personalizados admiten además dos criterios de coincidencia. Los criterios de coincidencia pueden usarse para modificar opcionalmente la interpretación predeterminada de lo que constituye una respuesta correcta.

Estos son los criterios de coincidencia:

  • Coincidencia de código de estado de respuesta HTTP: criterio de coincidencia de sondeo para aceptar el código de respuesta, o los intervalos de códigos de respuesta, HTTP especificados por el usuario. Se admiten códigos de estado de respuesta individuales, o un intervalo de códigos de estado de respuesta, separados por coma.
  • Coincidencia de cuerpo de respuesta HTTP: criterio de coincidencia de sondeo que examina el cuerpo de la respuesta HTTP y busca la coincidencia con una cadena especificada por el usuario. La coincidencia solo busca la existencia de la cadena especificada por el usuario en el cuerpo de la respuesta, no es una coincidencia de expresión regular completa. La coincidencia especificada debe tener 4090 caracteres o menos.

Los criterios de coincidencia se pueden especificar mediante el cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.

Por ejemplo:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399




$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Los criterios de coincidencia se pueden asociar a la configuración de sondeo mediante un operador de -Match en PowerShell.

Casos de uso de sondeo personalizados

  • Si un servidor back-end solo permite el acceso a usuarios autenticados, los sondeos de application Gateway recibirán un código de respuesta 403 en lugar de 200. A medida que los clientes (usuarios) están enlazados a autenticarse para el tráfico activo, puede configurar el tráfico de sondeo para que acepte 403 como respuesta esperada.
  • Cuando un servidor back-end tiene instalado un certificado comodín (*.contoso.com) para atender diferentes subdominios, puede usar un sondeo personalizado con un nombre de host específico (necesario para SNI) que se acepte para establecer un sondeo TLS correcto y notificar ese servidor como correcto. Con "invalidar el nombre de host" en el valor de back-end establecido en NO, los distintos nombres de host entrantes (subdominios) se pasarán tal como está al back-end.

Consideraciones sobre grupos de seguridad de red (NSG)

El control específico sobre la subred de Application Gateway a través de reglas de NSG es posible en versión preliminar pública. Se pueden encontrar más detalles aquí.

Con la funcionalidad actual hay algunas restricciones:

Debe permitir el tráfico entrante de Internet en los puertos TCP 65503-65534 para la SKU de Application Gateway v1, y los puertos TCP 65200-65535 para la SKU de V2 con la subred de destino como cualquiera y origen como la etiqueta de servicio de GatewayManager. Este intervalo de puertos es necesario para la comunicación de la infraestructura de Azure.

Además, no se puede bloquear la conectividad saliente de Internet y se debe permitir el tráfico entrante desde la etiqueta AzureLoadBalancer.

Funcionamiento de una instancia de Application Gateway

Diagrama que muestra un ejemplo de cómo funciona una puerta de enlace de aplicación de Azure.

Cómo una puerta de enlace de aplicaciones acepta una solicitud

  1. Antes de que un cliente envíe una solicitud a una puerta de enlace de aplicaciones, resuelve el nombre de dominio de la puerta de enlace de aplicaciones mediante un servidor del sistema de nombres de dominio (DNS). Azure controla la entrada de DNS, ya que todas las puertas de enlace de aplicaciones están en el dominio de azure.com.
  2. Azure DNS devuelve la dirección IP al cliente, que es la dirección IP de front-end de la puerta de enlace de aplicaciones.
  3. La puerta de enlace de aplicaciones acepta el tráfico entrante en uno o varios clientes de escucha. Un cliente de escucha es una entidad lógica que comprueba si hay solicitudes de conexión. Se configura con una dirección IP de front-end, un protocolo y un número de puerto para las conexiones de los clientes a la puerta de enlace de aplicaciones.
  4. Si el firewall de aplicaciones web (WAF) está en uso, la puerta de enlace de aplicaciones comprueba los encabezados y el cuerpo de la solicitud, si están presentes, según las reglas de WAF. Esta acción determina si la solicitud es una solicitud válida o una amenaza de seguridad. Si la solicitud es válida, se enruta al back-end. Si la solicitud no es válida y WAF se encuentra en modo de prevención, se bloquea como una amenaza de seguridad. Si está en modo de detección, la solicitud se evalúa y se registra, pero se reenvía al servidor back-end.

Azure Application Gateway puede usarse como un equilibrador de carga interno de la aplicación o como un equilibrador de carga de aplicación orientado a Internet. Una puerta de enlace de aplicaciones orientada a Internet usa direcciones IP públicas. El nombre DNS de una puerta de enlace de aplicaciones orientada Internet puede resolverse públicamente en su dirección IP pública. Como consecuencia, las puertas de enlace de aplicaciones orientadas a Internet pueden enrutar las solicitudes de cliente desde Internet.

Las puertas de enlace de aplicaciones internas usan solo las direcciones IP privadas. Si usa una zona DNS privada o personalizada, el nombre de dominio debe poder resolverse internamente en la dirección IP privada de la instancia de Application Gateway. Por lo tanto, los equilibradores de carga internos solo pueden enrutar las solicitudes de clientes con acceso a una red virtual para la puerta de enlace de aplicaciones.

Cómo una puerta de enlace de aplicaciones enruta una solicitud

Si una solicitud es válida o no está bloqueada por WAF, la puerta de enlace de aplicaciones evalúa la regla de enrutamiento de solicitud que está asociada con el cliente de escucha. Esta acción determina a qué grupo de back-end se va a enrutar la solicitud.

Según la regla de enrutamiento de solicitud, la puerta de enlace de aplicaciones determina si debe enrutar todas las solicitudes en el cliente de escucha a un grupo de back-end específico, enrutar las solicitudes a grupos de back-end diferentes en función de la ruta de acceso URL, o redirigir las solicitudes al otro puerto o sitio externos.

Cuando la puerta de enlace de aplicaciones selecciona el grupo de back-end, envía la solicitud a uno de los servidores back-end correctos en el grupo (y.y.y.y). Un sondeo de estado determina el estado del servidor. Si el grupo de back-end contiene varios servidores, la puerta de enlace de aplicaciones utiliza un algoritmo round robin para enrutar las solicitudes entre los servidores en buen estado. Esta carga equilibra las solicitudes en los servidores.

Después de que la puerta de enlace de aplicaciones determina el servidor back-end, abre una nueva sesión TCP con el servidor back-end según la configuración HTTP. La configuración HTTP especifica el protocolo, el puerto y otras configuraciones relacionadas con el enrutamiento que son necesarias para establecer una nueva sesión con el servidor back-end.

El puerto y el protocolo usados en la configuración HTTP determinan si el tráfico entre los servidores back-end y la puerta de enlace de aplicaciones está cifrado (para lograr TLS de un extremo a otro) o sin cifrar.

Nota:

Las reglas se procesan en el orden en que aparecen en el portal para SKU v1.

Cuando una puerta de enlace de la aplicación envía la solicitud original al servidor back-end, respeta las opciones personalizadas en la configuración HTTP relacionadas con reemplazar el nombre de host, la ruta de acceso y el protocolo. Esta acción mantiene la afinidad de sesión basada en cookies, la purga de la conexión y la selección de nombre de host desde el back-end, entre otros.

Si el grupo de back-end:

  • Es un punto de conexión público, la puerta de enlace de aplicaciones usa su dirección IP pública de front-end para tener acceso al servidor. Si no hay una dirección IP pública de front-end, se asigna una a la conectividad saliente externa.
  • Contiene un FQDN que se puede resolver internamente o una dirección IP privada, la puerta de enlace de aplicaciones enruta la solicitud al servidor back-end mediante las direcciones IP privadas de su instancia.
  • Contiene un punto de conexión externo o un FQDN que puede resolverse externamente, la puerta de enlace de aplicaciones enruta la solicitud al servidor back-end mediante la dirección IP pública de su front-end. Si la subred contiene puntos de conexión de servicio, la puerta de enlace de aplicación enrutará la solicitud al servicio a través de su dirección IP privada. La resolución de DNS se basa en una zona DNS privada o un servidor DNS personalizado (si está configurado), o bien utiliza el DNS predeterminado proporcionado por Azure. Si no hay una dirección IP pública de front-end, se asigna una a la conectividad saliente externa.

Resolución DNS del servidor back-end

Cuando el servidor de un grupo de back-end está configurado con un nombre de dominio completo (FQDN), Application Gateway realiza una búsqueda DNS para obtener las direcciones IP del nombre de dominio. El valor de IP se almacena en la memoria caché de la puerta de enlace de aplicación para permitir que llegue a los destinos más rápido al atender las solicitudes entrantes.

Application Gateway conserva esta información almacenada en caché durante el período equivalente al TTL (período de vida) del registro DNS y realiza una búsqueda DNS nueva una vez que expira el TTL. Si una puerta de enlace detecta un cambio en la dirección IP de su consulta de DNS posterior, comenzará a enrutar el tráfico a este destino actualizado. En caso de problemas como que la búsqueda DNS no reciba una respuesta o que el registro ya no exista, la puerta de enlace sigue usando las direcciones IP válidas conocidas. Esto garantiza un impacto mínimo en la ruta de acceso de datos.

  • Al usar servidores DNS personalizados con Virtual Network de Application Gateway, es fundamental que todos los servidores sean idénticos y respondan de forma coherente con los mismos valores DNS.
  • Los usuarios de servidores DNS personalizados locales deben garantizar la conectividad con Azure DNS a través de Azure DNS Private Resolver (recomendado) o la máquina virtual del reenviador DNS al usar una zona DNS privada para el punto de conexión privado.

Modificaciones a una solicitud

Application Gateway inserta seis encabezados adicionales en todas las solicitudes antes de reenviarlas al back-end. Estos encabezados son x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url y x-appgw-trace-id. El formato del encabezado x-forwarded-for es una lista separada por comas de valores IP:puerto.

Los valores válidos para x-forwarded-proto son HTTP o HTTPS. X-forwarded-port especifica el puerto al que llegó la solicitud en la puerta de enlace de aplicaciones. El encabezado x-original-host contiene el encabezado de host original con el que llegó la solicitud. Este encabezado es útil en la integración de Azure Website, donde el encabezado de host entrante se modifica antes de que el tráfico se enrute al back-end. Si la opción de afinidad de sesión está habilitada, se agrega una cookie de afinidad administrada por la puerta de enlace.

X-appgw-trace-id es un GUID único que genera Application Gateway para cada solicitud de cliente y que presenta en la solicitud reenviada al miembro del grupo de back-end. El GUID consta de 32 caracteres alfanuméricos presentados sin guiones (por ejemplo: ac882cd65a2712a0fe1289ec2bb6aee7). Este GUID se puede usar para correlacionar una solicitud recibida e iniciada por Application Gateway con un miembro del grupo de back-end a través de la propiedad transactionId de los registros de diagnóstico.

Puede configurar la puerta de enlace de aplicaciones para que modifique los encabezados y URL de solicitud y respuesta mediante la rescritura de encabezados HTTP y URL o para que modifique la ruta de acceso URI mediante una configuración de invalidación de la ruta de acceso. Sin embargo, a menos que realice la configuración, todas las solicitudes entrantes se procesan con proxy hacia el back-end.