Información general sobre el balanceador de carga de red del proxy externo

En este documento se presentan los conceptos que debes conocer para configurar un balanceador de carga de red de proxy externo. Trusted Cloud

El balanceador de carga de red del proxy externo es un balanceador de carga de proxy inverso que distribuye el tráfico TCP procedente de Internet a las instancias de máquinas virtuales (VM) de tuTrusted Cloud red de nube privada virtual (VPC). Cuando se usa un balanceador de carga de red de proxy externo, el tráfico TCP entrante se termina en el balanceador de carga. A continuación, una nueva conexión reenvía el tráfico al backend disponible más cercano.

Los balanceadores de carga de red con proxy externo te permiten usar una sola dirección IP para todos los usuarios del mundo. El balanceador de carga dirige automáticamente el tráfico a los back-ends que están más cerca del usuario.

Este balanceador de carga está disponible en el modo regional y, a partir de ahora, se denominará "balanceador de carga de red de proxy externo regional". El balanceador de carga se implementa como un servicio gestionado basado en el proxy Envoy de código abierto. El modo regional asegura que todos los clientes y backends estén en una región específica. Utilice este balanceador de carga si quiere servir contenido desde una sola geolocalización (por ejemplo, para cumplir normativas).

Arquitectura

En los siguientes diagramas se muestran los componentes de los balanceadores de carga de red de proxy externos.

Estos son los componentes de los balanceadores de carga de red de proxy externo.

Subred de solo proxy

La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de carga. La marca --purpose de esta subred de solo proxy se ha definido como REGIONAL_MANAGED_PROXY. Todos los balanceadores de carga regionales basados en Envoy de la misma región y red VPC comparten un grupo de proxies Envoy de la misma subred de solo proxy.

Las VMs o los endpoints de backend de todos los balanceadores de carga de una región y una red de VPC reciben conexiones de la subred de solo proxy.

Aspectos que debes tener en cuenta:

• Las subredes de solo proxy se usan únicamente para los proxies de Envoy, no para tus back-ends.
• La dirección IP del balanceador de carga no se encuentra en la subred de solo proxy. La dirección IP del balanceador de carga se define mediante su regla de reenvío gestionada externa.

Reglas de reenvío y direcciones IP

Las reglas de reenvío dirigen el tráfico a una configuración de balanceo de carga según la dirección IP, el puerto y el protocolo. Esta configuración consta de un proxy de destino y un servicio de backend.

Especificación de la dirección IP. Cada regla de reenvío hace referencia a una sola dirección IP que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática que puedas usar o dejar que Cloud Load Balancing te asigne una. Te recomendamos que reserves una dirección IP estática. De lo contrario, deberá actualizar su registro DNS con la dirección IP efímera recién asignada cada vez que elimine una regla de reenvío y cree una nueva.

Especificación de puerto. Las reglas de reenvío externas que se usan en la definición de este balanceador de carga pueden hacer referencia exactamente a un puerto del intervalo 1-65535. Si quieres admitir varios puertos consecutivos, debes configurar varias reglas de reenvío. Se pueden configurar varias reglas de reenvío con la misma dirección IP virtual y diferentes puertos. Por lo tanto, puedes proxyizar varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual de proxy TCP. Para obtener más información, consulta las especificaciones de los puertos para las reglas de reenvío.

Para admitir varios puertos consecutivos, debes configurar varias reglas de reenvío. Se pueden configurar varias reglas de reenvío con la misma dirección IP virtual y puertos diferentes. Por lo tanto, puedes usar un proxy para varias aplicaciones con puertos personalizados independientes en la misma dirección IP virtual de proxy TCP.

En la siguiente tabla se muestran los requisitos de las reglas de reenvío de los balanceadores de carga de red de proxy externos.

Modo del balanceador de carga	Nivel de servicio de red	Regla de reenvío, dirección IP y esquema de balanceo de carga	Enrutamiento de Internet al frontend del balanceador de carga
Balanceador de carga de red con proxy externo regional	Niveles Premium	Regla de reenvío externa regional Dirección IP externa regional Esquema de balanceo de carga: EXTERNAL_MANAGED	Solicitudes enrutadas a los proxies de Envoy de la misma región que el balanceador de carga.

Reglas de reenvío y redes de VPC

En esta sección se describe cómo se asocian las reglas de reenvío que usan los balanceadores de carga de aplicaciones externos con las redes de VPC.

Modo del balanceador de carga	Asociación de redes VPC
Balanceador de carga de red con proxy externo regional	La red VPC de la regla de reenvío es la red en la que se ha creado la subred de solo proxy. La red se especifica al crear la regla de reenvío.

