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

21

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
Nitz
quelle
3
SSH unterstützt auch die Komprimierung, sodass sich OpenVPN und SSH nicht unbedingt voneinander unterscheiden. Haben Sie versucht, die Komprimierung auf beiden Seiten zu deaktivieren? Wenn Sie die Übertragung über OpenVPN durchführen, führen Sie top oder etwas auf Ihrem Client / Server aus. Gibt es offensichtliche Anzeichen dafür, dass Sie mit der VPN-Verbindung Ihre CPU / Ihren Arbeitsspeicher / usw. auslasten?
Zoredache
2
Es scheint unwahrscheinlich für ein AWS-gehostetes System zu sein, aber es gibt eine kleine Möglichkeit, dass UDP eine begrenzte Geschwindigkeit erhält oder so. Haben Sie versucht, OpenVPN über TCP zu betreiben?
Zoredache
4
@Nitz TCP-Tunnel in ssh verwenden kein TCP über TCP. Tatsächlich wird der ssh-Client normalerweise mit unzureichenden Berechtigungen ausgeführt, um dies überhaupt zu tun. Und nein, ssh entfernt keine TCP-Header aus Paketen, da es niemals ein TCP-Paket berührt. ssh ist nur eine Anwendung, die wie jede andere Anwendung den TCP-Stack im Kernel nutzt. Daten werden über eine TCP-Verbindung von einem Programm zum SSH-Client übertragen. Der ssh-Client verschlüsselt die Daten und sendet sie über die TCP-Verbindung an den Server. Der Server entschlüsselt es und sendet es über die dritte TCP-Verbindung an ein Programm am anderen Ende.
Kasperd
2
Klar, dass OpenVPN möglicherweise etwas mehr Aufwand verursacht, da es über zusätzliche IP / TCp-Header verfügt. Das sollte aber keinen Unterschied von 4-10 mal langsamer machen. Wenn der Unterschied im Bereich von 5-10% niedriger wäre, könnte ich versucht sein, dies zu tadeln. Der Grund, den Sie möglicherweise noch untersuchen möchten, ist, dass dies ein Symptom für ein zugrunde liegendes Problem sein kann, das andere Dinge auf eine weniger offensichtliche Weise beeinflusst.
Zoredache
2
@Nitz Wenn ich Sie richtig verstehe, sagen Sie, dass die unverschlüsselten Pakete, die in die virtuelle Schnittstelle eingehen, 1424 Byte groß sind, die verschlüsselten Pakete, die über die physische Schnittstelle gesendet werden, jedoch nur 160 Byte. Dies würde auf eine ziemlich extreme Fragmentierung hinweisen, die auf der VPN-Ebene oder der darunter liegenden UDP / IP-Ebene auftritt. Das könnte sicherlich das Leistungsproblem erklären. Die Pakete auf der virtuellen Schnittstelle sollten in der Größenordnung von 1300 bis 1400 Bytes liegen. Die Pakete auf der physischen Schnittstelle sollten in der Größenordnung von 1400-1500 Bytes liegen.
Kasperd

Antworten:

7

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.

Nitz
quelle
3

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.

Reim
quelle
2
Ich laufe redis über den Tunnel, also reicht mir ein einziger Port. Ich war nur erstaunt darüber, dass VPN nicht immer die beste Lösung für das Tunneln des Netzwerkverkehrs ist
Nitz,