Le tunneling SSH est plus rapide que OpenVPN, n'est-ce pas?

21

Logiquement, VPN devrait être plus rapide que SSH pour le tunneling, car:

  • Il fonctionne sur UDP et non sur TCP (donc pas de TCP sur TCP)
  • Il a une compression

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 US-East.
Étant donné que mon cas de test est la réplication Redis, c'est exactement ce que j'ai testé - j'ai exécuté un serveur Redis vierge, et une fois le chargement terminé, j'ai exécuté slaveofl'autre serveur et mesuré le temps entre Connecting to MASTERet 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.
Est-ce à dire que tout ce que j'ai réécrit était faux, ou ai-je grossièrement mal configuré ma configuration?

Mise à jour

J'ai fait plusieurs tests avec le même ensemble de données et obtenu ces résultats:

  • OpenVPN
    • TCP:
      compression: 15m
      pas de compression: 21m
    • UDP:
      compression: 5m
      pas de compression: 6m
  • Paramètres SSH par
    défaut: 1m50s
    sans compression: 1m30s
    compression: 2m30s

Update2

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       |

Spécifications techniques

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
Nitz
la source
3
SSH prend également en charge la compression, ce qui n'est pas nécessairement différent entre OpenVPN et SSH. Avez-vous essayé de désactiver la compression des deux côtés? Lorsque vous effectuez le transfert sur OpenVPN, exécutez top ou quelque chose sur votre client / serveur. Y a-t-il des signes évidents que vous maximisez votre CPU / mémoire / etc avec la connexion VPN?
Zoredache
2
Cela semble peu probable pour un système hébergé par AWS, mais il y a une petite possibilité que UDP obtienne un taux limité ou quelque chose. Avez-vous essayé de faire OpenVPN sur TCP?
Zoredache
4
Les tunnels TCP @Nitz dans ssh n'utilisent aucun TCP sur TCP. En fait, le client ssh est généralement exécuté avec des privilèges insuffisants pour le faire. Et non, ssh ne supprime aucun en-tête TCP des paquets, car il ne touche même jamais un paquet TCP. ssh n'est qu'une application utilisant la pile TCP du noyau, comme toute autre application. Les données transitent par une connexion TCP d'un programme au client ssh. Le client ssh crypte les données et les envoie via la connexion TCP au serveur. Le serveur le déchiffre et l'envoie via la troisième connexion TCP à un programme à l'autre bout.
kasperd
2
Bien sûr, il pourrait y avoir un peu plus de surcharge avec OpenVPN car il a les en-têtes IP / TCp supplémentaires. Mais cela ne devrait pas faire une différence de 4 à 10 fois plus lentement. Si la différence était de 5 à 10% plus lente, je serais tenté de blâmer cela. La raison pour laquelle vous voudrez peut-être continuer à enquêter est que cela pourrait être le symptôme d'un problème sous-jacent qui pourrait avoir un impact sur d'autres choses d'une manière moins évidente.
Zoredache
2
@ Nitz Si je vous comprends bien, vous dites que les paquets non chiffrés entrant dans l'interface virtuelle font 1424 octets, mais les paquets chiffrés envoyés sur l'interface physique ne sont que 160 octets. Cela indiquerait une fragmentation assez extrême se produisant au niveau de la couche VPN ou de la couche UDP / IP en dessous. Cela pourrait certainement expliquer le problème de performances. Les paquets sur l'interface virtuelle doivent être de l'ordre de 1300-1400 octets. Les paquets sur l'interface physique doivent être de l'ordre de 1400-1500 octets.
kasperd

Réponses:

7

Merci à kasperd de » commentaire , j'appris que SSH ne souffre pas de TCP sur TCP car il ne se déplace données par paquets. J'ai écrit un blog à ce sujet, mais la chose la plus intéressante est la netstatsortie, prouvant que SSH ne conserve en effet pas les données de la couche 3,4:

après tunnelisation, avant 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.

Nitz
la source
3

Cela dépend de ce que vous essayez de réaliser 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 épargner le 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 tunneling SSH.

rhymesy
la source
2
J'exécute redis sur le tunnel, donc un seul port me suffit. J'ai été simplement étonné par le fait que le VPN n'est pas toujours la meilleure solution pour la tunnellisation du trafic réseau
Nitz