Proxies de destino

Los balanceadores de carga de red de proxy externos finalizan las conexiones del cliente y crean nuevas conexiones con los back-ends. El proxy de destino dirige estas nuevas conexiones al servicio de backend.

De forma predeterminada, el proxy de destino no conserva la dirección IP del cliente original ni la información del puerto. Para conservar esta información, puedes habilitar el protocolo PROXY en el proxy de destino.

En la siguiente tabla se muestran los requisitos del proxy de destino de los balanceadores de carga de red de proxy externo.

Modo del balanceador de carga	Nivel de servicio de red	Proxy de destino
Balanceador de carga de red con proxy externo regional	Nivel Premium y Estándar	regionTargetTcpProxies

Servicios de backend

Los servicios de backend dirigen el tráfico entrante a uno o varios backends conectados. Cada backend se compone de un grupo de instancias o un grupo de puntos finales de red, así como de información sobre la capacidad de servicio del backend. La capacidad de servicio del backend puede basarse en la CPU o en las solicitudes por segundo (SPS).

Cada balanceador de carga tiene un único recurso de servicio de backend que especifica la comprobación del estado que se debe realizar en los backends disponibles.

Los cambios realizados en el servicio de backend no son instantáneos. Los cambios pueden tardar varios minutos en propagarse a los GFE. Para minimizar las interrupciones para tus usuarios, puedes habilitar el drenaje de conexiones en los servicios de backend. Estas interrupciones pueden producirse cuando se termina un backend, se elimina manualmente o se elimina mediante un escalador automático. Para obtener más información sobre cómo usar la purga de conexiones para minimizar las interrupciones del servicio, consulta Habilitar la purga de conexiones.

Para obtener más información sobre el recurso de servicio backend, consulta el artículo Descripción general de los servicios backend.

En la siguiente tabla se especifican los diferentes backends admitidos en el servicio de backend de los balanceadores de carga de red de proxy externo.

Modo del balanceador de carga	Backends admitidos en un servicio backend
	Grupos de instancias	NEGs por zonas	NEGs de Internet	NEGs sin servidor	NEGs híbridas	GKE
Balanceador de carga de red con proxy externo regional		Endpoints de tipo GCE_VM_IP_PORT	Solo NEGs regionales

Back-ends y redes de VPC

En el caso de los backends de los balanceadores de carga de red con proxy externos regionales, se aplican las siguientes condiciones:

• En el caso de los grupos de instancias, los NEGs zonales y los NEGs de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y en la misma región que el servicio de backend. Sin embargo, un balanceador de carga puede hacer referencia a un backend que utilice una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red VPC del balanceador de carga y la red VPC de backend se puede configurar mediante el peering de redes VPC, los túneles de Cloud VPN o las vinculaciones de VLAN de Cloud Interconnect.

  Definición de la red de backend

  • En el caso de los NEG zonales y los NEG híbridos, debes especificar explícitamente la red de VPC al crear el NEG.
  • En el caso de los grupos de instancias gestionados, la red VPC se define en la plantilla de instancia.
  • En los grupos de instancias no gestionados, la red VPC del grupo de instancias se configura para que coincida con la red VPC de la interfaz nic0 de la primera VM que se añade al grupo de instancias.

  Requisitos de red del backend

  La red de tu backend debe cumplir uno de los siguientes requisitos de red:

  • La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.

  • La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el emparejamiento entre redes de VPC. Debes configurar los intercambios de rutas de subred para permitir la comunicación entre la subred solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints de backend.

• En el resto de los tipos de backend, todos los backends deben estar ubicados en la misma red VPC y región.

Backends e interfaces de red

Si usas backends de grupos de instancias, los paquetes siempre se envían a nic0. Si quieres enviar paquetes a interfaces que no sean nic0 (ya sean NICs virtuales o interfaces de red dinámicas), usa back-ends de NEG.

Si usas backends de NEG por zonas, los paquetes se envían a la interfaz de red que represente el endpoint en el NEG. Los endpoints del NEG deben estar en la misma red VPC que la red VPC definida explícitamente del NEG.

Protocolo para comunicarse con los backends

Cuando configuras un servicio de backend para un balanceador de carga de red proxy externo, defines el protocolo que utiliza el servicio de backend para comunicarse con los backends. El balanceador de carga solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo. Los balanceadores de carga de red del proxy externo solo admiten TCP para comunicarse con los backends.

Reglas de cortafuegos

