Requisitos de hardware OpenVPN

Estoy planeando una nueva red. Todo el tráfico que sale de esta red se convertirá en una VPN para salir a Internet en un servidor distante. Esto se hará a través de OpenVPN. Sólo habrá un túnel.

Estamos buscando una conexión a Internet de muy alta velocidad con una velocidad descendente de 100 Mbit / sy una velocidad de 5 Mbit / s.

¿Qué tipo de hardware necesitaré para soportar tales velocidades? ¿Hay alguna regla de pulgar para el tamaño del hardware de los servidores OpenVPN?

¿Será suficiente un tablero de átomos? ¿Qué hay de un AMD Geode 800Mhz?

Gracias de antemano por su ayuda,

Supongo que una CPU Atom manejará 100mbit de tráfico OpenVPN. Bajo carga se puede encontrar un Atom introducirá un poco más de latencia que una CPU más rápida, pero esto probablemente no será significativo cuando se considera en contra de la latencia de los enlaces de larga distancia que tiene entre el servidor y los clientes.

Algunos resultados de pruebas no científicas, la ejecución de datos entre mi netbook con una CPU Atom a un servidor OpenVPN local (a través de una red de 1000mbit, pero el netbook sólo tiene una NIC de 100Mbit):

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.43.1 3333 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 91.2072 s, 11.8 MB/s real 1m31.227s user 0m1.792s sys 0m25.874s dspillett@minirant:~$ dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.44.1 3333 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 113.082 s, 9.5 MB/s real 1m53.107s user 0m1.468s sys 0m15.337s dspillett@minirant:~$ 

Donde 192.168.43.1 es el servidor visto justo encima de la red local y 192.168.44.1 es la misma máquina que se ve a través de un enlace OpenVPN a través de esa red. La VPN está en modo puente, utilizando una conexión basada en UDP.

Htop mostró que la CPU se gravaba más durante la prueba de VPN que el usuario + sys cuenta desde el time porque el time sólo está contando la actividad de la CPU del dd , no las VPN. Se mostró cpu0 a ~ 70% y cpu1 a ~ 30% a lo largo de la prueba que sugeriría que la CPU está cerca del límite que puede transferir a través de OpenVPN en esa prueba (que Atom era single core pero con hyperthreading) Para mezclar a lo largo de 9.5Mbyte / seg.

Como una indicación de la latencia añadida por la VPN (que será una combinación de gastos generales de trabajo de la CPU de cifrado de datos y la sobrecarga del método de tunelización), ping con pequeños (por defecto, 56 byte de carga) paquetes:

 --- 192.168.43.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8997ms rtt min/avg/max/mdev = 0.138/0.166/0.183/0.015 ms --- 192.168.44.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8998ms rtt min/avg/max/mdev = 0.544/0.614/0.860/0.091 ms 

Y mayores (2048 byte payload):

 --- 192.168.43.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet los rtt min/avg/max/mdev = 0.514/0.521/0.531/0.021 ms --- 192.168.44.1 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 0.710/0.997/1.437/0.173 ms 

Obviamente obtendrá resultados diferentes con la VPN que maneja múltiples conexiones que muestran patrones de tráfico en el mundo real, por lo que quizás desee realizar algunas pruebas más detalladas usted mismo. Usted puede ser capaz de exprimir más con algunos ajustes – mi conjunto de OpenVPN es prácticamente correr en fuera de la caja de los valores por defecto.

No conozco ningún punto de referencia publicado aparte de algunas pruebas informales que algunas personas han publicado y publicado en sus sitios web. Anecdóticamente, el código criptográfico (OpenSSL) no parece ser el más optimizado del mundo, pero tampoco parece ser un cerdo. Un punto de referencia fácil para usted sería configurar un servidor OpenVPN y el cliente en un par de PCs en una LAN y el tiempo de mover un poco de tráfico a través de ellos mientras observa la carga de la CPU en ambos.

Puedo decirte que puedo saturar un acoplamiento de 802.11g que funciona en 54Mbps con tráfico cifrado sin maximizar hacia fuera la CPU en una máquina de la chatarra Pentium II 400Mhz que sea el servidor de OpenVPN en mi LAN casera. Eso me hace pensar que el Geode probablemente podría hacerlo, también.

OpenSSL (y por lo tanto OpenVPN) también soporta algunas soluciones de descarga de hardware. Una solución de gama baja es el "candado" de Vía, incluido en algunos chips de Vía. Eso también podría ser una manera de mantener bajos los requerimientos de su CPU. Ver:

Tengo set-up 2 servidores de OpenVPN y ambos trabajando muy bien, he hecho 3 clientes para cada uno y ellos ssem a, ser cooping bien.

Uno se basa en RasPi 3 con 32 GB de micro SD muy rápido y 32 GB USB clave adicional, hasta ahora tan bueno.

El otro es un portátil con 4Gb Ram y 500Gb HD ejecutando UBUNTU, este también está funcionando bien.

Mi conclusión es ésta; Si usted no tiene un montón de clientes en mi caso 3, realmente no necesita una gran cantidad de crujido número de animales por lo tanto, muy poco costo en la creación de él.

Mi velocidad de descarga de Internet es de 60Mb / s y la velocidad de subida es de 16 Mb / s, es por eso que tengo 3 clientes, es decir ~ 5Mb / s cada uno.

Aclamaciones

Siamak

Recomendaría un VIA Nano. Con una vía VIA Nano L2200 @ 1600MHz puedo empujar 330 Mbits. El nano VIA está en el mismo rango de precio que el Atom y tiene soporte de hardware AES. Para obtener un rendimiento como este, tendrá que cambiar de blowfish de AES y agregar lo siguiente a openssl.conf:

 openssl_conf = openssl_def [openssl_def] engines = openssl_engines [openssl_engines] padlock = padlock_engine [padlock_engine] default_algorithms = ALL 

Aquí hay un enlace a un ejemplo de un combo mobo / CPU: http://www.via-itx.com/via-vb8001.html