Logiquement, VPN devrait être plus rapide que SSH pour le tunneling, car:
Cependant, aujourd'hui, j'ai testé la réplication Redis sur les deux méthodes.
J'ai exécuté le test sur une machine virtuelle AWS en Irlande, en me connectant à une machine virtuelle AWS USA-Est.
Puisque mon scénario de test est la réplication Redis, c'est exactement ce que j'ai testé - j'ai exécuté un serveur Redis vierge, et après avoir terminé le chargement, j'ai exécuté slaveof
l'autre serveur et mesuré le temps entre Connecting to MASTER
et MASTER <-> SLAVE sync: Finished with success
. Entre les deux, j'ai utilisé
while 1; do redis-cli -p 7777 info | grep master_sync_left_bytes;sleep 1; done
Pour obtenir une estimation brute de la vitesse.
SSH a gagné de loin: ~ 11 Mo/s par rapport à ~ 2 Mo/s d'OpenVPN.
Cela signifie-t-il que tout ce que j'ai réécrit était faux, ou ai-je grossièrement mal configuré ma configuration?
J'ai fait plusieurs tests avec le même ensemble de données et obtenu ces résultats:
Voici les résultats iperf, avec des tests bidirectionnels (sauf SSH, où aucun chemin de retour n'est 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 |
J'utilise CentOS 6.3 (serveur), CentOS 6.5 (client).
La version d'OpenVPN est 2.3.2 (identique à Ubuntu 14.10, donc pas de version moisie)
Mon tunneling SSH ressemble à:
ssh -f XXXX@XXXX -i XXXX -L 12345:127.0.0.1:12345 -N
Mon fichier de configuration ressemble à:
serveur
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
client
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
Grâce à kasperdcomment , j'ai appris que SSH ne souffre pas de TCP sur TCP car il ne déplace que les données des paquets. J'ai écrit un article de blog à ce sujet, mais le plus intéressant est la sortie netstat
, prouvant que SSH ne conserve en effet pas les données de la couche 3,4:
après tunneling, avant la connexion
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
...
après tunnelisation et connexion
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
...
Je vais donc utiliser le tunneling SSH, car il semble que mon OpenVPN ne soit pas mal configuré ou quoi que ce soit, tout simplement pas le bon outil pour le travail.
Cela dépend de ce que vous essayez d'atteindre et de vos priorités. VPN vous connecte à un réseau et SSH à une machine. Le VPN est un peu plus sécurisé avec l'encapsulation, ce que SSH ne fait pas.
De plus, le VPN permet à tout le trafic de le traverser facilement, par rapport à SSH où vous devrez forcer les applications.
Allez-vous utiliser AD du tout? Parce que le VPN vous permettra de le faire avec beaucoup plus de facilité.
Je préfère SSH pour les nécessités rapides et VPN pour les applications critiques où je devrais gagner du temps supplémentaire.
Selon la situation, j'ai utilisé SSH dans un VPN au cas où le VPN serait compromis. De cette façon, quelqu'un qui sonde devrait traverser le tunnel SSH.