Funcionamiento de una instancia de Application Gateway
En este artículo se explica el proceso que usa una puerta de enlace de aplicaciones para aceptar las solicitudes entrantes y enrutarlas al back-end.
Cómo una puerta de enlace de aplicaciones acepta una solicitud
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.
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.
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.
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.
Nota:
Las reglas se procesan en el orden en que aparecen en el portal para SKU v1.
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.
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.
Nota:
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.
Importante
- Al usar servidores DNS personalizados con Virtual Network de Application Gateway, es fundamental que todos los servidores respondan de forma coherente con los mismos valores DNS. Cuando una instancia de Application Gateway emite una consulta DNS, usa el valor del servidor que responde primero.
- 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.