24 votos

¿SSH tunneling es más rápido que OpenVPN, podría ser?

Lógicamente, VPN debe ser más rápido que el de SSH para la construcción de túneles, debido a que:

  • Se ejecuta en UDP y TCP no (así que no hay TCP TCP)
  • Se ha de compresión

Sin embargo, hoy he probado Redis la replicación a través de ambos métodos.
Corrí la prueba con más de una Irlanda AWS VM, la conexión a un NOS-Oriente de AWS VM.
Desde mi caso de prueba es Redis de replicación, esto es exactamente lo que he probado - me quedé en blanco Redis servidor, y después de haber terminado de cargar, me ejecutado slaveof el otro servidor, y se mide el tiempo entre Connecting to MASTER y MASTER <-> SLAVE sync: Finished with success. En el medio, he usado

while 1; do redis-cli -p 7777 info | grep master_sync_left_bytes;sleep 1; done

Para obtener un crudo de la estimación de la velocidad.
SSH ganó por un tiro largo: ~11MB/s en comparación con OpenVPN ~2 MB/s.
Eso no significa que todo lo que me reaserched estaba mal, o me groseramente mal configurado mi instalación?

Actualización

He hecho varias pruebas con el mismo conjunto de datos, y se obtuvieron los siguientes resultados:

  • OpenVPN
    • TCP:
      compresión: 15m
      no hay compresión: 21m
    • UDP:
      compresión: 5m
      no hay compresión: 6m
  • SSH
    valores predeterminados: 1m50s
    no hay compresión: 1m30s
    compresión: 2m30s

Update2

Aquí están las iperf resultados, bidireccional pruebas (excepto SSH, donde no hay camino de retorno está disponible)

| method           | result (Mb/s)|
|------------------+--------------|
| ssh              | 91.1 / N.A   |
| vpn blowfish udp | 43 / 11      |
| vpn blowfish tcp | 13 / 12      |
| vpn AES udp      | 36 / 4       |
| vpn AES tcp      | 12 / 5       |

Especificaciones técnicas

Estoy corriendo CentOS 6.3 (servidor), CentOS 6.5 (cliente).
OpenVPN es la versión 2.3.2 (igual que en Ubuntu 14.10, así que no hay moho versión)
Mi SSH tunneling parece:

ssh -f XXXX@XXXX -i XXXX -L 12345:127.0.0.1:12345 -N

Mi archivo de configuración se parece a:
servidor

port 1194
proto udp
dev tun0
topology subnet
log /var/log/openvpn.log

ca XXXX
cert XXXX
key XXXX
dh XXXX
crl-verify XXXX

cipher AES-256-CBC

server XXXX 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
comp-lzo
status /var/log/openvpn-status.log
verb 3
tun-mtu 1500
fragment 1300

persist-key
persist-tun

cliente

client

remote XXXX 1194

proto udp
dev tun
log /var/log/openvpn.log
comp-lzo

cipher AES-256-CBC
ns-cert-type server

# the full paths to your server keys and certs
ca XXXX
cert XXXX
key XXXX

tun-mtu 1500 # Device MTU
fragment 1300 # Internal fragmentation

persist-key
persist-tun
nobind

10voto

Nitz Puntos 453

Gracias a kasperd's comentario, me enteré de que SSH no sufren de TCP-TCP, ya que sólo se mueve de paquetes de datos. Escribí un post en el blog al respecto, pero lo más interesante es el netstat salida, demostrando que SSH, de hecho, no preservar la Capa de 3,4 datos:

después del túnel, antes de conectar

backslasher@client$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 127.0.0.1:20000             0.0.0.0:*                   LISTEN      20879/ssh
tcp        0      0 10.105.16.225:53142         <SERVER IP>:22              ESTABLISHED 20879/ssh
...

backslasher@server$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 0.0.0.0:6379                0.0.0.0:*                   LISTEN      54328/redis-server
tcp        0      0 <SERVER IP>:22              <CLIENT IP>:53142           ESTABLISHED 53692/sshd
...

después de túnel y la conexión de

backslasher@client$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 127.0.0.1:20000             0.0.0.0:*                   LISTEN      20879/ssh
tcp        0      0 127.0.0.1:20000             127.0.0.1:53142             ESTABLISHED 20879/ssh
tcp        0      0 127.0.0.1:53142             127.0.0.1:20000             ESTABLISHED 21692/redis-cli
...

backslasher@server$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 0.0.0.0:6379                0.0.0.0:*                   LISTEN      54328/redis-server
tcp        0      0 127.0.0.1:6379              127.0.0.1:42680             ESTABLISHED 54328/redis-server
tcp        0      0 127.0.0.1:42680             127.0.0.1:6379              ESTABLISHED 54333/sshd
tcp        0      0 <SERVER IP>:22              <CLIENT IP>:53142           ESTABLISHED 52889/sshd
...

Así que voy a usar SSH túnel, ya que parece que mi OpenVPN no está mal configurado o algo, solo que no de la herramienta correcta para el trabajo.

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: