46 votos

Rendimiento de OpenVPN: ¿cuántos clientes simultáneos son posibles?

Estoy evaluando un sistema para un cliente donde muchos clientes de OpenVPN se conectan a un servidor de OpenVPN. "Muchos" significa 50000 - 1000000.

¿Por qué hago eso? Los clientes son sistemas distribuidos embebidos, cada uno sentado detrás del router dsl del propietario del sistema. El servidor necesita ser capaz de enviar comandos a los clientes. Mi primer enfoque ingenuo es hacer que los clientes se conecten al servidor a través de una red openvpn. De esta manera, el túnel de comunicación segura puede ser usado en ambas direcciones.

Esto significa que todos los clientes están siempre conectados al servidor. Hay muchos clientes resumiendo a lo largo de los años.

La pregunta es: ¿el servidor de OpenVPN explota al llegar a un cierto número de clientes? Ya estoy al tanto de un límite máximo de número de conexiones TCP, por lo tanto (y por otras razones) la VPN tendría que usar el transporte UDP.

Gurús de OpenVPN, ¿cuál es su opinión?

0 votos

¿Podría compartir con nosotros sus conclusiones finales al respecto? ¿Ha podido hacer pruebas con más de 5.000 usuarios?

0 votos

Hola Philipp, abandonamos el plan OpenVPN ya que estaba claro que tocaríamos un terreno que nadie había tocado antes. Optamos por una conexión TCP Socket normal basada en SSL a un servidor de gestión de conexiones Node.js.

28voto

the-wabbit Puntos 28168

Dudo que un montaje tan grande se haya intentado antes, por lo que es probable que se estén sobrepasando los límites al intentarlo. He podido encontrar un artículo sobre un Despliegue de VPN para 400 clientes pero a juzgar por el texto, el autor sólo se basó en estimaciones aproximadas sobre el número de clientes que podían ejecutarse por CPU y le faltó entender cómo funcionaría su configuración.

Principalmente, hay que tener en cuenta estos dos puntos:

  1. El ancho de banda que van a utilizar sus transferencias de datos necesitaría encriptación/desencriptación en el lado del servidor VPN, consumiendo recursos de la CPU

  2. Las conexiones de los clientes de OpenVPN consumen recursos de memoria y CPU en el servidor, incluso cuando no se transfieren datos.

Cualquier hardware de PC decente disponible hoy en día debería saturar fácilmente un enlace Gigabit con Blowfish o AES-128, incluso los dispositivos integrados de 100 dólares son capaz de alcanzar velocidades cercanas a los 100 Mbps por lo que los cuellos de botella de la CPU debidos a la intensidad del ancho de banda no deberían ser motivo de preocupación.

Teniendo en cuenta que el intervalo de reintroducción por defecto es de 3.600 segundos, un número de 1.000.000 de clientes significaría que el servidor tendría que ser capaz de completar 278 intercambios de claves por segundo de media. Aunque un intercambio de claves es una tarea bastante intensiva para la CPU, podría descargarla a un hardware dedicado si fuera necesario: las tarjetas aceleradoras criptográficas disponibles cumplen y superan fácilmente este número de handshakes TLS. Y las restricciones de memoria no deberían molestar demasiado también - un binario de 64 bits debería encargarse de cualquier restricción de memoria virtual que podría golpear de otra manera.

Pero lo mejor de OpenVPN es que se puede ampliar con bastante facilidad: basta con configurar un número arbitrario de servidores OpenVPN y asegurarse de que los clientes los utilizan (por ejemplo, mediante DNS round-robin), configurar un protocolo de enrutamiento dinámico de su elección (normalmente sería RIP debido a su simplicidad) y su infraestructura será capaz de soportar un número arbitrario de clientes siempre que tenga suficiente hardware.

0 votos

Gracias por la respuesta concisa. ¿Ves alternativas al uso de openvpn? El objetivo principal es solo tener la comunicación bidireccional pasando por el router.

2 votos

