Cómo funciona una puerta de enlace de aplicaciones

• 16/11/2019
• 4 minutos para leer
• • a
  • j
  • D
  • s
  • v
  • +2

Este artículo explica cómo una pasarela de aplicación acepta las peticiones entrantes y las enruta al backend.

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 utilizando un servidor de Sistema de nombres de dominio (DNS). Azure controla la entrada DNS porque todas las puertas de enlace de aplicaciones están en el dominio azure.com.

2. El DNS de Azure devuelve la dirección IP al cliente, que es la dirección IP del frontend de la puerta de enlace de aplicaciones.

3. La puerta de enlace de aplicaciones acepta el tráfico entrante en uno o más escuchadores. Un listener es una entidad lógica que comprueba las solicitudes de conexión. Se configura con una dirección IP frontal, un protocolo y un número de puerto para las conexiones de los clientes a la pasarela de aplicación.

4. Si se utiliza un cortafuegos de aplicaciones web (WAF), la pasarela de aplicación comprueba las cabeceras de la solicitud y el cuerpo, si está presente, con las reglas del WAF. Esta acción determina si la solicitud es válida o una amenaza para la seguridad. Si la solicitud es válida, se dirige al backend. Si la solicitud no es válida y el WAF está 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 sigue reenviando al servidor backend.

Azure Application Gateway puede utilizarse como equilibrador de carga de aplicaciones interno o como equilibrador de carga de aplicaciones orientado a Internet. Una puerta de enlace de aplicaciones orientada a Internet utiliza direcciones IP públicas. El nombre DNS de una puerta de enlace de aplicaciones orientada a Internet se puede resolver públicamente con su dirección IP pública. Como resultado, las puertas de enlace de aplicaciones orientadas a Internet pueden enrutar las solicitudes de los clientes desde Internet.

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

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

Si una solicitud es válida y no está bloqueada por WAF, la puerta de enlace de aplicaciones evalúa la regla de enrutamiento de solicitudes que está asociada con el oyente. Esta acción determina a qué grupo de backend debe dirigirse la solicitud.

En función de la regla de enrutamiento de solicitudes, la puerta de enlace de aplicaciones determina si debe dirigir todas las solicitudes del oyente a un grupo de backend específico, dirigir las solicitudes a diferentes grupos de backend en función de la ruta de la URL o redirigir las solicitudes a otro puerto o sitio externo.

Cuando la puerta de enlace de la aplicación selecciona el grupo de backend, envía la solicitud a uno de los servidores backend sanos del grupo (y.y.y). La salud del servidor se determina mediante una sonda de salud. Si el pool de backend contiene varios servidores, la pasarela de aplicaciones utiliza un algoritmo round-robin para enrutar las peticiones entre los servidores sanos. Esto equilibra la carga de las solicitudes en los servidores.

Después de que la puerta de enlace de la aplicación determina el servidor backend, abre una nueva sesión TCP con el servidor backend basándose en la configuración HTTP. Los ajustes HTTP especifican el protocolo, el puerto y otros ajustes relacionados con el enrutamiento que se requieren para establecer una nueva sesión con el servidor backend.

El puerto y el protocolo utilizados en los ajustes HTTP determinan si el tráfico entre la pasarela de aplicación y los servidores backend está cifrado (logrando así TLS de extremo a extremo) o no está cifrado.

Cuando una puerta de enlace de aplicaciones envía la solicitud original al servidor backend, respeta cualquier configuración personalizada realizada en la configuración HTTP relacionada con la anulación del nombre de host, la ruta y el protocolo. Esta acción mantiene la afinidad de sesión basada en cookies, el vaciado de la conexión, la selección del nombre de host del backend, etc..

Modificaciones de la solicitud

Una puerta de enlace de aplicaciones inserta cuatro cabeceras adicionales en todas las solicitudes antes de reenviarlas al backend. Estas cabeceras son x-forwarded-for, x-forwarded-proto, x-forwarded-port y x-original-host. El formato de la cabecera x-forwarded-for es una lista separada por comas de IP:puerto.

Los valores válidos para x-forwarded-proto son HTTP o HTTPS. X-forwarded-port especifica el puerto por el que la solicitud llegó a la pasarela de aplicación. La cabecera X-original-host contiene la cabecera original del host con el que llegó la solicitud. Este encabezado es útil en la integración de sitios web de Azure, donde el encabezado de host entrante se modifica antes de que el tráfico se enrute al backend. Si la afinidad de sesión está habilitada como opción, entonces añade una cookie de afinidad gestionada por la puerta de enlace.

Puede configurar la puerta de enlace de la aplicación para modificar las cabeceras de solicitud y respuesta y la URL mediante el uso de Rewrite HTTP headers and URL o para modificar la ruta URI mediante el uso de una configuración de path-override. Sin embargo, a menos que se configure para hacerlo, todas las solicitudes entrantes son proxies al backend.

Aprenda sobre los componentes de la pasarela de aplicación