Tunelowanie SSH jest szybsze niż OpenVPN, prawda?

Logicznie rzecz biorąc, VPN powinien być szybszy niż SSH do tunelowania, ponieważ:

• Działa na UDP, a nie TCP (więc nie TCP przez TCP)
• Ma kompresję

Jednak dzisiaj przetestowałem replikację Redis w obu metodach.
Przeprowadziłem test na maszynie wirtualnej AWS w Irlandii, łącząc się z maszyną AWS na wschodzie Stanów Zjednoczonych.
Ponieważ moim przypadkiem testowym jest replikacja Redis, dokładnie to przetestowałem - uruchomiłem pusty serwer Redis, a po zakończeniu ładowania slaveofuruchomiłem drugi serwer i zmierzyłem czas między Connecting to MASTERa MASTER <-> SLAVE sync: Finished with success. W międzyczasie użyłem

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

Aby uzyskać przybliżone oszacowanie prędkości.
SSH wygrał długim strzałem: ~ 11 MB / s w porównaniu do ~ 2 MB / s OpenVPN.
Czy to oznacza, że ​​wszystko, co powtórzyłem, było złe, czy też rażąco źle skonfigurowałem moją konfigurację?

Aktualizacja

Przeprowadziłem kilka testów z tym samym zestawem danych i uzyskałem następujące wyniki:

• OpenVPN
  • TCP:
    kompresja: 15m
    brak kompresji: 21m
  • UDP:
    kompresja: 5 m
    brak kompresji: 6 m
• 
  Domyślne wartości SSH : 1m50s
  brak kompresji: 1m30s
  kompresja: 2m30s

Aktualizacja 2

Oto wyniki iperf z testami dwukierunkowymi (oprócz SSH, gdzie nie jest dostępna ścieżka zwrotna)

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

Specyfikacja techniczna

Używam CentOS 6.3 (serwer), CentOS 6.5 (klient).
Wersja OpenVPN to 2.3.2 (tak samo jak w Ubuntu 14.10, więc nie ma wersji spleśniałej)
Moje tunelowanie SSH wygląda następująco:

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

Mój plik konfiguracyjny wygląda następująco:
serwer

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

Dzięki kasperd „s komentarza , dowiedziałem się, że SSH nie cierpi z TCP-over-TCP ponieważ tylko przenosi dane pakietowe. Napisałem o tym post na blogu , ale najciekawszą rzeczą jest netstatwynik, udowadniający, że SSH faktycznie nie zachowuje danych warstwy 3,4:

po tunelowaniu, przed podłączeniem

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

po tunelowaniu i podłączeniu

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

Więc użyję tunelowania SSH, ponieważ wydaje się, że moja OpenVPN nie jest źle skonfigurowana ani nic, tylko niewłaściwe narzędzie do tego zadania.

To zależy od tego, co próbujesz osiągnąć i jakie są twoje priorytety. VPN łączy Cię z siecią, a SSH z maszyną. VPN jest nieco bezpieczniejszy dzięki enkapsulacji, czego nie robi SSH.

Ponadto VPN pozwala na swobodny przepływ całego ruchu w porównaniu do SSH, w którym będziesz musiał wymusić aplikacje.

Czy w ogóle zamierzasz korzystać z AD? Ponieważ VPN pozwoli ci to zrobić o wiele łatwiej.

Wolę SSH do szybkich potrzeb i VPN do krytycznych aplikacji, w których powinienem poświęcić dodatkowy czas.

W zależności od sytuacji użyłem SSH w VPN na wypadek, gdyby VPN został naruszony. W ten sposób ktoś sondujący musiałby przejść przez tunelowanie SSH.