Descripción general del balanceador de cargas de red del proxy externo

En este documento, se presentan los conceptos que debes comprender para configurar un Trusted Cloud balanceador de cargas de red del proxy externo.

El balanceador de cargas de red del proxy externo es un balanceador de cargas de proxy inverso que distribuye el tráfico TCP proveniente de Internet a instancias de máquina virtual (VM) en tu red deTrusted Cloud nube privada virtual (VPC). Cuando se usa un balanceador de cargas de red del proxy externo, el tráfico de usuarios de TCPentrante finaliza en el balanceador de cargas. Luego, una conexión nueva reenvía el tráfico al backend.

Los balanceadores de cargas de red del proxy externo te permiten usar una sola dirección IP para todos los usuarios en todo el mundo. El balanceador de cargas enruta el tráfico de manera automática a los backends que están más cerca del usuario.

Este balanceador de cargas está disponible en el modo regional y, a partir de ahora, se lo denominará balanceador de cargas de red de proxy externo regional. El balanceador de cargas se implementa como un servicio administrado basado en el proxy de Envoy con código abierto. El modo regional garantiza que todos los clientes y backends estén en una región especificada. Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento).

Arquitectura

En los siguientes diagramas, se muestran los componentes de los balanceadores de cargas de red del proxy externo.

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red del proxy externo regional.

Componentes del balanceador de cargas de red del proxy externo regional
Componentes del balanceador de cargas de red del proxy externo regional (haz clic para ampliar)

Los siguientes son componentes de balanceadores de cargas de red del 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 cargas. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas basados en Envoy en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy.

Las VM de backend o los extremos de todos los balanceadores de cargas en una región y una red de VPC reciben conexiones desde la subred de solo proxy.

Puntos que debes recordar:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • La dirección IP del balanceador de cargas no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada externa.

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 en 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 para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática. De lo contrario, debes 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.

Especificación de puerto Las reglas de reenvío externas que se usan en la definición de este balanceador de cargas pueden hacer referencia exactamente a un puerto del 1 al 65535. Si deseas 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 usar proxies en varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual del proxy TCP. Si deseas obtener más detalles, consulta Especificaciones de puertos para 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 proxies en varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual del proxy TCP.

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

Modo de balanceador de cargas Nivel de servicio de red Regla de reenvío, dirección IP y esquema de balanceo de cargas Enrutamiento de Internet al frontend del balanceador de cargas
Balanceador de cargas de red del proxy externo regional Nivel Premium

Regla de reenvío externa regional

Dirección IP externa regional

Esquema de balanceo de cargas: EXTERNAL_MANAGED

 Solicitudes enrutadas a los proxies de Envoy en la misma región que el balanceador de cargas.

Reglas de reenvío y redes de VPC

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

Modo de balanceador de cargas Asociación de redes de VPC
Balanceador de cargas de red del proxy externo regional

La red de VPC de la regla de reenvío es la red en la que se creó la subred de solo proxy. Debes especificar la red cuando creas la regla de reenvío.

Proxies de destino

Los balanceadores de cargas de red del proxy externo finalizan las conexiones del cliente y crean conexiones nuevas a los backends. El proxy de destino enruta estas conexiones nuevas al servicio de backend.

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

En la siguiente tabla, se muestran los requisitos del proxy de destino para los balanceadores de cargas de red de proxy externos.

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

Servicios de backend

Los servicios de backend dirigen el tráfico entrante a uno o más backends adjuntos. 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 tiene un solo recurso de servicio de backend que especifica la verificación de estado que se realizará para los backends disponibles.

Los cambios que se realicen en el servicio de backend no son instantáneos. Los cambios pueden demorar varios minutos en propagarse a los GFE. 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.

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

En la siguiente tabla, se especifican los diferentes backends compatibles con el servicio de backend de los balanceadores de cargas de red del proxy externo.

Modo de balanceador de cargas Backends compatibles en un servicio de backend
Grupos de instancias NEG zonales NEG de Internet NEG sin servidores NEG híbridos GKE
Balanceador de cargas de red del proxy externo regional Extremos de tipo GCE_VM_IP_PORT Solo NEG regionales

Backends y redes de VPC

