Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte 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. Cuando configuras el oyente, debes introducir valores para estos ajustes que coincidan con los valores correspondientes en la solicitud entrante en la pasarela.
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. La elección depende de si el enrutamiento depende del nombre de host en la solicitud entrante.
| El enrutamiento depende del nombre del host | Tipo de cliente de escucha | Comportamiento |
|---|---|---|
| No | Basic | Acepta y reenvía todas las peticiones de cualquier dominio a los pools de backend. Aprenda a crear una puerta de enlace de aplicaciones con un escuchador básico. |
| Sí | Multisitio | Reenvía las solicitudes a distintos grupos de servidores back-end según la cabecera host o los nombres de host. 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, debes especificar un nombre de host que coincida con la solicitud entrante. |
Para obtener más información sobre los oyentes multisitio, consulte Alojamiento 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 oyente básico aparece primero en el orden, procesa primero y acepta cualquier solicitud para esa combinación de puerto e IP. Para evitar este comportamiento, configura primero las reglas con listeners multisitio y desplaza al final de la lista la regla con el listener básico.
Para la SKU v2, la prioridad de la regla define el orden en el que se procesan los agentes de escucha. Define los oyentes comodín y básicos con un número de prioridad mayor que el de los oyentes específicos de sitio y multisitio. Esta configuración garantiza que los oyentes específicos de sitio y multisitio se ejecuten antes que los oyentes comodín y básicos.
La siguiente tabla resume cómo se determina el orden de procesamiento en cada SKU.
| SKU | Qué determina el orden | Configuración recomendada |
|---|---|---|
| v1 | El orden de las reglas y el tipo de oyente. Una regla con un oyente básico que aparece en primer lugar en el orden se procesa primero y acepta cualquier solicitud para esa combinación de puerto e IP. | Configure primero las reglas con escuchas multisitio y coloque la regla con la escucha básica en la última posición de la lista. |
| v2 | Prioridad de la regla. | Defina detectores genéricos y básicos con un número de prioridad superior al utilizado para los detectores de sitio específico y de varios sitios, de modo que los detectores de sitio específico y de varios sitios se ejecuten primero. |
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 oyente escucha las solicitudes entrantes en esta IP.
Elija una dirección IP pública de front-end cuando los clientes accedan a la aplicación detrás de esta escucha a través de Internet. Elige una dirección IP privada de frontend para un endpoint interno que no esté expuesto a internet, como una aplicación interna de línea de negocio o un nivel de una aplicación multinivel que aún requiera distribución de carga, fijación de sesión o terminación TLS. Para las combinaciones soportadas, véase Configuración de direcciones IP del frontend.
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.
El puerto 80 es la opción típica para un oyente HTTP, y el puerto 443 es la opción típica para un oyente HTTPS. Usa un puerto personalizado cuando tu aplicación lo requiera y confirma que el valor está dentro del rango permitido para tu SKU, porque el rango soportado varía entre los SKUs v1 y v2.
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
Elige HTTP o HTTPS. Elige HTTPS cuando el tráfico entre el cliente y la pasarela de aplicaciones deba estar cifrado, lo que también permite que la pasarela descargue el trabajo de cifrado y descifrado para que tus servidores backend no estén sobrecargados por el cómputo TLS. Elige HTTP cuando ese cifrado no sea necesario para el tráfico que este oyente acepta.
Si elige HTTP, el tráfico entre el cliente y la puerta de enlace de la aplicación está sin cifrar.
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 función de terminación de 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 soportados
Consulte Información general de la terminación de TLS y TLS de extremo a extremo con Application Gateway.
Compatibilidad con protocolos adicionales
Compatibilidad con HTTP/2
Application Gateway admite el protocolo HTTP/2 para los clientes que se conectan a los agentes de escucha de Application Gateway. La comunicación con pools de servidores backend siempre utiliza HTTP/1.1. De forma predeterminada, HTTP/2 está deshabilitado. El siguiente fragmento de código de Azure PowerShell muestra cómo habilitar este soporte:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Importante
Cuando creas un recurso de pasarela de aplicaciones a través del portal de Azure, la opción predeterminada para HTTP2 está activada. Puedes elegir Desactivado durante la creación y volver a activar el soporte de HTTP/2 seleccionando Habilitado en HTTP2 en Configuración de la pasarela > de aplicación en el portal de Azure.
En casos donde un cliente no soporta HTTP/2, la conexión utiliza HTTP/1.1. Activar HTTP/2 no desactiva HTTP/1.1; permite soporte para ambos.
Nota:
Application Gateway solo admite HTTP/2 a través de TLS (agentes de escucha HTTPS). Application Gateway no soporta intentos de actualización del protocolo HTTP/2 Cleartext (h2c) desde HTTP/1.1 y devuelve un error 403 Prohibido. Los clientes que intenten actualizaciones h2c deben usar conexiones nativas HTTP/2 sobre HTTPS o permanecer en HTTP/1.1.
Soporte HTTP/3 (QUIC)
Importante
El soporte de HTTP/3 en Azure Application Gateway está actualmente en fase de vista previa. Aunque en versión preliminar, la funcionalidad, la disponibilidad y otros aspectos de esta característica pueden cambiar en respuesta a los comentarios.
Esta versión preliminar se proporciona sin un contrato de nivel de servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características no se admitan o que tengan funcionalidades restringidas.
Para obtener más información, vea Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
Application Gateway solo soporta HTTP/3 para conexiones de cliente que usan oyentes Basic. Un oyente habilitado para HTTP/3 también puede aceptar tráfico HTTP/1.1 o HTTP/2 de los clientes. La comunicación desde la Pasarela de Aplicaciones hacia los pools de servidores backend continúa usando HTTP/1.1.
El soporte para HTTP/3 está desactivado por defecto.
Cómo se anuncia el soporte HTTP/3
Application Gateway anuncia soporte HTTP/3 utilizando el encabezado de respuesta HTTP Alt-Svc. Cuando activas HTTP/3 en un oyente, Application Gateway incluye el siguiente encabezado de Alt-Svc en las respuestas.
Alt-Svc: h3=":<listener-port>"; ma=86400
Cuando desactivas HTTP/3, Application Gateway no incluye el encabezado Alt-Svc.
Los clientes que soportan HTTP/3 pueden usar el servicio anunciado para establecer una conexión QUIC en el puerto del oyente. Los clientes que no soportan HTTP/3 continúan usando HTTP/2 o HTTP/1.1 sobre TCP.
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
Puedes definir páginas de error personalizadas para los diferentes códigos de respuesta que devuelva Application Gateway. Puedes configurar páginas de error para los códigos de respuesta 400, 403, 405, 408, 500, 502, 503 y 504. Utiliza una configuración global o específica de la página de error del oyente para configurarlos de forma granular para cada oyente. Para más información, consulte Create Application Gateway custom error pages (Creación de páginas de error personalizadas de Application Gateway).
Nota:
La Pasarela de Aplicación transmite un error desde el servidor backend al cliente sin modificarlo.
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 manejo centralizado de TLS también te permite especificar una política central de TLS que se adapte a tus necesidades de seguridad. Puedes elegir una política TLS predefinida o personalizada .
Configuras la política TLS para controlar las versiones del protocolo TLS. Puedes configurar una pasarela de aplicación para usar una versión mínima de protocolo para los handshakes TLS de TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.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 escuchador, lo asocias con una regla de enrutamiento de solicitudes. Esa regla determina cómo se dirigen al back-end las solicitudes que recibe el listener.