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 ubicado detrás del enrutador dsl del propietario 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 están siempre conectados al servidor. Hay muchos clientes resumiendo a lo largo de los años.
La pregunta es:¿El servidor OpenVPN explota al llegar a una determinada cantidad de clientes? Ya conozco un límite máximo de número de conexiones TCP, por lo tanto (y por otras razones) la VPN tendría que usar transporte UDP.
Gurús de OpenVPN, ¿cuál es vuestra opinión?
Respuesta1
Dudo que alguna vez se haya intentado una configuración tan grande, por lo que es probable que superes los límites al intentarlo. Podría encontrar un artículo sobre unImplementación de VPN para 400 clientespero a juzgar por el texto, el autor sólo se basó en estimaciones aproximadas sobre cuántos clientes podrían ejecutarse por CPU y no entendía cómo funcionaría su configuración.
Principalmente deberías considerar estos dos puntos:
El ancho de banda que utilizarán sus transferencias de datos necesitaría cifrado/descifrado en el lado del servidor VPN, lo que consumiría recursos de la CPU.
Las conexiones del cliente 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 soncapaz de velocidades cercanas a 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.
Dado el intervalo de cambio de clave predeterminado de 3600 segundos, una cantidad 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 que consume bastante CPU, puede descargarlo a hardware dedicado si es necesario: las tarjetas aceleradoras criptográficas disponibles cumplen y superan fácilmente esta cantidad de apretones de manos TLS. Y las restricciones de memoria tampoco deberían molestar demasiado: un binario de 64 bits debería encargarse de cualquier restricción de memoria virtual que de otro modo probablemente enfrentaría.
Pero la verdadera belleza de OpenVPN es que puede escalarlo con bastante facilidad: simplemente configure una cantidad arbitraria de servidores OpenVPN y asegúrese de que sus clientes los estén usando (por ejemplo, a través de 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 admitir una cantidad arbitraria de clientes siempre que tenga suficiente hardware.
Respuesta2
De hecho, he hecho esto, aunque con "sólo" unos pocos cientos de conexiones remotas detrás de enrutadores DSL. No puedo comentar mucho sobre los problemas de cambio de claves, pero aprendí algunas cosas prácticas a lo largo del 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 ahora solo proporciona uno o dos de estos, proporcione usted mismo espacio para la cabeza. Configurados correctamente, los clientes seguirán intentándolos al azar hasta que encuentren uno que funcione.
2) Usamos una imagen de servidor VPN de AWS personalizada y podemos generar capacidad adicional a pedido, y Amazon DNS (R53) maneja el lado DNS. Está completamente desvinculado del resto de nuestra infraestructura.
3) En el extremo del servidor, haga un uso cuidadoso de la máscara de red para restringir la cantidad de clientes potenciales. Eso debería obligar a los clientes a utilizar un servidor alternativo, mitigando los problemas de la CPU. Creo que limitamos nuestros servidores a unos 300 clientes. Esta elección fue un tanto arbitraria de nuestra parte: "intuición", si se quiere.
4) También en el lado del servidor, debes hacer un uso cuidadoso de los cortafuegos. En términos simples, tenemos el nuestro configurado de manera que los clientes puedan conectarse mediante VPN, pero los servidores prohíben 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 a nosotros.
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 lado del cliente regularmente.
6) Necesita una forma de generar claves únicas para los clientes para poder desautorizarlas a veces. Los generamos internamente con el proceso de compilación de nuestro servidor (PXEboot). A nosotros nunca nos ha pasado, pero sabemos que podemos hacerlo.
7) Necesitará algunas herramientas de administración y 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.
Respuesta3
Actualización 2018
No estoy seguro de qué ha cambiado todo desde 2012. Solo quería brindar una actualización sobre mi experiencia en 2018. Hemos implementado una red openvpn muy similar a la configuración OP. Nuestros puntos finales son equipos 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 para acceder de forma remota a todos los puntos finales. La red no está demasiado activa, pero a veces tiene entre 5 y 10 sesiones remotas simultáneamente.
Usando una versión actual de openvpn en alrededor de 100 clientes en una imagen azul con un solo núcleo y 2 GB de RAM, utilizamos alrededor del 0,7 % de la memoria en promedio y el uso de la CPU casi siempre es de alrededor 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 simultáneos si tuviera la memoria RAM para admitirlo. Si el uso de RAM aumentara linealmente, entonces 16 GB podrían manejar 50000 usuarios con suficiente extra en una máquina openvpn dedicada.
No estamos en una escala lo suficientemente grande como para decir eso con mucha confianza, pero solo quería brindar una actualización reciente ya que cuando implementé originalmente nuestra red encontré esto y esperaba un uso mucho mayor 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 de tráfico, pero para los puntos finales que no se comunican mucho esto no debería ser un problema.
En 1000000 necesitarías 200 GB de RAM en una sola máquina (si se escala linealmente con más), aunque esto es posible, creo que en ese momento querrías tener 5 máquinas cada una con 64 GB de RAM para no tener 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 exageradas, ya que estoy dividiendo todo el uso de openvpn por la cantidad de clientes, donde solo una parte de esa RAM se debe a los clientes.
Hemos agregado 74 puntos finales en un año desde su implementación inicial. Espero seguir aumentando ese número de manera significativa y haré más actualizaciones si llegamos a una escala decente.
Respuesta4
Estoy investigando un problema similar, aunque la cantidad de clientes sería de cientos, tal vez 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 los clientes en intervalos de tiempo aleatorios para que puedan comprobar si fueron encuestados. Si lo estuvieran, deben enviar un correo electrónico o algo así indicando que están en línea y enviar paquetes de mantenimiento activo durante un período de tiempo para que pueda conectarme con 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 clientes VPN actualmente conectados...