Para los backends del balanceador de cargas de red del proxy externo regional, se aplica lo siguiente:

  • Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect.

    Definición de la red de backend

    • En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
    • En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
    • En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz nic0 de la primera VM que se agrega al grupo de instancias.

    Requisitos de red del backend

    La red de tu backend debe satisfacer 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 intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

  • Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a interfaces que no son de nic0 (ya sean vNICs o interfaces de red dinámicas), usa backends de NEG en su lugar.

Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.

Protocolo para comunicarse con los backends

Cuando configuras un servicio de backend para un balanceador de cargas de red del proxy externo, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos. El balanceador de cargas solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo. Los balanceadores de cargas de red de proxy externos solo son compatibles con TCP para comunicarse con los backends.

Reglas de firewall

Se requieren las siguientes reglas de firewall:

  • Para los balanceadores de cargas de red del proxy externo regional, se necesita una regla de firewall de entrada que permita que el tráfico de la subred de solo proxy llegue a tus backends.

  • Una regla de firewall allow de entrada para permitir 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 el nivel de los proxies de GFE. No puedes usar reglas de firewall 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 zonal GCE_VM_IP_PORT NEG: permite el tráfico a los números de puerto de los extremos.

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 del balanceador de cargas.Trusted Cloud En otras palabras, existen dos conexiones TCP.

Para los balanceadores de cargas de red del proxy externo regional:

  • Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente está detrás de una puerta de enlace 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 (subred de solo proxy) hasta la VM o el extremo de backend:

    • Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red que el balanceador de cargas.

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

Puertos abiertos

Los balanceadores de cargas de red del proxy externo son balanceadores de cargas del 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. Cuando ejecutas un análisis de puerto, es posible que veas 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 envían paquetes SYN-ACK en respuesta a los sondeos de SYN solo para los puertos en los que configuraste una regla de reenvío. 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 que se envían a una dirección IP o un puerto diferentes no se envían a los backends.

    Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Cloud Armor Standard, los GFE proporcionan protección siempre encendida contra ataques de DSD volumétricos basados en protocolos y desbordamientos SYN. Esta protección está disponible incluso si no configuraste Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te inscribes en Managed Protection Plus.

  • 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 GFEs 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 VMs 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

Los balanceadores de cargas de red del proxy externo regional admiten implementaciones que usan redes de 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 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 debe definirse en el mismo proyecto que las instancias de backend.

Para los balanceadores de cargas de red del proxy externo regional, las VM de backend se suelen ubicar en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend regional y una verificación de estado.

Distribución del tráfico

Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo de cargas, que define un método que mide la carga de backend y una capacidad objetivo.

Para los balanceadores de cargas de red del proxy externs, 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 total de conexiones que puede controlar el backend.
  • Si el modo de balanceo de cargas es UTILIZATION, la carga se distribuye según el uso de instancias en un grupo de instancias. Este modo de balanceo se aplica solo a los backends de grupos de instancias de VM.

La distribución del tráfico entre los backends se determina según el modo de balanceo del balanceador de cargas.

Balanceador de cargas de red del proxy externo regional

Para los balanceadores de cargas de red del proxy externo regional, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.

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 cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro 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. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.

Para obtener más información, consulta lo siguiente:

Afinidad de sesión

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

Los balanceadores de cargas de red del proxy externo ofrecen los siguientes tipos de afinidad de sesión:

  • Ninguno

    Un parámetro de configuración de afinidad de sesión de NONE no significa que no haya afinidad de sesión. Esto significa que no se configuró explícitamente ninguna opción de afinidad de sesión.

    El hashing siempre se realiza para seleccionar un backend. Además, un parámetro de configuración de afinidad de sesión de NONE significa que el balanceador de cargas usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas consta de 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 de IP de cliente (CLIENT_IP) es un hash de 2 tuplas creado a partir de las direcciones IP de origen y 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 ese backend 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 cargas si el paquete se envía directamente al balanceador de cargas.
    • Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si un sistema intermedio de NAT o proxy procesa el paquete antes de que se entregue a un balanceador de cargas de Trusted Cloud . En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs de backend pueden recibir más conexiones o solicitudes que otras.

Ten en cuenta lo siguiente cuando configures la afinidad de sesión:

  • No uses la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión puede interrumpirse cada vez que cambia la cantidad de backends activos y en buen estado. Para obtener más información, consulta Pérdida de afinidad de sesión.

  • Los valores predeterminados de las marcas --session-affinity y --subsetting-policy son NONE, y solo uno de ellos a la vez se puede establecer en un valor diferente.

Pérdida de la afinidad de sesión

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

  • La instancia o el extremo de backend seleccionados deben permanecer configurados como backend. La afinidad de sesión se puede interrumpir cuando ocurre uno de los siguientes eventos:
    • Quitas la instancia seleccionada de su grupo de instancias.
    • El ajuste de escala automático o la recuperación automática del grupo de instancias administrado quitan la instancia seleccionada de su grupo de instancias administrado.
    • Quitas el extremo seleccionado de su NEG.
    • Quitas del servicio de backend el grupo de instancias o el NEG que contiene la instancia o el extremo seleccionados.
  • La instancia o el extremo de backend seleccionados deben permanecer en buen estado. La afinidad de sesión se puede interrumpir cuando la instancia o el extremo seleccionados fallan en las verificaciones de estado.
  • En el caso de los balanceadores de cargas de red de proxy externos globales y los balanceadores de cargas de red de proxy clásicos, la afinidad de sesión puede interrumpirse si se usa un Google Front End (GFE) de primera capa diferente para las solicitudes o conexiones posteriores después del cambio en la ruta de acceso de enrutamiento. Es posible que se seleccione un GFE de primera capa diferente si la ruta de acceso de enrutamiento de un cliente en 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 el NEG que contiene la instancia o el extremo seleccionados no deben estar completos según su capacidad objetivo. (En el caso de los grupos de instancias administrados regionales, el componente zonal del grupo de instancias que contiene la instancia seleccionada no debe estar completo). La afinidad de sesión puede interrumpirse cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEG no lo están. Dado que la plenitud puede cambiar de formas impredecibles cuando se usa el modo de balanceo UTILIZATION, debes usar el modo de balanceo RATE o CONNECTION para minimizar las situaciones en las que se puede interrumpir la afinidad de sesión.

  • La cantidad total de instancias o extremos de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend configurados, y se puede interrumpir la afinidad de sesión:

    • Agregar instancias o extremos nuevos:

      • Agrega instancias a un grupo de instancias existente en el servicio de backend.
      • El ajuste de escala automático del grupo de instancias administrado agrega instancias a un grupo de instancias administrado en el servicio de backend.
      • Agrega extremos a un NEG existente en el servicio de backend.
      • Agregas grupos de instancias o NEG no vacíos al servicio de backend.

    • Quitar cualquier instancia o extremo, no solo la instancia o el extremo seleccionados:

      • Quitas cualquier instancia de un backend de grupo de instancias.
      • El ajuste de escala automático o la recuperación automática de un grupo de instancias administrado quitan cualquier instancia de un backend de grupo de instancias administrado.
      • Quitas cualquier extremo de un backend de NEG.
      • Quita cualquier grupo de instancias de backend o NEG existente y no vacío del servicio de backend.

  • La cantidad total de instancias o extremos de backend en buen estado debe permanecer constante. Cuando ocurre al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend en buen estado, y se puede interrumpir la afinidad de sesión:

    • Cualquier instancia o extremo pasa su verificación de estado y pasa de estar en mal estado a estar en buen estado.
    • Cualquier instancia o extremo falla su verificación de estado y pasa de estar en buen estado a estar en mal estado o con tiempo de espera agotado.

Conmutación por error

La conmutación por error para los balanceadores de cargas de red del proxy externos funciona de la siguiente manera:

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

Para obtener documentación relacionada, consulta Balanceo de cargas nativo del contenedor mediante NEG zonales independientes.

Limitaciones

  • No puedes crear un balanceador de cargas de red de proxy externo regional en el nivel Premium con laTrusted Cloud consola. En su lugar, usa gcloud CLI o la API.

  • Trusted Cloud no garantiza la duración de las conexiones TCP cuando usas balanceadores de cargas de red del proxy externo. 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 administran las conexiones.

¿Qué sigue?