Configuración del cliente de escucha de Application Gateway
Nota:
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para empezar, vea Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.
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
Cuando crea un nuevo cliente de escucha, puede elegir entre básico y multisitio.
Si desea que se acepten todas las solicitudes (para cualquier dominio) y se reenvíen a los grupos de servidores back-end, elija básico. Aprenda a crear una puerta de enlace de aplicaciones con un cliente de escucha básico.
Si quiere reenviar las solicitudes a diferentes grupos de servidores back-end en función del encabezado host o del nombre de host, elija un cliente de escucha multisitio. Application Gateway se basa en los encabezados de host HTTP 1.1 para hospedar más de un sitio web en la misma dirección IP pública y en el mismo puerto. Para diferenciar las solicitudes en el mismo puerto, debe especificar un nombre de host que coincida con la solicitud entrante. Para obtener más información, consulte Hospedaje de varios sitios mediante Application Gateway.
Orden de procesamiento de los clientes de escucha
En el caso de la SKU v1, la correspondencia de las solicitudes se establece según el orden de las reglas y el tipo de cliente de escucha. Si una regla con un cliente de escucha básico está en primera posición según el orden, se procesa en primer lugar y acepta cualquier solicitud para esa combinación de puerto y dirección IP. Para evitar este comportamiento, configure las reglas con clientes de escucha multisitio en primer lugar e inserte la regla con el cliente de escucha básico en el último lugar de la lista.
Para la SKU v2, los clientes de escucha multisitio se procesan antes que los básicos, a menos que se defina una prioridad de las reglas. Si se utiliza la prioridad de las reglas, los clientes de escucha con caracteres comodín deben tener un número de prioridad mayor que aquellos que no incluyen caracteres comodín, para garantizar que estos últimos se ejecuten antes que los clientes de escucha con caracteres comodín.
Frontend IP address (Dirección IP de front-end)
Elija la dirección IP de front-end que va a asociar a este cliente de escucha. El cliente de escucha escuchará las solicitudes entrantes en esta dirección IP.
Nota:
El front-end de Application Gateway admite direcciones IP de doble pila. Puede crear hasta cuatro direcciones IP de front-end: dos direcciones IPv4 (públicas y privadas) y dos direcciones IPv6 (públicas y privadas).
Puerto de front-end
Asocie un puerto de front-end. Puede seleccionar un puerto existente o crear uno nuevo. Elija cualquier valor del intervalo de puertos permitidos. Puede usar no solo los puertos conocidos, como el 80 y el 443, sino cualquier puerto permitido personalizado que sea adecuado. El mismo puerto se puede usar para agentes de escucha públicos y privados.
Nota:
Cuando se usan agentes de escucha privados y públicos con el mismo número de 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. Por lo tanto, en función de la configuración del grupo de seguridad de red, es posible que necesite una regla de entrada con direcciones IP de destino como direcciones IP de front-end públicas y privadas de la puerta de enlace de aplicaciones.
Regla de entrada:
- Origen: (según sus necesidades)
- Direcciones IP de destino: direcciones IP de front-end pública y privada de la puerta de enlace de aplicaciones.
- Puerto de destino: (según la configuración del agente de escucha)
- Protocolo: TCP
regla de salida: (ningún requisito específico)
Protocolo
Elija HTTP o HTTPS:
Si elige HTTP, se descifrará el tráfico entre el cliente y la puerta de enlace de aplicaciones.
Seleccione HTTPS si quiere terminación TLS o cifrado TLS de un extremo a otro. El tráfico entre el cliente y la puerta de enlace de aplicación se cifra y la conexión TLS se finalizará en dicha puerta de enlace de aplicación. Si desea un cifrado TLS de un extremo a otro en el destino de back-end, también debe elegir HTTPS en la configuración HTTP de back-end. Esto garantiza que el tráfico se cifrará cuando la puerta de enlace de aplicación inicie una conexión con el destino de back-end.
Para configurar la terminación TLS, se debe agregar un certificado TLS/SSL al cliente de escucha. Esto permite a Application Gateway descifrar el tráfico entrante y cifrar el tráfico de respuesta al cliente. El certificado proporcionado a Application Gateway debe estar en formato Intercambio de información personal (PFX), que contiene las claves privadas y públicas.
Nota:
Al usar un certificado TLS de Key Vault para un agente de escucha, debe asegurarse de que la instancia de Application Gateway siempre tenga acceso a ese recurso de almacén de claves vinculado y al objeto de certificado que contiene. Esto permite operaciones fluidas de la característica de terminación TLS y mantiene el estado general del recurso de puerta de enlace. Si un recurso de puerta de enlace de aplicación detecta un almacén de claves con una configuración incorrecta, coloca automáticamente los agentes de escucha HTTPS asociados en un estado deshabilitado. Más información.
Certificados admitidos
Consulte Introducción a la terminación TLS y a TLS de extremo a extremo con Application Gateway.
Compatibilidad con protocolos adicionales
Compatibilidad con HTTP2
La compatibilidad con el protocolo HTTP/2 está disponible únicamente para los clientes que se conectan a los clientes de escucha de la puerta de aplicaciones. La comunicación con grupos de servidores back-end es siempre HTTP/1.1. De forma predeterminada, HTTP/2 está deshabilitado. El siguiente fragmento de código de Azure PowerShell muestra cómo habilitarlo:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
También puede habilitar la compatibilidad con HTTP2 mediante Azure Portal si selecciona Habilitado en HTTP2 en Configuración de Application Gateway >.
Compatibilidad con WebSocket
La compatibilidad con WebSocket está habilitada de forma predeterminada. No hay ninguna opción de configuración que permita al usuario habilitarla o deshabilitarla. Puede usar WebSockets con clientes de escucha HTTP y HTTPS.
Páginas de error personalizadas
Puede definir páginas de error personalizadas para distintos códigos de respuesta devueltos por Application Gateway. Los códigos de respuesta para los que puede configurar las páginas de error son 400, 403, 405, 408, 500, 502, 503 y 504. Puede usar la configuración de página de error específica del cliente de escucha o de nivel global para establecerlas de forma granular para cada agente de escucha. Para más información, consulte Create Application Gateway custom error pages (Creación de páginas de error personalizadas de Application Gateway).
Nota:
El cliente pasa un error que origina el servidor back-end sin modificar.
Directiva TLS
Puede centralizar la administración de certificados TLS/SSL y reducir la sobrecarga de cifrado y descifrado de una granja de servidores de back-end. El control centralizado de TLS también le permite especificar una directiva TLS central adaptada a sus requisitos de seguridad. Puede elegir la directiva TLS predefinida o personalizada.
Puede configurar la directiva TLS para controlar las versiones del protocolo TLS. Puede configurar una puerta de enlace de aplicación para que use una versión de protocolo mínima para los protocolos de enlace TLS desde TLS1.0, TLS1.1, TLS1.2 y TLS1.3. De forma predeterminada, SSL 2.0 y 3.0 están deshabilitadas y no se pueden configurar. Para más información, consulte Introducción a la directiva TLS de Application Gateway.
Después de crear un cliente de escucha, puede asociarlo a una regla de enrutamiento de solicitud. Esta regla determina cómo se enrutan las solicitudes que se reciben en el cliente de escucha hacia el back-end.