Se necesitan las siguientes reglas de cortafuegos:

• En el caso de los balanceadores de carga de red de proxy externos regionales, una regla de cortafuegos de entrada para permitir que el tráfico de la subred de solo proxy llegue a tus backends.

• Una regla de cortafuegos de entrada allow para permitir que el tráfico de los intervalos de comprobación del estado llegue a tus backends. Para obtener más información sobre las sondas de comprobación del estado y por qué es necesario permitir el tráfico procedente de ellas, consulta Intervalos de IP de las sondas y reglas de cortafuegos.

Las reglas de cortafuegos se implementan a nivel de instancia de VM, no a nivel de proxies de GFE. No puedes usar reglas de cortafuegos para evitar que el tráfico llegue al balanceador de carga.

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

• Permite el tráfico al puerto de destino para la comprobación del estado de cada servicio de backend.
• En el caso de los backends de grupos de instancias, determine los puertos que se van a configurar mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados a ese puerto con nombre en cada grupo de instancias. Los números de puerto pueden variar entre los grupos de instancias asignados al mismo servicio de backend.
• En el caso de los backends de NEG zonales GCE_VM_IP_PORT NEG, permite el tráfico a los números de puerto de los endpoints.

Direcciones IP de origen

La dirección IP de origen de los paquetes, tal como la ven los backends, no es laTrusted Cloud dirección IP externa del balanceador de carga. En otras palabras, hay dos conexiones TCP.

En el caso de los balanceadores de carga de red de proxy externo regionales:

• Conexión 1, del cliente original al balanceador de carga (subred de solo proxy):

  • Dirección IP de origen: el cliente original (o la dirección IP externa si el cliente está detrás de una pasarela NAT o un proxy de reenvío).
  • Dirección IP de destino: la dirección IP de tu balanceador de carga.

• Conexión 2, del balanceador de carga (subred de solo proxy) a la máquina virtual o el endpoint de backend:

  • Dirección IP de origen: una dirección IP de la subred solo proxy que comparten todos los balanceadores de carga basados en Envoy implementados en la misma región y red que el balanceador de carga.

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

Puertos abiertos

Los balanceadores de carga de red de proxy externo son balanceadores de carga de proxy inverso. El balanceador de carga finaliza las conexiones entrantes y, a continuación, abre nuevas conexiones desde el balanceador de carga a los back-ends. Estos balanceadores de carga 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. Cuando ejecutas un análisis de puertos, es posible que veas otros puertos abiertos de otros servicios de Google que se ejecutan en GFE.

No es útil realizar un análisis de puertos en la dirección IP de un balanceador de carga basado en GFE desde el punto de vista de la auditoría por los siguientes motivos:

• En un análisis de puertos (por ejemplo, con nmap), normalmente no se espera ningún paquete de respuesta o un paquete TCP RST al realizar un sondeo TCP SYN. Los GFE solo envían paquetes SYN-ACK en respuesta a las sondas SYN de los puertos en los que haya configurado una regla de reenvío. Los GFE solo envían paquetes a tus back-ends en respuesta a los paquetes enviados a la dirección IP de tu balanceador de carga y al puerto de destino configurado en su regla de reenvío. Los paquetes que se envían a una dirección IP o un puerto diferentes no se envían a tus back-ends.

  Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Cloud Armor Standard, las GFEs ofrecen protección continua frente a ataques DDoS volumétricos y basados en protocolos, así como frente a inundaciones SYN. Esta protección está disponible aunque no hayas configurado Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te registras en Managed Protection Plus.

• Los paquetes enviados a la dirección IP de tu balanceador de carga pueden responderse con cualquier GFE de la flota de Google. Sin embargo, al analizar una combinación de dirección IP y puerto de destino de un balanceador de carga, solo se interroga a un GFE por conexión TCP. La dirección IP de tu balanceador de carga no se asigna a un solo dispositivo o sistema. Por lo tanto, al analizar la dirección IP de un balanceador de carga basado en GFE, no se analizan todos los GFEs de la flota de Google.

Teniendo esto en cuenta, a continuación se indican algunas formas más eficaces de auditar la seguridad de tus instancias de backend:

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

• Un auditor de seguridad debe inspeccionar la configuración de las reglas de cortafuegos aplicables a las VMs backend. Las reglas de cortafuegos que definas bloquearán el tráfico de los GFEs a las VMs de backend, pero no bloquearán el tráfico entrante a los GFEs. Para consultar las prácticas recomendadas, ve a la sección Reglas de cortafuegos.

Arquitectura de VPC compartida

