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

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

¿Por qué hago eso? Los clientes son sistemas integrados distribuidos, cada uno sentado detrás del enrutador dsl de los propietarios del sistema. El servidor debe poder 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 seguro se puede utilizar en ambas direcciones.

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

La pregunta es: ¿explota el servidor OpenVPN cuando llega a un cierto número de clientes? Ya conozco un límite máximo de número de conexión 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?

Dudo que alguna vez se haya intentado una configuración tan grande, por lo que probablemente superará los límites al intentarlo. Pude encontrar un artículo sobre una implementación de VPN para 400 clientes, pero a juzgar por el texto, el autor se basó en estimaciones aproximadas sobre cuántos clientes podrían ejecutarse por CPU y no entendió cómo funcionaría su configuración.

Principalmente deberías considerar estos dos puntos:

1. El ancho de banda que usarán sus transferencias de datos necesitaría cifrado / descifrado en el lado del servidor VPN, consumiendo recursos de la CPU

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

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

Dado el intervalo de reescritura predeterminado de 3600 segundos, un número de 1,000,000 de clientes significaría que el servidor necesitaría poder completar 278 intercambios de claves por segundo en promedio. Si bien un intercambio de claves es una tarea bastante intensiva de la CPU, podría descargarlo en hardware dedicado si es necesario: las tarjetas de aceleración criptográficas disponibles cumplen y superan fácilmente este número de apretones de manos 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 de lo contrario podría afectar.

Pero la verdadera belleza de OpenVPN es que puede escalarlo con bastante facilidad: simplemente configure un número arbitrario de servidores OpenVPN y asegúrese de que sus clientes los estén utilizando (por ejemplo, mediante DNS round-robin), configure un protocolo de enrutamiento dinámico de su elección (normalmente esto sería RIP debido a su simplicidad) y su infraestructura sería capaz de soportar un número arbitrario de clientes siempre que tenga suficiente hardware.

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

1) Al implementar clientes, asegúrese de especificar varios servidores VPN en la configuración del cliente, vpn1.example.com, vpn2.example.com, vpn3 ..... Incluso si solo proporciona uno o dos de estos ahora, usted da usted mismo espacio para la cabeza. Configurados correctamente, los clientes seguirán reintentándolos al azar hasta que encuentren uno que funcione.

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

3) Al final del servidor (s), haga un uso cuidadoso de la máscara de red para restringir el número de clientes potenciales. Eso debería forzar a los clientes a un servidor alternativo, mitigando los problemas de la CPU. Creo que limitamos nuestros servidores a aproximadamente 300 clientes. Esta elección fue algo arbitraria de nuestra parte: "instinto" si lo desea.

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

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

6) Necesita una forma de generar claves únicas para los clientes para que pueda rechazarlas a veces. Los generamos internamente con nuestro proceso de compilación del servidor (PXEboot). Nunca nos sucedió, pero sabemos que podemos hacerlo.

7) Necesitará algunas herramientas de administración, scripts para monitorear las conexiones de su servidor VPN de manera efectiva.

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

Actualización 2018

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

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

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

En 1000000 necesitaría 200 gb de ram en una sola máquina (si se escala linealmente con extra), mientras que esto es posible, creo que en ese momento desearía tener 5 máquinas cada una con 64 gb de ram para que no tenga un solo punto de fracaso Esto debería permitir el mantenimiento, reinicios y reemplazos de 1 o incluso 2 máquinas sin problemas importantes.

Es probable que mis estimaciones de ram sean excesivas ya que estoy dividiendo todo el uso de openvpn por el número de clientes donde solo una parte de ese ram se debe a los clientes.

Hemos agregado 74 puntos finales en un año desde su implementación inicial. Espero seguir aumentando significativamente ese número y haré una nueva actualización si llegamos a una escala decente.

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

Pensé que no puedo mantener a todos los clientes conectados todo el tiempo.

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

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

El problema que estoy enfrentando en este momento es que parece imposible obtener una lista de los clientes VPN actualmente conectados ...