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
- TCP:
- 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
fonte
Respostas:
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
após tunelamento e conexão
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.
fonte
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.
fonte