Descripción general del balanceo de cargas del proxy SSL

Cuando usas del balanceo de cargas del proxy SSL de Google Cloud para el tráfico SSL, puedes finalizar las conexiones SSL (TLS) de los usuarios en la capa de balanceo de cargas y balancear las conexiones en las instancias de backend mediante los protocolos SSL (recomendados) o TCP. Para conocer los tipos de backends compatibles, consulta Backends.

El balanceo de cargas del proxy SSL está diseñado para el tráfico que no es HTTP(S). En el caso del tráfico HTTP(S), te recomendamos que uses el Balanceo de cargas de HTTP(S).

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

SSL Proxy Load Balancing admite direcciones IPv4 e IPv6 para el tráfico de clientes. Las solicitudes de clientes de IPv6 finalizan en la capa de balanceo de cargas y, luego, se dirigen mediante proxies IPv4 a tus VM.

El balanceo de cargas del proxy SSL es un servicio de balanceo de cargas que se puede implementar a nivel mundial. Puedes implementar los backends en varias regiones para que el balanceador de cargas dirija el tráfico automáticamente a la región más cercana que tenga capacidad. Si la región más cercana ya alcanzó su capacidad máxima, el balanceador de cargas dirige automáticamente las conexiones nuevas a otra región con capacidad disponible. Las conexiones de los usuarios existentes permanecen en la región actual.

El balanceo de cargas global requiere que uses el nivel Premium de los niveles de servicio de red, que es el nivel predeterminado. De lo contrario, el balanceo de cargas se maneja a nivel regional.

Beneficios

A continuación, se presentan algunos beneficios del uso del balanceo de cargas del proxy SSL:

  • 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.

  • Mejor uso de backends: El procesamiento SSL puede consumir una gran cantidad de CPU si los algoritmos de cifrados que se usan no son eficientes en cuanto al uso de ese recurso. Para maximizar el rendimiento de CPU, usa certificados SSL ECDSA y TLS 1.2, y opta por el conjunto de algoritmos de cifrado ECDHE-ECDSA-AES128-GCM-SHA256 para SSL entre el balanceador de cargas y las instancias de backend.

  • Administración de certificados: Los certificados SSL orientados al cliente pueden ser certificados que obtienes y administras tú mismo (certificados autoadministrados) o certificados que Google obtiene y administra por ti (certificados administrados por Google). Cada uno de los certificados SSL administrados por Google admite hasta 100 dominios. Se admiten varios dominios para los certificados administrados por Google. Solo debes aprovisionar certificados en el balanceador de cargas. En las VM, puedes simplificar la administración mediante el uso de certificados autofirmados.

  • Parches de seguridad: Si surgen vulnerabilidades en la pila SSL o TCP, se aplican parches en el balanceador de cargas de forma automática para proteger las VM.

  • Compatibilidad con el balanceo de cargas del proxy de SSL para los siguientes puertos: 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. Cuando usas certificados SSL administrados por Google con el balanceo de cargas del proxy SSL, el puerto de frontend que se usa para el tráfico debe ser 443 a fin de que puedan aprovisionarse y renovarse los certificados SSL administrados por Google.

  • Políticas de SSL. Las políticas de SSL te permiten controlar las características de SSL que el balanceador de cargas del proxy SSL negocia con los clientes.

Notas

  • Si bien enviar tráfico mediante TCP no encriptado entre la capa de balanceo de cargas y las instancias de backend te permite descargar el procesamiento de SSL de tus backends, también implica una reducción de la seguridad. Por lo tanto, no lo recomendamos.

  • El balanceo de cargas del proxy SSL puede manejar HTTPS, pero no se recomienda hacerlo. Es mejor que uses el balanceo de cargas de HTTPS para ese tipo de tráfico. Para obtener más información, consulta las Preguntas frecuentes.

  • Puedes crear políticas de SSL con la herramienta de línea de comandos de gcloud.

  • Los balanceadores de cargas del proxy SSL no admiten la autenticación basada en certificados de cliente, también denominada autenticación TLS mutua.

  • Los balanceadores de cargas del proxy SSL tienen un recurso de servicio de backend único. Los cambios en el servicio de backend no son instantáneos. Los cambios pueden llevar varios minutos en propagarse a Google Front End (GFE).

En las siguientes secciones, se describe el funcionamiento de SSL Proxy Load Balancing.

Casos de uso

Mediante el uso del balanceo de cargas del proxy SSL, las conexiones SSL finalizan en la capa de balanceo de cargas y, luego, se dirigen mediante proxies al backend disponible más cercano.

En este ejemplo, el tráfico de usuarios de Iowa y Boston finaliza en la capa del balanceo de cargas y se establece una conexión independiente para el backend seleccionado.

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

Comportamiento del balanceador de cargas en los niveles de servicio de red

El balanceo de cargas del proxy SSL es un servicio global con nivel Premium. Solo puedes tener un servicio de backend, y este puede tener backends en varias regiones. El tráfico se asigna a los backends como se indica a continuación:

  1. Cuando un cliente envía una solicitud, el servicio de balanceo de cargas determina el origen aproximado de la solicitud a partir de la dirección IP de origen.
  2. El servicio de balanceo de cargas determina las ubicaciones de los backends que son propiedad del servicio de backend, su capacidad general y su uso actual general.
  3. Si las instancias de backend más cercanas al usuario tienen capacidad disponible, la solicitud se reenvía al conjunto de backends más cercano.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todas las instancias de backend disponibles en esa región. Sin embargo, en cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias de backend en buen estado con capacidad disponible en una región determinada, el balanceador de cargas envía la solicitud a la siguiente región más cercana con capacidad disponible.

