El túnel SSH es más rápido que OpenVPN, ¿podría ser?

Lógicamente, la VPN debería ser más rápida que SSH para la tunelización, porque:

• Se ejecuta en UDP y no en TCP (por lo que no hay TCP sobre TCP)
• Tiene compresión

Sin embargo, hoy probé la replicación de Redis con ambos métodos.
Ejecuté la prueba en una VM AWS de Irlanda, conectándome a una VM AWS de EE. UU.
Como mi caso de prueba es la replicación de Redis, esto es exactamente lo que probé: ejecuté un servidor Redis en blanco y, después de que terminó de cargarse, ejecuté slaveofel otro servidor y medí el tiempo entre Connecting to MASTERy MASTER <-> SLAVE sync: Finished with success. En el medio, solía

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

Para obtener una estimación aproximada de la velocidad.
SSH ganó por una posibilidad remota: ~ 11MB / s en comparación con los ~ 2MB / s de OpenVPN.
¿Significa eso que todo lo que recomendé estaba mal o que configuré mal mi configuración?

Actualizar

Hice varias pruebas con el mismo conjunto de datos y obtuve estos resultados:

• OpenVPN
  • TCP:
    compresión: 15 m
    sin compresión: 21 m
  • UDP:
    compresión: 5m
    sin compresión: 6m
• Valores
  predeterminados de SSH : 1m50s
  sin compresión: 1m30s
  compresión: 2m30s

Actualización2

Aquí están los resultados de iperf, con pruebas bidireccionales (excepto SSH, donde no hay una ruta de retorno 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 ejecutando CentOS 6.3 (servidor), CentOS 6.5 (cliente).
La versión de OpenVPN es 2.3.2 (igual que en Ubuntu 14.10, por lo que no hay una versión con moho)
Mi túnel SSH se ve así:

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

Gracias a kasperd 's comentario , he aprendido que SSH no sufre de TCP-sobre-TCP, ya que sólo se mueve de paquetes de datos. Escribí una publicación de blog al respecto, pero lo más interesante es la netstatsalida, demostrando que SSH de hecho no conserva los datos de la Capa 3,4:

después de hacer un 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 tunelizar y 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 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 el túnel SSH, ya que parece que mi OpenVPN no está mal configurado ni nada, simplemente no es la herramienta adecuada para el trabajo.

Depende de lo que intente lograr y cuáles sean sus prioridades. VPN te conecta a una red y SSH a una máquina. VPN es un poco más seguro con la encapsulación, que SSH no hace.

Además, VPN permite que todo el tráfico lo atraviese fácilmente, en comparación con SSH, donde tendrá que forzar las aplicaciones.

¿Vas a usar AD en absoluto? Porque VPN te permitirá hacerlo con mucha más facilidad.

Prefiero SSH para necesidades rápidas y VPN para aplicaciones críticas en las que debo ahorrar tiempo extra.

Dependiendo de la situación, he usado SSH en una VPN en caso de que la VPN se haya visto comprometida. De esta manera, alguien que realiza la prueba tendría que atravesar el túnel SSH.