@SteffenMüller Si no necesitas una pila completa sino sólo un canal de control, por qué no usar algo similar a botnets ? Hay implementaciones disponibles y el SANS ofrece convenientemente un papel sobre cómo instalarlos

0 votos

Gracias por el interesante enlace. Desgraciadamente, el bot utiliza un simple sondeo para consultar si el servidor tiene información. Aunque este podría ser el camino a seguir, estoy buscando una manera de establecer y mantener una conexión bidireccional. El sondeo constante provoca retrasos en la ejecución de los comandos o un alto volumen de datos por peticiones de sondeo inútiles. ¿Tal vez una conexión TCP permanente es el camino a seguir?

27voto

Aitch Puntos 493

De hecho, he hecho esto, aunque con "sólo" unos pocos cientos de conexiones remotas de manera similar detrás de los routers DSL. No puedo comentar demasiado sobre los problemas de reintroducción, pero algunas cosas prácticas que aprendí en el camino:

1) Al desplegar los clientes, asegúrese de especificar varios servidores VPN en la conf del cliente, vpn1.ejemplo.com, vpn2.ejemplo.com, vpn3..... Incluso si sólo proporciona uno o dos de estos ahora, usted se da margen de maniobra. Si se configura correctamente, los clientes seguirán probando al azar hasta que encuentren uno que funcione.

2) Utilizamos una imagen de servidor de VPN de AWS personalizada, y podemos aumentar la capacidad adicional bajo demanda, y Amazon DNS (R53) se encarga de la parte de DNS. Está completamente separado del resto de nuestra infraestructura.

3) En el extremo del servidor o servidores, utilice cuidadosamente la máscara de red para restringir el número de clientes potenciales. Eso debería forzar a los clientes a ir a un servidor alternativo, mitigando los problemas de CPU. Creo que limitamos nuestros servidores a unos 300 clientes. Esta elección fue un tanto arbitraria por nuestra parte, una "corazonada" si se quiere.

4) También en el extremo del servidor, debe hacer un uso cuidadoso de los cortafuegos. En términos simples, tenemos el nuestro configurado de tal manera que los clientes pueden conectarse por VPN, pero los servidores no permiten estrictamente todas las conexiones ssh de entrada, excepto desde una dirección IP conocida. Podemos hacer SSH a los clientes si lo necesitamos ocasionalmente, pero ellos no pueden hacer SSH a nosotros.

5) No confíes en que OpenVPN haga la reconexión por ti en el extremo del cliente. 9 de cada 10 veces lo hará, pero a veces se bloquea. Tenga un proceso separado para restablecer/reiniciar openVPN en el extremo del cliente regularmente.

6) Necesitas una forma de generar claves únicas para los clientes para poder desautorizarlos a veces. Nosotros las generamos internamente con nuestro proceso de construcción del servidor (PXEboot). Nunca nos ha pasado, pero sabemos que podemos hacerlo.

7) Necesitará algunas herramientas de gestión, scripts para supervisar eficazmente las conexiones de su servidor VPN.

Lamentablemente, no hay mucho material sobre cómo hacer esto, pero es posible, con una configuración cuidadosa.

0 votos

Muchas gracias por la información. Me sorprende que los problemas de reintroducción ya te afecten con 300 clientes...

0 votos

Para aclarar - no lo han hecho, pero tampoco he estado rastreando .... :-/ El número de "300" parecía razonable. Si tenemos problemas, simplemente aumentaremos la imagen de AWS a una instancia más grande. Nunca he tenido cerca de ese número de conexiones en un servidor antes, probablemente sólo alrededor de 100 máximo, pero corremos varios servidores y que aproximadamente el equilibrio en línea con openvpn elegir un destino de una lista conocida al azar.

0 votos

¿Puedes compartir más detalles sobre cómo lo haces? "5) No confíes en que OpenVPN haga la reconexión por ti en el extremo del cliente. 9 de cada 10 veces lo hará, pero a veces se bloquea. Ten un proceso separado para restablecer/reiniciar openVPN en el extremo del cliente regularmente".

4voto

CraigZ Puntos 41

Actualización 2018