Los balanceadores de carga de red de proxy externo regionales admiten implementaciones que usan redes de VPC compartidas. Las VPC compartidas te permiten mantener una separación clara de las responsabilidades entre los administradores de redes y los desarrolladores de servicios. Tus equipos de desarrollo pueden centrarse en crear servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de carga. Si no conoces la VPC compartida, consulta la documentación general sobre la VPC compartida.

Dirección IP	Regla de reenvío	Proxy de destino	Componentes de backend
Se debe definir una dirección IP externa en el mismo proyecto que el balanceador de carga.	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 debe definirse en el mismo proyecto que las instancias de backend.	En el caso de los balanceadores de carga de red de proxy externo regionales, las VMs de backend suelen estar ubicadas en un proyecto de servicio. En ese proyecto de servicio se deben definir un servicio backend regional y una comprobación del estado.

Distribución del tráfico

Cuando añades un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo de carga, que define un método para medir la carga del backend y la capacidad objetivo.

En el caso de los balanceadores de carga de red de proxy externo, el modo de balanceo puede ser CONNECTION o UTILIZATION:

• Si el modo de balanceo de carga es CONNECTION, la carga se distribuye en función del número total de conexiones que puede gestionar el backend.
• Si el modo de balanceo de carga es UTILIZATION, la carga se distribuye en función del uso de las instancias de un grupo de instancias. Este modo de balanceo solo se aplica a los backends de grupos de instancias de VM.

La distribución del tráfico entre los backends se determina mediante el modo de balanceo del balanceador de carga.

Balanceador de carga de red con proxy externo regional

En el caso de los balanceadores de carga de red de proxy externos regionales, la distribución del tráfico se basa en el modo de balanceo de carga y en la política de localidad del balanceo de carga.

El modo de balanceo determina el peso y la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). La política de localidad del balanceo de carga (LocalityLbPolicy) determina cómo se balancea la carga de los backends del grupo.

Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según su modo de balanceo. Una vez que se ha seleccionado un backend, el tráfico se distribuye entre las instancias o los endpoints de ese grupo de backend según la política de localidad del balanceo de carga.

Para obtener más información, consulta las siguientes secciones:

• Modos de balanceo
• Política de localidad de balanceo de carga (documentación de la API de servicio backend regional)

Afinidad de sesión

La afinidad de sesión te permite configurar el servicio de backend del balanceador de carga para que envíe todas las solicitudes del mismo cliente al mismo backend, siempre que el backend esté en buen estado y tenga capacidad.

Los balanceadores de carga de red de proxy externos ofrecen los siguientes tipos de afinidad de sesión:

• Ninguno

  Si el ajuste de afinidad de sesión es NONE, no significa que no haya afinidad de sesión. Esto significa que no se ha configurado explícitamente ninguna opción de afinidad de sesión.

  El hashing siempre se realiza para seleccionar un backend. Si la afinidad de sesión es NONE, el balanceador de carga usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas está formado por la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino.

  El valor predeterminado de la afinidad de sesión es NONE.

• Afinidad de IP de cliente

  La afinidad de sesión por IP de cliente (CLIENT_IP) es un hash de dos tuplas creado a partir de las direcciones IP de origen y de destino del paquete. La afinidad de IP de cliente reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend, siempre que este tenga capacidad y se mantenga en buen estado.

  Cuando uses la afinidad de IP de cliente, ten en cuenta lo siguiente:

  • La dirección IP de destino del paquete solo es la misma que la dirección IP de la regla de reenvío del balanceador de carga si el paquete se envía directamente al balanceador de carga.
  • Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si el paquete se procesa mediante un sistema NAT o proxy intermedio antes de enviarse a un balanceador de carga. Trusted Cloud En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs backend pueden recibir más conexiones o solicitudes que otras.

Tenga en cuenta lo siguiente al configurar la afinidad de sesión:

• No confíes en la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión puede dejar de funcionar cuando cambia el número de back-ends activos y correctos. Para obtener más información, consulta Pérdida de la afinidad de sesión.

• Los valores predeterminados de las marcas --session-affinity y --subsetting-policy son NONE, y solo se puede asignar un valor diferente a una de ellas a la vez.

Pérdida de la afinidad de sesión

Todas las opciones de afinidad de sesión requieren lo siguiente:

