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

Question

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

• Ele está sendo executado no UDP e não no TCP (portanto, nenhum TCP sobre TCP)
• Tem compactação

No entanto, hoje testei a replicação Redis nos dois métodos.
Fiz o teste em uma VM da Irlanda AWS, conectando-me a uma VM da AWS nos EUA.
Como o meu caso de teste é a replicação do Redis, foi exatamente isso que testei - executei um servidor Redis em branco e, após o carregamento, executei slaveof do outro servidor e medi o tempo entre Connecting to MASTER e 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 aproximada da velocidade.
SSH ganhou por um longo tiro: ~ 11MB / s em comparação com ~ 2MB / s do OpenVPN.
Isso significa que tudo o que eu criei estava errado, ou eu mal configurei minha configuração?

Atualizar

Eu 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ões: 1m50s
  sem compressão: 1m30s
  compactaçã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 rodando o CentOS 6.3 (servidor), o CentOS 6.5 (cliente).
Versão OpenVPN é 2.3.2 (mesmo que no Ubuntu 14.10, então não há versão mofada)
Meu tunelamento 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: 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

    

Answer 1

Graças ao -tunneling-is-faster-than-openvpn-could-it-be # comment793509_653211 "> comentário , eu aprendi que o SSH não sofre de TCP-over-TCP, uma vez que apenas move dados de pacote. Eu escrevi uma postagem no blog sobre isso, mas o mais interessante é a saída netstat , provando que SSH na verdade 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 o tunelamento e a 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, vou usar o tunelamento SSH, já que parece que meu OpenVPN não está configurado incorretamente nem nada, mas não a ferramenta certa para o trabalho.

    

Answer 2

Depende do que você está tentando alcançar e quais são suas prioridades. VPN conecta você a uma rede e 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 facilmente por ela, em comparação com 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.

Eu prefiro SSH para necessidades rápidas e VPN para aplicações críticas onde eu deveria poupar o tempo extra.

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