En el nivel Estándar, el balanceo de cargas del proxy TCP es un servicio regional. Todos sus backends deben estar ubicados en la región que usa la dirección IP externa y la regla de reenvío del balanceador de cargas.

Direcciones IP de origen

Las direcciones IP de origen de los paquetes, vistas por cada contenedor o instancia de máquina virtual (VM) de backend, son una dirección IP de estos rangos:

  • 35.191.0.0/16
  • 130.211.0.0/22

La dirección IP de origen para el tráfico real del balanceo de cargas es la misma que la de los rangos de IP del sondeo de verificación de estado.

Las direcciones IP de origen del tráfico, vistas por los backends, no son la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos sesiones HTTP, SSL o 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).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Sesión 2, que abarca desde el balanceador de cargas (GFE) hasta el contenedor o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de estos rangos: 35.191.0.0/16 o 130.211.0.0/22.

      No puedes predecir la dirección real de origen.

    • Dirección IP de destino: Es la dirección IP interna del contenedor o la VM de backend en la red de nube privada virtual (VPC).

Control geográfico sobre la ubicación en la que se finaliza TLS

El balanceador de cargas del proxy SSL finaliza TLS en ubicaciones distribuidas de manera global a fin de minimizar la latencia entre los clientes y el balanceador de cargas. Si necesitas control geográfico sobre la ubicación donde finaliza TLS, usa el balanceo de cargas de red y finaliza TLS en backends ubicados en regiones adecuadas para tus necesidades.

Puertos abiertos

Los balanceadores de cargas de proxy SSL son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre nuevas conexiones entre el balanceador de cargas y los backends. Google Front End (GFE) proporciona la función de proxy inverso.

Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las instancias de backend, pero no bloquean el tráfico entrante a los GFE.

Los balanceadores de cargas del proxy SSL tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Si ejecutas un escaneo de puertos o de seguridad sobre la dirección IP externa de tu balanceador de cargas, parecerá que hay puertos adicionales abiertos.

Esto no afecta a los balanceadores de cargas de proxy SSL. Las reglas de reenvío externas que se usan en la definición de un balanceador de cargas SSL solo pueden hacer referencia a los puertos TCP 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. El tráfico con un puerto de destino de TCP diferente no se reenvía al backend del balanceador de cargas.

Reglas de firewall

Las instancias de backend deben permitir conexiones desde los rangos de verificación de estado o GFE del balanceador de cargas. Esto significa que debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus instancias o extremos de backend. Estos rangos de direcciones IP se usan como fuentes para los paquetes de verificación de estado y para todos los paquetes con balanceo de cargas que se envían a tus backends.

Los puertos que configuras para esta regla de firewall deben permitir el tráfico a instancias o a extremos de backend:

  • Debes permitir los puertos que usa cada regla de reenvío
  • Debes permitir los puertos que usa cada verificación de estado que se configuró para cada servicio de backend.

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

Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de 130.211.0.0/2235.191.0.0/16, consulta Rangos de IP de sondeo y reglas de firewall.

Modo de balanceo

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

Para el balanceo de cargas de proxy SSL, el modo de balanceo puede ser connection o backend 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 exactamente uno de los siguientes parámetros: maxConnections (excepto para los grupos de instancias regionales administrados), maxConnectionsPerInstance o maxConnectionsPerEndpoint.

Si el modo de balanceo de cargas es backend utilization, la carga se distribuye según la utilización de instancias en un grupo de instancias.

Para obtener información sobre cómo comparar los tipos de balanceador de cargas y los modos de balanceo admitidos, consulta Métodos de balanceo de cargas.

Certificado SSL

Debes instalar uno o más certificados SSL en el proxy SSL de destino.

Los proxies SSL de destino utilizan estos certificados para proteger las comunicaciones entre Google Front End (GFE) y el cliente. Estos pueden ser certificados SSL administrados por Google o autoadministrados.

A fin de obtener más información sobre los límites y las cuotas de los certificados SSL, consulta Certificados SSL en la página de cuotas del balanceo de cargas.

A fin de contar con la mayor seguridad, usa la encriptación de extremo a extremo en la implementación del balanceador de cargas del proxy SSL. Para obtener más información, consulta Encriptación del balanceador de cargas en los backends.

Para obtener información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe de Encriptación en tránsito en Google Cloud.

Preguntas frecuentes

¿Cuándo debo usar el balanceo de cargas de HTTPS en lugar del balanceo de cargas del proxy SSL?

Aunque el balanceo de cargas del proxy SSL puede controlar tráfico HTTPS, el balanceo de cargas de HTTP(S) cuenta con características adicionales que lo convierten en una mejor opción en la mayoría de los casos.

El balanceo de cargas de HTTP(S) cuenta con las siguientes características adicionales:

  • Negocia HTTP/2 y SPDY/3.1.
  • Rechaza solicitudes o respuestas HTTP no válidas.
  • Reenvía las solicitudes a diferentes VM según la ruta y el host de URL.
  • Se integra a Cloud CDN.
  • Distribuye la carga de la solicitud de manera más uniforme entre las instancias de backend, lo que proporciona un mejor aprovechamiento del backend. Los balanceos de cargas de HTTPS realizan solicitudes por separado, mientras que el balanceo de cargas del proxy SSL envía todos los bytes desde la misma conexión SSL o TCP hacia la misma instancia de backend.

El balanceo de cargas del proxy SSL se puede usar para otros protocolos que usan SSL, como IMAP y WebSockets mediante SSL.

¿Puedo ver la dirección IP original de la conexión a la capa de balanceo de cargas?

Sí. Puedes configurar el balanceador de cargas para que anteponga un encabezado de protocolo PROXY versión 1 que retenga la información de la conexión original. Si deseas obtener más información, consulta Actualiza el encabezado del protocolo de proxy para el proxy.

Qué sigue