Oyentes para los equilibradores de carga de red - Elastic Load Balancing

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Oyentes para los equilibradores de carga de red

Un oyente es un proceso que comprueba las solicitudes de conexión mediante el protocolo y el puerto configurados. Antes de comenzar a utilizar el equilibrador de carga de red, debe agregar al menos un oyente. Si su equilibrador de carga no cuenta con oyentes, no puede recibir tráfico de los clientes. Las reglas que defina para un oyente determinan cómo el equilibrador de carga direcciona las solicitudes a sus destinos registrados, como instancias de EC2.

Configuración del oyente

Los oyentes son compatibles con los siguientes protocolos y puertos:

  • Protocolos: TCP, TLS, UDP, TCP_UDP, QUIC, TCP_QUIC

  • Puertos: 1-65535

Puede utilizar un agente de escucha TLS para trasladar la carga de cifrado y descifrado al balanceador de carga con el fin de que las aplicaciones puedan concentrarse en la lógica de negocio. Si el protocolo del oyente es TLS, debe implementar al menos un certificado de servidor SSL en el oyente. Para obtener más información, consulte Certificados de servidor.

Si se debe asegurar de que los destinos descifren el tráfico de TLS en lugar del equilibrador de carga, puede crear un oyente de TCP en el puerto 443 en lugar de crear un oyente de TLS. Con un oyente de TCP, el equilibrador de carga transfiere el tráfico cifrado a los destinos sin descifrarlo.

Puede usar un oyente QUIC para aceptar tráfico QUIC. El Network Load Balancer actúa como un balanceador de cargas de paso de acuerdo con. RFC9000 Utilice un oyente QUIC y backends con QUIC habilitado para permitir una migración de conexiones fluida en dispositivos móviles.

Para admitir TCP y UDP en el mismo puerto, cree un agente de escucha TCP_UDP. Los grupos de destino de un agente de escucha TCP_UDP deben utilizar el protocolo TCP_UDP.

Para admitir tanto TCP como QUIC en el mismo puerto, cree un oyente TCP_QUIC. Los grupos de destino de un oyente TCP_QUIC deben usar el protocolo TCP_QUIC.

Un detector UDP para un balanceador de cargas de doble pila requiere grupos objetivo. IPv6

WebSockets solo es compatible con los oyentes TCP, TLS, TCP_UDP y TCP_QUIC.

El tráfico QUIC no admite la negociación de versiones. QUIC v1 es la única versión de QUIC compatible.

Todo el tráfico de red enviado a un agente de escucha configurado se clasifica como tráfico deseado. El tráfico de red que no coincide con un agente de escucha configurado se clasifica como tráfico no deseado. Las solicitudes de ICMP distintas del tipo 3 también se consideran tráfico no deseado. Los equilibradores de carga de red eliminan el tráfico no deseado sin reenviarlo a un destino. Los paquetes de datos TCP enviados al puerto de los agentes de escucha configurados que no sean conexiones nuevas ni formen parte de una conexión TCP activa se rechazan con un restablecimiento TCP (RST).

Para obtener más información, consulte Enrutamiento de solicitudes en la Guía del usuario de Elastic Load Balancing.

Acciones predeterminadas

Al crear un oyente, se especifica una acción predeterminada para el enrutamiento de las solicitudes. La acción predeterminada reenvía las solicitudes a los grupos de destino especificados.

Distribución del tráfico entre varios grupos de destino

Si especifica varios grupos de destino para una acción predeterminada, las solicitudes se distribuyen entre estos grupos de destino en función de sus ponderaciones relativas. Debe especificar una ponderación de 0 a 999 para cada grupo de destino. Un grupo de destino con una ponderación de 0 no recibe tráfico. Después de agregar un grupo de destino o de actualizar las ponderaciones de los grupos de destino, las nuevas conexiones se enrutan según las nuevas ponderaciones de los grupos de destino. Las conexiones existentes no se ven afectadas y continúan hasta que se cierran, como de costumbre.

Por ejemplo, si especifica dos grupos de destino, cada uno con una ponderación de 10, cada grupo de destino recibe la mitad de las solicitudes. Si especifica dos grupos de destino, uno con una ponderación de 10 y el otro con una ponderación de 20, el grupo de destino con una ponderación de 20 recibe el doble de solicitudes que el grupo de destino con una ponderación de 10.

Un caso de uso común consiste en migrar el tráfico de un grupo de destino a otro. Esto significa que se incrementa gradualmente la ponderación del nuevo grupo de destino mientras se reduce la ponderación del grupo de destino original hasta llegar a 0. Si actualiza la ponderación de un grupo de destino a 0, después de un breve periodo, no recibe nuevas conexiones y las conexiones existentes se cierran.

Sesiones persistentes y grupos de destinos ponderados

Las acciones de reenvío en los oyentes pueden especificar si se habilita la persistencia de grupos de destino. Cuando se habilita, la persistencia de grupos de destino hace que las conexiones posteriores desde la misma dirección IP de origen prefieran el grupo de destino seleccionado previamente.