• La instancia o el endpoint de backend seleccionados deben seguir configurados como backend. La afinidad de sesión puede dejar de funcionar cuando se produce uno de los siguientes eventos:
  • Se elimina la instancia seleccionada de su grupo de instancias.
  • La función de autoescalado o de reparación automática de grupos de instancias gestionados elimina la instancia seleccionada de su grupo de instancias gestionado.
  • Eliminas el endpoint seleccionado de su NEG.
  • Elimina del servicio de backend el grupo de instancias o el NEG que contenga la instancia o el endpoint seleccionados.
• La instancia o el endpoint de backend seleccionados deben mantener su buen estado. La afinidad de sesión puede dejar de funcionar cuando la instancia o el endpoint seleccionados no superan las comprobaciones de estado.
• En el caso de los balanceadores de carga de red proxy externos globales y los balanceadores de carga de red proxy clásicos, la afinidad de sesión puede dejar de funcionar si se usa un Google Front End (GFE) de primera capa diferente para las solicitudes o conexiones posteriores al cambio en la ruta. Es posible que se seleccione otra GFE de primera capa si la ruta de acceso de un cliente de Internet a Google cambia entre solicitudes o conexiones.

Todas las opciones de afinidad de sesión tienen los siguientes requisitos adicionales:

• El grupo de instancias o NEG que contiene la instancia o el endpoint seleccionados no debe estar lleno, tal como se define en su capacidad objetivo. En el caso de los grupos de instancias gestionados regionales, el componente de zona del grupo de instancias que contiene la instancia seleccionada no debe estar lleno. La afinidad de sesión puede dejar de funcionar cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEGs no. Como la capacidad puede cambiar de forma impredecible al usar el modo de balanceo UTILIZATION, debes usar el modo de balanceo RATE o CONNECTION para minimizar las situaciones en las que la afinidad de sesión pueda fallar.

• El número total de instancias o endpoints de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend configurados y se puede interrumpir la afinidad de sesión:

  • Añadir nuevas instancias o endpoints:

    • Añade instancias a un grupo de instancias que ya tengas en el servicio de backend.
    • El autoescalado de grupos de instancias gestionados añade instancias a un grupo de instancias gestionado en el servicio de backend.
    • Añade puntos finales a un NEG que ya esté en el servicio backend.
    • Añade grupos de instancias o NEGs no vacíos al servicio de backend.

  • Para quitar cualquier instancia o endpoint, no solo la instancia o el endpoint seleccionados:

    • Elimina cualquier instancia de un backend de grupo de instancias.
    • El autoescalado o la reparación automática de grupos de instancias gestionados elimina cualquier instancia de un backend de grupo de instancias gestionado.
    • Puedes quitar cualquier endpoint de un backend de NEG.
    • Elimina cualquier grupo de instancias de backend o NEG no vacío del servicio de backend.

• El número total de instancias o endpoints de backend en buen estado debe mantenerse constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend correctos y se puede interrumpir la afinidad de sesión:

  • Cualquier instancia o endpoint supera su comprobación de estado y pasa de estar en mal estado a estar en buen estado.
  • Si alguna instancia o endpoint no supera la comprobación del estado, pasa de estar en buen estado a no estarlo o a agotar el tiempo de espera.

Conmutación por error

La conmutación por error de los balanceadores de carga de red de proxy externo funciona de la siguiente manera:

• Si un backend deja de estar en buen estado, el tráfico se redirige automáticamente a los backends en buen estado de la misma región.

• Si todos los backends están en mal estado, el balanceador de carga rechaza el tráfico.

Balanceo de carga para aplicaciones de GKE

Si creas aplicaciones en Google Kubernetes Engine, puedes usar NEGs independientes para balancear la carga del tráfico directamente a los contenedores. Con los NEGs independientes, eres responsable de crear el objeto Service que crea el NEG y, a continuación, de asociar el NEG al servicio de backend para que el balanceador de carga pueda conectarse a los pods.

Para consultar la documentación relacionada, consulta Balanceo de carga nativo de contenedores mediante NEGs de zona independientes.

Limitaciones

• No puedes crear un balanceador de carga de red proxy externo regional en el nivel Premium mediante laTrusted Cloud consola .En su lugar, usa la interfaz de línea de comandos de gcloud o la API.

• Trusted Cloud no ofrece ninguna garantía sobre la duración de las conexiones TCP cuando se usan balanceadores de carga de red de proxy externos. Los clientes deben ser resistentes a las conexiones interrumpidas, tanto por problemas generales de Internet como por los reinicios programados periódicamente de los proxies que gestionan las conexiones.

Siguientes pasos

• Configura un balanceador de carga de red de proxy externo regional (proxy TCP).
• Registro y monitorización de balanceadores de carga de red de proxy.