Il tunneling SSH è più veloce di OpenVPN, potrebbe essere?

Logicamente, la VPN dovrebbe essere più veloce di SSH per il tunneling, perché:

• Funziona su UDP e non su TCP (quindi nessun TCP su TCP)
• Ha compressione

Tuttavia, oggi ho testato la replica di Redis su entrambi i metodi.
Ho eseguito il test su una VM AWS in Irlanda, collegandomi a una VM AWS negli Stati Uniti orientali.
Poiché il mio caso di test è la replica di Redis, questo è esattamente ciò che ho testato: ho eseguito un server Redis vuoto e, al termine del caricamento, ho eseguito slaveofl'altro server e misurato il tempo tra Connecting to MASTERe MASTER <-> SLAVE sync: Finished with success. Nel mezzo, ho usato

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

Per ottenere una stima approssimativa della velocità.
SSH ha vinto con un tiro a segno: ~ 11 MB / s rispetto ai ~ 2 MB / s di OpenVPN.
Ciò significa che tutto ciò che ho riesaminato era sbagliato o che ho configurato male la configurazione?

Aggiornare

Ho effettuato diversi test con lo stesso set di dati e ho ottenuto questi risultati:

• OpenVPN
  • TCP:
    compressione: 15m
    nessuna compressione: 21m
  • UDP:
    compressione: 5m
    nessuna compressione: 6m
• 
  Valori predefiniti SSH : 1m50s
  nessuna compressione: 1m30s
  compressione: 2m30s

Update2

Ecco i risultati iperf, con test bidirezionali (tranne SSH, dove non è disponibile alcun percorso di ritorno)

| 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       |

Specifiche tecniche

Sto eseguendo CentOS 6.3 (server), CentOS 6.5 (client).
La versione di OpenVPN è 2.3.2 (come in Ubuntu 14.10, quindi nessuna versione ammuffita lì) Il
mio tunneling SSH assomiglia a:

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

Il mio file di configurazione è simile a:
server

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

Grazie alla kasperd 's commento , ho imparato che SSH non soffre di TCP-over-TCP poiché solo sposta i dati a pacchetto. Ho scritto un post sul blog a riguardo, ma la cosa più interessante è l' netstatoutput, dimostrando che SSH in effetti non conserva i dati del Livello 3,4:

dopo il tunneling, prima del collegamento

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
...

dopo il tunneling e il collegamento

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
...

Quindi userò il tunneling SSH, dal momento che sembra che il mio OpenVPN non sia configurato in modo errato o altro, semplicemente non lo strumento giusto per il lavoro.

Dipende da cosa stai cercando di raggiungere e quali sono le tue priorità. VPN ti connette a una rete e SSH a una macchina. La VPN è un po 'più sicura con l'incapsulamento, cosa che SSH non fa.

Inoltre, VPN consente a tutto il traffico di attraversarlo facilmente, rispetto a SSH dove dovrai forzare le applicazioni.

Stai per usare AD? Perché VPN ti consentirà di farlo con molta più facilità.

Preferisco SSH per necessità veloci e VPN per applicazioni critiche in cui dovrei risparmiare tempo extra.

A seconda della situazione, ho usato SSH in una VPN nel caso in cui la VPN fosse compromessa. In questo modo qualcuno sondaggio dovrebbe superare il tunneling SSH.