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
- TCP:
- 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
fuente
Respuestas:
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
después de tunelizar y conectar
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.
fuente
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.
fuente