Descripción general del balanceo de cargas de proxy TCP externo

El Balanceo de cargas de proxy TCP externo es un balanceador de cargas del proxy inverso que distribuye el tráfico TCP proveniente de Internet a instancias de máquinas virtuales (VM) en tu red de VPC de Google Cloud. Cuando se usa el balanceo de cargas de proxy TCP externo, el tráfico que llega a través de una conexión TCP se finaliza en la capa de balanceo de cargas y, luego, se reenvía al backend disponible más cercano mediante TCP o SSL.

El balanceo de cargas de proxy TCP externo te permite usar una sola dirección IP para todos los usuarios en todo el mundo. El balanceador de cargas de proxy TCP externo enruta el tráfico de manera automática a los backends más cercanos al usuario.

Con el nivel Premium, el balanceo de cargas del proxy TCP externo se puede configurar como un servicio de balanceo de cargas global. Con el nivel Estándar, el balanceador de cargas del proxy TCP externo administra el balanceo de cargas de forma regional.

En este ejemplo, las conexiones al tráfico de los usuarios de Seúl y Boston se finalizan en la capa de balanceo de cargas. Estas conexiones están etiquetadas como 1a2a. Se establecen conexiones independientes desde el balanceador de cargas hasta las instancias de backend seleccionadas. Estas conexiones están etiquetadas como 1b2b.

Cloud Load Balancing con finalización TCP (haz clic para ampliar)
Cloud Load Balancing con finalización TCP (haz clic para ampliar)

El balanceo de cargas de proxy TCP externo se diseñó para el tráfico de TCP en puertos conocidos específicos, como el puerto 25 del protocolo para transferencia simple de correo (SMTP). Para obtener más información, consulta Especificaciones de puertos. Para el tráfico de clientes encriptado en estos mismos puertos, usa el balanceo de cargas de proxy SSL externo.

El balanceo de cargas de proxy TCP externo no es compatible con el puerto TCP 80 o el puerto 8080. Para el tráfico HTTP(S), usa el balanceo de cargas HTTP(S) externo.

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Ventajas

Algunos de los beneficios del balanceador de cargas del proxy TCP externo incluyen los siguientes:

  • Terminación de IPv6. El balanceo de cargas del proxy TCP externo admite direcciones IPv6 e IPv4 para el tráfico del cliente. Las solicitudes de cliente de IPv6 se finalizan en la capa de balanceo de cargas y, luego, se envían mediante proxies de IPv4 a tus backends.
  • Enrutamiento inteligente. El balanceador de cargas puede enrutar solicitudes a ubicaciones de backend en las que haya capacidad. Por el contrario, un balanceador de cargas L3/L4 debe dirigirse a backends regionales sin considerar la capacidad. El uso del enrutamiento inteligente permite el aprovisionamiento en N+1 o N+2 en lugar de x*N.
  • Parches de seguridad. Si surgen vulnerabilidades en la pila TCP, Cloud Load Balancing aplica parches al balanceador de cargas de manera automática para proteger tus backends.
  • Compatibilidad con los siguientes puertos TCP conocidos. 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 y 9300.
  • Integración con Google Cloud Armor. Puedes usar las políticas de seguridad de Google Cloud Armor para proteger tu infraestructura contra ataques de denegación de servicio distribuido (DSD) y otros ataques dirigidos.

Arquitectura

Los siguientes son componentes de balanceadores de cargas de proxy TCP externos.

Reglas de reenvío y direcciones IP

Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino y un servicio de backend.

Cada regla de reenvío proporciona una sola dirección IP que puedes usar en los registros DNS de tu aplicación. No se requiere balanceo de cargas basado en DNS. Puedes reservar una dirección IP estática para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática; de lo contrario, deberás actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.

Las reglas de reenvío externas que se usan en la definición de un balanceador de cargas del proxy TCP externo pueden hacer referencia de forma exacta a uno de los puertos enumerados en: Especificaciones de puertos para reglas de reenvío.

Proxies de destino

