SSH-Tunneling ist schneller als OpenVPN, könnte es sein?

VPN sollte für das Tunneln logischerweise schneller als SSH sein, weil:

• Es läuft auf UDP und nicht auf TCP (also kein TCP über TCP)
• Es hat Kompression

Heute habe ich jedoch die Redis-Replikation mit beiden Methoden getestet.
Ich habe den Test über eine AWS-VM in Irland durchgeführt und eine Verbindung zu einer AWS-VM in den USA hergestellt.
Da es sich bei meinem Testfall um die Redis-Replikation handelt, habe ich genau dies getestet: Ich habe einen leeren Redis-Server ausgeführt und nach dem Laden slaveofden anderen Server ausgeführt und die Zeit zwischen Connecting to MASTERund gemessen MASTER <-> SLAVE sync: Finished with success. Dazwischen habe ich benutzt

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

Um eine grobe Schätzung der Geschwindigkeit zu erhalten.
SSH hat bei weitem gewonnen: ~ 11MB / s im Vergleich zu OpenVPNs ~ 2MB / s.
Bedeutet das, dass alles, was ich neu erstellt habe, falsch war oder dass ich mein Setup grob falsch konfiguriert habe?

Aktualisieren

Ich habe mehrere Tests mit demselben Datensatz durchgeführt und die folgenden Ergebnisse erhalten:

• OpenVPN
  • TCP:
    Komprimierung: 15 m,
    keine Komprimierung: 21 m
  • UDP:
    Komprimierung: 5 m,
    keine Komprimierung: 6 m
• SSH- Standardeinstellungen
  : 1m50s,
  keine Komprimierung: 1m30s,
  Komprimierung: 2m30s

Update2

Hier sind die Iperf-Ergebnisse mit bidirektionalen Tests (außer SSH, wo kein Rückweg verfügbar ist).

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

Technische Daten

Ich verwende CentOS 6.3 (Server), CentOS 6.5 (Client).
OpenVPN-Version 2.3.2 (wie in Ubuntu 14.10, also keine Schimmel-Version)
Mein SSH-Tunneling sieht so aus:

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

Meine Konfigurationsdatei sieht aus wie:
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

Klient

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

Dank kasperd ‚s Kommentar , habe ich gelernt , dass SSH nicht von TCP-over-TCP leidet , da sie nur Paketdaten bewegt. Ich habe einen Blog-Beitrag darüber geschrieben, aber das Interessanteste ist die netstatAusgabe, die beweist, dass SSH tatsächlich keine Layer-3,4-Daten speichert:

nach dem tunneln, vor dem verbinden

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

nach dem Tunneln und Verbinden

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

Daher werde ich SSH-Tunneling verwenden, da mein OpenVPN anscheinend nicht falsch konfiguriert ist oder so, nur nicht das richtige Tool für den Job.

Es hängt davon ab, was Sie erreichen möchten und welche Prioritäten Sie setzen. VPN verbindet Sie mit einem Netzwerk und SSH mit einem Computer. VPN ist mit der Kapselung etwas sicherer, was SSH nicht tut.

Außerdem lässt VPN zu, dass der gesamte Datenverkehr problemlos durch das Netzwerk geleitet wird, im Gegensatz zu SSH, bei dem Sie die Anwendungen erzwingen müssen.

Wirst du überhaupt AD verwenden? Denn mit VPN können Sie das viel einfacher tun.

Ich bevorzuge SSH für schnelle Anforderungen und VPN für kritische Anwendungen, bei denen ich die zusätzliche Zeit sparen sollte.

Je nach Situation habe ich SSH in einem VPN verwendet, falls das VPN kompromittiert wurde. Auf diese Weise müsste jemand, der prüft, den SSH-Tunnel passieren.