Funcionamiento de Azure Application Gateway
Azure Application Gateway tiene una serie de componentes que se combinan para enrutar y equilibrar la carga de forma segura las solicitudes en un grupo de servidores web. Application Gateway incluye los siguientes componentes:
- Dirección IP de front-end: las solicitudes de cliente se reciben a través de una dirección IP de front-end. Puede configurar Application Gateway para que tenga una dirección IP pública, privada o ambas. Application Gateway no puede tener más de una dirección IP pública y una privada.
- Clientes de escucha: Application Gateway usa uno o varios clientes de escucha para recibir las solicitudes entrantes. Un agente de escucha acepta el tráfico que llega a una combinación especificada de protocolo, puerto, host y dirección IP. Cada agente de escucha enruta las solicitudes a un grupo de servidores back-end siguiendo las reglas de enrutamiento que especifique. Un agente de escucha puede ser básico o multisitio. Un cliente de escucha básico solo enruta una solicitud según la ruta de acceso de la dirección URL. Un cliente de escucha multisitio también puede enrutar las solicitudes mediante el elemento de nombre de host de la dirección URL. Los agentes de escucha también controlan los certificados TLS/SSL para proteger la aplicación entre el usuario y Application Gateway.
- Reglas de enrutamiento: una regla de enrutamiento enlaza un cliente de escucha a los grupos de servidores back-end. Una regla especifica cómo interpretar los elementos de nombre de host y ruta de acceso de la dirección URL de una solicitud, y dirige la solicitud al grupo de servidores back-end adecuado. Una regla de enrutamiento también tiene un conjunto de configuración de HTTP asociado. Estas configuraciones de HTTP indican si se cifra el tráfico entre Application Gateway y los servidores back-end y cómo hacerlo. Entre las otras informaciones de configuración se incluye el protocolo, la permanencia de sesión, el drenaje de conexiones, el período de tiempo de espera de una solicitud y los sondeos de estado.
Equilibrio de carga en Application Gateway
Application Gateway equilibra automáticamente la carga de las solicitudes enviadas a los servidores de cada grupo back-end mediante un mecanismo round-robin. El equilibrio de carga funciona con el enrutamiento de la capa OSI 7 implementado por el enrutamiento de Application Gateway, lo que significa que equilibra la carga de las solicitudes en función de los parámetros de enrutamiento (nombres y rutas de acceso de host) utilizados por las reglas de Application Gateway. En comparación, otros equilibradores de carga, como Azure Load Balancer, funcionan en el nivel de capa OSI 4 y distribuyen el tráfico según la dirección IP del destino de una solicitud.
Si tiene que asegurarse de que todas las solicitudes para un cliente en la misma sesión se enrutan al mismo servidor en un grupo de servidores back-end, puede configurar la permanencia de sesión.
Firewall de aplicaciones web
El firewall de aplicaciones web (WAF) es un componente opcional que controla las solicitudes entrantes antes de que lleguen a un agente de escucha. El firewall de aplicaciones web comprueba cada solicitud en busca de muchos riesgos comunes, según el Open Web Application Security Project (OWASP). Entre las amenazas comunes se incluyen las siguientes: Inyección de código SQL, scripting entre sitios, inyección de comandos, contrabandamiento de solicitudes HTTP, división de respuesta HTTP, inclusión remota de archivos, bots, rastreadores y escáneres, y infracciones y anomalías del protocolo HTTP.
OWASP define un conjunto de reglas genéricas para detectar ataques. Estas reglas se conocen como Core Rule Set (CRS). Los conjuntos de reglas están en continua revisión, puesto que los ataques son cada vez más sofisticados. WAF admite cuatro conjuntos de reglas: CRS 3.2, 3.1, 3.0 y 2.2.9. CRS 3.1 es el valor predeterminado. Si es necesario, puede optar por seleccionar únicamente determinadas reglas de un conjunto de reglas, que están destinadas a determinadas amenazas. Además, puede personalizar el firewall para que especifique qué elementos de una solicitud debe examinar y limitar el tamaño de los mensajes para evitar que cargas masivas sobrecarguen los servidores.
Grupos de servidores back-end
Un grupo de back-end es una colección de servidores web que se pueden componer de: un conjunto fijo de máquinas virtuales, un conjunto de escalado de máquinas virtuales, una aplicación hospedada por Azure App Services o una colección de servidores locales.
Cada grupo de servidores back-end tiene un equilibrador de carga asociado que distribuye el trabajo en el grupo. Al configurar el grupo, proporcione la dirección IP o el nombre de cada servidor web. Todos los servidores en el grupo de back-end se deben configurar de la misma manera, incluida su configuración de seguridad.
Si usa TLS/SSL, el grupo de back-end tiene una configuración de HTTP que hace referencia a un certificado utilizado para autenticar los servidores de back-end. La puerta de enlace vuelve a cifrar el tráfico con este certificado antes de enviarlo a uno de los servidores en el grupo de back-end.
Si usa Azure App Service para hospedar la aplicación de back-end, no es necesario que instale ningún certificado en Application Gateway para conectarse al grupo de back-end. Todas las comunicaciones se cifran automáticamente. Application Gateway confía en los servidores porque los administra Azure.
Application Gateway usa una regla para especificar cómo dirigir los mensajes que recibe en su puerto de entrada a los servidores del grupo de back-end. Si los servidores usan TLS/SSL, debe configurar la regla para que indique lo siguiente:
- Que los servidores esperan tráfico a través del protocolo HTTPS.
- Qué certificado debe usarse para cifrar el tráfico y autenticar la conexión a un servidor.
Enrutamiento de Application Gateway
Cuando la puerta de enlace enruta la solicitud del cliente a un servidor web en el grupo de servidores back-end mediante un conjunto de reglas configuradas para que la puerta de enlace determine dónde debería ir la solicitud. Hay dos métodos principales de enrutamiento del tráfico de solicitudes de clientes: enrutamiento basado en rutas de acceso y enrutamiento de varios sitios.
Enrutamiento basado en ruta de acceso
El enrutamiento basado en rutas de acceso envía solicitudes con distintas rutas de acceso de URL a distintos grupos de servidores back-end. Por ejemplo, podría dirigir las solicitudes con la ruta /video/* a un grupo de servidores backend que contenga servidores que están optimizados para controlar el streaming de vídeo y dirigir las solicitudes de /images/* a un grupo de servidores que administran la recuperación de imágenes.
Enrutamiento de varios sitios
El enrutamiento de varios sitios configura más de una aplicación web en la misma instancia de Application Gateway. En una configuración de varios sitios, hay que registrar varios nombres de DNS (CNAME) para la dirección IP de la puerta de enlace de aplicación, especificando el nombre de cada sitio. Application Gateway usa agentes de escucha independientes para esperar por las solicitudes de cada sitio. Cada agente de escucha pasa la solicitud a otra regla, que puede enrutar las solicitudes a servidores en otro grupo de servidores back-end. Por ejemplo, podría dirigir todas las solicitudes de http://contoso.com a los servidores de un grupo back-end y las solicitudes de http://fabrikam.com a otro grupo back-end. El diagrama siguiente muestra esta configuración:
Las configuraciones de varios sitios son útiles para admitir aplicaciones multiinquilino, donde cada inquilino tiene su propio conjunto de máquinas virtuales u otros recursos que hospedan una aplicación web.
El enrutamiento de Application Gateway también incluye estas características:
- Redireccionamiento. El redireccionamiento puede ser hacia otro sitio o de HTTP a HTTPS.
- Reescritura de encabezados HTTP. Los encabezados HTTP permiten que el cliente y el servidor pasen información de parámetros con la solicitud o la respuesta.
- Páginas de error personalizadas. Application Gateway permite crear páginas de error personalizadas, en lugar de mostrar las páginas de error predeterminadas. Mediante una página de error personalizada puede usar su propia marca y diseño.
Terminación de TLS/SSL
Cuando finaliza la conexión TLS/SSL en la puerta de enlace de aplicaciones, descarga la carga de trabajo de la terminación TLS/SSL intensiva de CPU de los servidores. Además, no es necesario instalar certificados y configurar TLS/SSL en los servidores.
Si necesita el cifrado de extremo a extremo, Application Gateway puede descifrar el tráfico en la puerta de enlace con la clave privada y, después, volver a cifrarlo con la clave pública del servicio que se ejecuta en el grupo de back-end.
El tráfico entra en la puerta de enlace por medio de un puerto de front-end. Puede abrir muchos puertos, y Application Gateway puede recibir mensajes en cualquiera de ellos. Un cliente de escucha es lo primero que se encuentra el tráfico al entrar en la puerta de enlace a través de un puerto. El agente de escucha está configurado para escuchar un nombre de host específico y un puerto específico en una dirección IP específica. El cliente de escucha puede usar un certificado TLS/SSL para descifrar el tráfico que entra en la puerta de enlace. Después, el cliente de escucha usa una regla que ha definido para dirigir las solicitudes entrantes a un grupo de back-end.
Exponer una aplicación web o un sitio web a través de la puerta de enlace de aplicaciones también significa que los servidores no se conectan directamente a la web. Solo expone el puerto 80 o el 443 en la puerta de enlace de aplicaciones, que luego se reenvía al servidor del grupo de back-end. En esta configuración, los servidores web no son accesibles directamente desde Internet, lo que reduce la superficie de ataque de su infraestructura.
Sondeos de estado
Los sondeos de estado determinan qué servidores están disponibles para el equilibrio de carga en un grupo back-end. Application Gateway usa un sondeo de estado para enviar una solicitud a un servidor. Cuando el servidor devuelve una respuesta HTTP con un código de estado entre 200 y 399, se considera que el servidor está en buen estado. Si no configura un sondeo de estado, Application Gateway crea un sondeo predeterminado que espera 30 segundos antes de decidir que un servidor no está disponible. Los sondeos de estado garantizan que el tráfico no se dirige a un punto de conexión web no responde o con errores en el grupo de back-end.
Escalado automático
Application Gateway admite el escalado automático y puede escalarse o reducirse verticalmente en función de los cambiantes patrones de la carga de tráfico. La escalabilidad automática también elimina el requisito de tener elegir un tamaño de implementación o un número de instancias durante el aprovisionamiento.
Tráfico de WebSocket y HTTP/2
Application Gateway proporciona compatibilidad nativa con los protocolos Websocket y HTTP/2. Los protocolos WebSocket y HTTP/2 permiten una comunicación dúplex completa entre un servidor y un cliente a través de una conexión TCP de larga duración. Este tipo de comunicación es más interactivo entre el servidor web y el cliente, y puede ser bidireccional sin necesidad de sondear según sea necesario en implementaciones basadas en HTTP. Estos protocolos tienen, a diferencia de HTTP, una sobrecarga reducida y pueden reutilizar la misma conexión TCP para varias solicitudes y respuestas, con lo que se utilizan los recursos de una manera más eficaz. Estos protocolos están diseñados para utilizarse a través de los puertos HTTP tradicionales 80 y 443.