El balanceo de cargas de proxy TCP externo finaliza las conexiones TCP del cliente y crea conexiones nuevas con los backends. El proxy de destino enruta estas conexiones nuevas al servicio de backend.

De forma predeterminada, la dirección IP de cliente original y la información del puerto no se conservan. Puedes conservar esta información mediante el protocolo PROXY.

Servicios de backend

Los servicios de backend dirigen el tráfico entrante a uno o más backends conectados. Cada backend está compuesto por un grupo de instancias o un grupo de extremos de red, además de información sobre la capacidad de entrega del backend. La capacidad de entrega del backend se puede basar en CPU o en solicitudes por segundo (RPS).

Cada balanceador de cargas del proxy TCP externo tiene un solo recurso de servicio de backend. Los cambios en el servicio de backend no son instantáneos. Los cambios pueden llevar varios minutos en propagarse a Google Front End (GFE).

Cada servicio de backend especifica las verificaciones de estado que se realizarán en los backends disponibles.

Para garantizar interrupciones mínimas a tus usuarios, puedes habilitar el vaciado de conexiones en los servicios de backend. Estas interrupciones pueden ocurrir cuando un backend se finaliza, se quita de forma manual, o lo quita un escalador automático. Si quieres obtener más información sobre el uso del vaciado de conexiones para minimizar las interrupciones del servicio, consulta Habilita el vaciado de conexiones.

Backends y redes de VPC

Todos los backends deben estar ubicados en el mismo proyecto, pero se pueden ubicar en redes de VPC diferentes. No es necesario que las diferentes redes de VPC estén conectadas mediante el intercambio de tráfico entre redes de VPC, ya que los sistemas proxy de GFE se comunican directamente con los backends en sus respectivas redes de VPC.

Protocolo para comunicarse con los backends

Cuando configuras un servicio de backend para un balanceador de cargas de proxy TCP externo, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos. Puedes elegir SSL o TCP. El balanceador de cargas solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo.

Reglas de firewall

El balanceo de cargas de proxy TCP externo y el balanceo de cargas de proxy SSL externo requieren las siguientes reglas de firewall:

  • Una regla de firewall de permiso de entrada que permita que el tráfico de Google Front End (GFE) llegue a tus backends.

  • Una regla de firewall de permiso de entrada que permita que el tráfico de los rangos de sondeo de verificación de estado llegue a tus backends. Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico, consulta Rangos de IP del sondeo y reglas de firewall.

Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de GFE. No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas.

Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:

  • Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.

  • Para los backends de grupos de instancias: determina los puertos que se configurarán mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.

  • Para los backends de NEG GCE_VM_IP_PORT: permite el tráfico a los números de puerto de los extremos.

Los rangos de direcciones IP de origen necesarios para ser permitidos son los siguientes:

  • 130.211.0.0/22
  • 35.191.0.0/16

Estos rangos se aplican a las verificaciones de estado y a las solicitudes del GFE.

Direcciones IP de origen

La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos conexiones TCP.

  • Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Conexión 2, desde el balanceador de cargas (GFE) hasta el extremo o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de los rangos especificados en Reglas de firewall.

    • Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.

Puertos abiertos

Los balanceadores de cargas de proxy TCP externos son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre conexiones nuevas del balanceador de cargas a los backends. Estos balanceadores de cargas se implementan mediante proxies de Google Front End (GFE) en todo el mundo.

Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Para ver una lista de algunos de los puertos que pueden estar abiertos en los GFE, consulta Regla de reenvío: especificaciones de puertos. Es posible que haya otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.