Consideraciones
  • Para oyentes TLS, no se pueden agregar simultáneamente grupos de destino TCP y grupos de destino TLS a la regla del oyente. Todos los grupos de destino deben usar el mismo protocolo.

  • Para oyentes TLS, la persistencia de grupos de destino no es compatible.

  • En el caso de los balanceadores de cargas de doble pila, no puedes añadir grupos objetivo y grupos objetivo a la misma acción predeterminada. IPv4 IPv6 Todos los grupos de destino en la acción predeterminada deben usar el mismo tipo de dirección IP.

  • En el caso de los oyentes, si una acción de reenvío contiene varios grupos de destino y alguno de ellos tiene la persistencia habilitada, la acción de reenvío también debe tener habilitada la persistencia de grupos de destino.

Atributos del oyente

A continuación se indican los atributos del oyente de los equilibradores de carga de red:

tcp.idle_timeout.seconds

Valor del tiempo de inactividad de TCP, en segundos. El rango válido es de 60 a 6000 segundos. El valor predeterminado es de 350 segundos.

Para obtener más información, consulte Actualización del tiempo de inactividad.

Oyentes seguros

Para utilizar un agente de escucha TLS, debe implementar al menos un certificado de servidor en el balanceador de carga. El balanceador de carga utiliza un certificado de servidor para terminar la conexión frontend y descifrar las solicitudes de los clientes antes de enviarlas a los destinos. Tenga en cuenta que si necesita transferir tráfico cifrado a los destinos sin que el equilibrador de carga lo descifre, debe crear un oyente de TCP en el puerto 443 en lugar de crear un oyente de TLS. El equilibrador de carga transfiere la solicitud al destino tal cual, sin descifrarla.

Elastic Load Balancing utiliza una configuración de negociación de TLS, lo que se conoce como política de seguridad, para negociar las conexiones de TLS entre un cliente y el equilibrador de carga. Una política de seguridad es una combinación de protocolos y cifrados. El protocolo establece una conexión segura entre un cliente y un servidor, y garantiza que todos los datos transferidos entre el cliente y el equilibrador de carga son privados. Un cifrado es un algoritmo de cifrado que usa claves de cifrado para crear un mensaje codificado. Los protocolos usan diversos cifrados para cifrar los datos a través de Internet. Durante el proceso de negociación de conexiones, el cliente y el equilibrador de carga presentan una lista con los cifrados y protocolos que admite cada uno por orden de preferencia. El primer cifrado de la lista del servidor que coincide con uno de los cifrados del cliente se selecciona para la conexión segura.

Los equilibradores de carga de red no admiten la autenticación TLS mutua (mTLS). En el caso de la compatibilidad con mTLS, cree un oyente de TCP en lugar de uno de TLS. El equilibrador de carga transmite la solicitud tal cual, de modo que puede implementar mTLS en el destino.

Los equilibradores de carga de red admiten la reanudación de TLS mediante PSK para TLS 1.3 y tickets de sesión para TLS 1.2 y versiones anteriores. No se admiten las reanudaciones con ID de sesión ni los casos en los que se configuran varios certificados en el oyente mediante SNI. La característica de datos 0-RTT y la extensión early_data no están implementadas.

Para ver demostraciones relacionadas, consulte la Compatibilidad con TLS en el equilibrador de carga de red y la Compatibilidad con SNI en el equilibrador de carga de red.

Políticas de ALPN

La negociación de protocolo de capa de aplicación (ALPN) es una extensión TLS que se envía en los mensajes de saludo iniciales de TLS. ALPN permite a la capa de aplicación negociar qué protocolos deben utilizarse a través de una conexión segura, como HTTP/1 y HTTP/2.

Cuando el cliente inicia una conexión de ALPN, el balanceador de carga compara la lista de preferencias de ALPN del cliente con su política de ALPN. Si el cliente admite un protocolo de la política de ALPN, el balanceador de carga establece la conexión en función de la lista de preferencias de la política de ALPN. De lo contrario, el balanceador de carga no utiliza ALPN.

Políticas de ALPN admitidas

Las siguientes son las políticas de ALPN admitidas:

HTTP1Only

Negocian solo HTTP/1.*. La lista de preferencias de ALPN es http/1.1, http/1.0.

HTTP2Only

Negocian solo HTTP/2. La lista de preferencias de ALPN es h2.

HTTP2Optional

Prefieren HTTP/1.* sobre HTTP/2 (que puede ser útil para pruebas HTTP/2). La lista de preferencias de ALPN es http/1.1, http/1.0, h2.

HTTP2Preferred

Prefieren HTTP/2 sobre HTTP/1.*. La lista de preferencias de ALPN es h2, http/1.1, http/1.0.

None

No negocian ALPN. Es la opción predeterminada.

Habilitar conexiones de ALPN

Puede habilitar conexiones de ALPN cuando cree o modifique un agente de escucha TLS. Para obtener más información, consulte Añadir un agente de escucha y Actualizar la política de ALPN.