No estoy seguro de lo que ha cambiado desde 2012. Sólo quería dar una actualización en cuanto a mi experiencia en 2018. Hemos desplegado una red openvpn muy similar a la configuración OP. Nuestros puntos finales son pcs linux completos en lugar de dispositivos integrados. Cada punto final tiene un monitor que se utiliza para mostrar la información y la alarma para ese sitio y nuestro servidor nos permite un único punto para remoto en todos los puntos finales. La red no es demasiado activa, pero a veces tiene 5-10 sesiones remotas simultáneamente.

Usando una construcción actual de openvpn en alrededor de 100 clientes en una imagen de azure con un solo núcleo y 2gb de ram usamos alrededor de 0,7% de la memoria en promedio y el uso de la cpu es casi siempre alrededor de 0%. Basado en lo que encontré para esta prueba más pequeña me imagino que un solo servidor con especificaciones decentes podría manejar fácilmente 50000 concurrentes si tuviera la ram para soportarlo. Si el uso de la memoria RAM escala linealmente, entonces 16gb sería capaz de manejar 50000 usuarios con suficiente extra en una máquina dedicada openvpn.

No estamos en una escala lo suficientemente grande como para decir que con la confianza significativa, pero yo sólo quería dar una actualización reciente, ya que cuando originalmente el despliegue de nuestra red me encontré con esto y estaba esperando mucho más el uso de recursos en esta escala. Ahora, creo que la cpu que ejecuta esto tiene encriptación de hardware y no estoy seguro de en qué punto se sobrecargaría el tráfico sabio pero para los puntos finales que no se comunican mucho esto no debería ser un problema.

A 1000000 necesitarías 200gb de ram en una sola máquina (si se escala linealmente con el extra) mientras que esto es posible yo pensaría que en ese punto querrías tener 5 máquinas cada una con 64gb de ram para no tener un solo punto de fallo. Esto debería permitir el mantenimiento, reinicios y reemplazos de 1 o incluso 2 máquinas sin problemas significativos.

Mis estimaciones de ram son probablemente exageradas ya que estoy dividiendo todo el uso de openvpn por el número de clientes donde sólo una parte de esa ram se debe a los clientes.

Hemos añadido 74 puntos finales en un año desde su despliegue inicial. Espero seguir aumentando ese número de forma significativa y haré una nueva actualización si llegamos a una escala decente.

0 votos

¿Puedes compartir más detalles sobre cómo lo haces? "5) No confíes en que no me deja comentar en el hilo anterior pero quería responder a esto:OpenVPN haciendo la reconexión por ti en el extremo del cliente. 9 de cada 10 veces lo hará, pero a veces se atasca. Ten un proceso separado para reiniciar openVPN en el extremo del cliente regularmente." - Doug 18 mayo '17 a las 17:12

0 votos

Llegar a un límite de caracteres. Utiliza supervisord para hacerlo. Haz que se reinicie automáticamente cada 6-12h

0 votos

¿Hay más novedades al respecto? Su respuesta es muy interesante, ya que en muchos otros foros se indica que lo que puede soportar una sola instancia es un número de centenas bajo o medio.

1voto

Davor Dundovic Puntos 11

Estoy estudiando un problema similar, aunque el número de clientes sería de cientos, tal vez un par de miles.

Me he dado cuenta de que no puedo mantener a todos los clientes conectados todo el tiempo.

Estoy pensando en iniciar el demonio OpenVPN en los clientes en intervalos de tiempo aleatorios para que puedan comprobar si fueron encuestados. Si lo fueron, deben enviar un correo electrónico o algo así que están en línea y enviar paquetes keep alive durante un período de tiempo para que pueda conectarme a ellos.

Si no hay tráfico durante algún tiempo, el demonio se detendrá.

El problema al que me enfrento ahora es que parece imposible obtener una lista de los clientes VPN actualmente conectados...

2 votos

Puede obtener una lista actual de clientes conectados a través del registro de estado de openvpn. Allí se ven todas las ips conectadas al servidor actual.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X