Ejecutar un análisis de puerto en la dirección IP de un balanceador de cargas basado en GFE no es útil desde la perspectiva de la auditoría por los siguientes motivos:

  • Por lo general, un análisis de puerto (por ejemplo, con nmap) no espera ningún paquete de respuesta o un paquete RST de TCP cuando realiza sondeos de TCP SYN. Los GFE enviarán paquetes SYN-ACK en respuesta a los sondeos de SYN de una variedad de puertos si el balanceador de cargas usa una dirección IP del nivel Premium. Sin embargo, los GFE solo envían paquetes a tus backends en respuesta a los paquetes enviados a la dirección IP del balanceador de cargas y al puerto de destino configurado en su regla de reenvío. Los paquetes enviados a direcciones IP de balanceador de cargas diferentes o la dirección IP del balanceador de cargas en un puerto que no se configuró en la regla de reenvío no dan como resultado que los paquetes se envíen a los backends del balanceador de cargas.

  • Cualquier GFE en la flota de Google puede responder a los paquetes enviados a la dirección IP de tu balanceador de cargas. Sin embargo, el análisis de una combinación de direcciones IP del balanceador de cargas y del puerto de destino solo intercepta un solo GFE por conexión TCP. La dirección IP de tu balanceador de cargas no se asigna a un solo dispositivo o sistema. Por lo tanto, analizar la dirección IP de un balanceador de cargas basado en GFE no analiza todos los GFE de la flota de Google.

Con esto en mente, las siguientes son algunas formas más efectivas de auditar la seguridad de tus instancias de backend:

  • Un auditor de seguridad debe inspeccionar la configuración de reglas de reenvío para la configuración del balanceador de cargas. Las reglas de reenvío definen el puerto de destino para el que tu balanceador de cargas acepta paquetes y los reenvía a los backends. Para los balanceadores de cargas basados en GFE, cada regla de reenvío externo solo puede hacer referencia a un solo puerto TCP de destino.

  • Un auditor de seguridad debe inspeccionar la configuración de la regla de firewall aplicable a las VM de backend. Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las VM de backend, pero no bloquean el tráfico entrante a los GFE. Para conocer las prácticas recomendadas, consulta la sección de reglas de firewall.

Arquitectura de VPC compartida

El balanceo de cargas de proxy TCP externo admite redes que usan VPC compartida. La VPC compartida te permite mantener una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios. Tus equipos de desarrollo pueden enfocarse en compilar servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de cargas. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.

Dirección IP Regla de reenvío Proxy de destino y mapa de URL Componentes de backend
Se debe definir una dirección IP externa en el mismo proyecto que el balanceador de cargas. La regla de reenvío externa debe definirse en el mismo proyecto que las instancias de backend (el proyecto de servicio). El proxy TCP de destino y el mapa de URL deben definirse en el mismo proyecto que las instancias de backend. Se debe definir un servicio de backend global en el mismo proyecto que las instancias de backend. Estas instancias deben estar en grupos de instancias vinculadas al servicio de backend como backends. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Distribución de tráfico

La forma en que un balanceador de cargas de proxy SSL distribuye el tráfico a sus backends depende del modo de balanceo y el método de hash seleccionado para elegir un backend (afinidad de sesión).

Cómo se distribuyen las conexiones

El balanceo de cargas de proxy TCP externo se puede configurar como un servicio de balanceo de cargas global con el nivel Premium y como un servicio regional en el nivel Estándar.

Para el nivel Premium:

  • Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
  • Si configuras un servicio de backend con backends en varias regiones, Google Front End (GFE) intenta dirigir las solicitudes a grupos de instancias de backend o NEG en buen estado en la región más cercana al usuario. Los detalles del proceso se detallan en esta página.

Para el nivel Estándar:

  • Google hace pública la dirección IP del balanceador de cargas desde los puntos de presencia asociados con la región de la regla de reenvío. El balanceador de cargas usa una dirección IP externa regional.

  • Puedes configurar backends en la misma región que la regla de reenvío. El proceso documentado aquí todavía es válido, pero el balanceador de cargas solo dirige las solicitudes a backends en buen estado en esa región.

