O encapsulamento SSH é mais rápido que o OpenVPN, poderia ser?

Logicamente, a VPN deve ser mais rápida que o SSH para o encapsulamento, porque:

• Está rodando em UDP e não em TCP (portanto, não há TCP sobre TCP)
• Tem compressão

No entanto, hoje testei a replicação Redis nos dois métodos.
Fiz o teste em uma VM da AWS na Irlanda, conectando-me a uma VM da AWS no leste dos EUA.
Como meu caso de teste é a replicação Redis, foi exatamente isso que eu testei - executei um servidor Redis em branco e, após o carregamento, executei slaveofo outro servidor e medi o tempo entre Connecting to MASTERe MASTER <-> SLAVE sync: Finished with success. No meio, eu usei

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

Para obter uma estimativa grosseira da velocidade.
O SSH venceu por um longo tiro: ~ 11MB / s em comparação com o OpenVPN ~ 2MB / s.
Isso significa que tudo o que eu reaserched estava errado ou que eu configurei mal minha configuração?

Atualizar

Fiz vários testes com o mesmo conjunto de dados e obtive estes resultados:

• OpenVPN
  • TCP:
    compressão: 15m
    sem compressão: 21m
  • UDP:
    compressão: 5m
    sem compressão: 6m
• SSH
  padrão: 1m50s
  sem compressão: 1m30s
  de compressão: 2m30s

Update2

Aqui estão os resultados do iperf, com testes bidirecionais (exceto SSH, onde nenhum caminho de retorno está disponível)

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

Especificações técnicas

Estou executando o CentOS 6.3 (servidor), CentOS 6.5 (cliente).
A versão do OpenVPN é 2.3.2 (igual ao Ubuntu 14.10, portanto, não há versão mofada).
Meu encapsulamento SSH se parece com:

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

Meu arquivo de configuração se parece com:
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

Graças à kasperd 's comentário , eu aprendi que o SSH não sofre de TCP-sobre-TCP, uma vez que só se move dados do pacote. Eu escrevi um post sobre isso, mas o mais interessante é a netstatsaída, provando que o SSH de fato não preserva os dados da Camada 3,4:

após o tunelamento, 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
...

após tunelamento e conexão

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

Então, eu vou usar o encapsulamento SSH, pois parece que meu OpenVPN não está configurado incorretamente ou algo assim, apenas não é a ferramenta certa para o trabalho.

Depende do que você está tentando alcançar e quais são suas prioridades. A VPN conecta você a uma rede e o SSH a uma máquina. A VPN é um pouco mais segura com o encapsulamento, o que o SSH não faz.

Além disso, a VPN permite que todo o tráfego passe com facilidade, contra o SSH, onde você terá que forçar os aplicativos.

Você vai usar o AD? Porque a VPN permitirá que você faça isso com muito mais facilidade.

Prefiro o SSH para necessidades rápidas e a VPN para aplicativos críticos, onde devo poupar o tempo extra.

Dependendo da situação, usei o SSH em uma VPN, caso a VPN fosse comprometida. Dessa forma, alguém sondando teria que passar pelo tunelamento SSH.