Proceso de distribución de solicitudes:

  1. Los routers perimetrales anuncian la dirección IP externa de la regla de reenvío en los límites de la red de Google. Cada anuncio enumera un salto siguiente a un sistema de balanceo de cargas de capa 3/4 (Maglev).
  2. Los sistemas Maglev enrutan el tráfico a Google Front End (GFE) de primera capa. El GFE de la primera capa finaliza TLS si es necesario y, luego, enruta el tráfico a los GFE de la segunda capa de acuerdo con este proceso:
    1. Si un servicio de backend usa un grupo de instancias o backends de NEG GCE_VM_IP_PORT, los primeros GFE de capa prefieren los GFE de segunda capa que se encuentran en la región que contiene el grupo de instancias o NEG o cerca de ella.
    2. Para los buckets de backend y los servicios de backend con NEG híbridos, NEG sin servidores y de Internet, los GFE de la primera capa eligen GFE de segunda capa en un subconjunto de regiones, de modo que el tiempo de ida y vuelta entre los dos GFE es minimizado.

      La preferencia de GFE de segunda capa no es una garantía y puede cambiar de manera dinámica según las condiciones y el mantenimiento de la red de Google.

      Los GFE de segunda capa conocen el estado de la verificación de estado y el uso real de la capacidad del backend.

  3. La segunda capa de GFE dirige las solicitudes a backends en zonas dentro de su región.
  4. En el nivel Premium, a veces, los GFE de segunda capa envían solicitudes a backends en zonas de diferentes regiones. Este comportamiento se llama efecto secundario.
  5. El efecto secundario se rige por dos principios:

    • La propagación se puede realizar cuando todos los backends conocidos por un GFE de segunda capa están al máximo de capacidad o están en mal estado.
    • La segunda capa de GFE tiene información para los backends en buen estado y disponibles en zonas de otra región.

    Los GFE de segunda capa suelen configurarse para entregar un subconjunto de ubicaciones de backend.

    El comportamiento del efecto secundario no agota todas las zonas posibles de Google Cloud. Si necesitas dirigir el tráfico fuera de los backends en una zona en particular o en una región completa, debes configurar el escalador de capacidad en cero. Configurar backends para que fallen las verificaciones de estado no garantiza que el GFE de segunda capa se transmita a backends en zonas de otra región.

  6. Cuando se distribuyen solicitudes a backends, los GFE operan a nivel zonal.

Modo de balanceo

Cuando agregas un backend al servicio de backend, debes establecer un modo de balanceo de cargas.

Para el balanceo de cargas de proxy TCP externo, el modo de balanceo puede ser CONNECTION o UTILIZATION.

Si el modo de balanceo de cargas es CONNECTION, la carga se distribuye según la cantidad de conexiones simultáneas que pueda controlar el backend. También debes especificar con exactitud uno de los siguientes parámetros: maxConnections (excepto para los grupos de instancias administrados regionales), maxConnectionsPerInstance o maxConnectionsPerEndpoint.

Si el modo de balanceo de cargas es UTILIZATION, la carga se distribuye según el uso de instancias en un grupo de instancias.

Para obtener información sobre la comparación de los tipos de balanceadores de cargas y los modos de balanceo admitidos, consulta Métodos de balanceo de cargas.

Afinidad de sesión

La afinidad de sesión envía todas las solicitudes del mismo cliente al mismo backend si este se encuentra en buen estado y tiene capacidad.

El balanceo de cargas de proxy TCP externo ofrece afinidad de IP de cliente, que reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend.

Conmutación por error

Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado dentro de la misma región. Si todos los backends de una región están en mal estado, el tráfico se distribuirá a los backends en buen estado en otras regiones (solo nivel Premium). Si todos los backends están en mal estado, el balanceador de cargas descartará el tráfico.

Balanceo de cargas para aplicaciones de GKE

Si compilas aplicaciones en Google Kubernetes Engine, puedes usar NEG independientes para balancear las cargas del tráfico directamente a los contenedores. Con los NEG independientes, eres responsable de crear el objeto Service que crea el NEG y, luego, asociar el NEG con el servicio de backend para que el balanceador de cargas pueda se conectan a los Pods.

Documentación de GKE relacionada:

¿Qué sigue?