Tunneling SSH lebih cepat dari OpenVPN, mungkinkah?

Secara logis, VPN harus lebih cepat daripada SSH untuk tunneling, karena:

Ini berjalan pada UDP dan bukan TCP (jadi tidak ada TCP melalui TCP)
Ini memiliki kompresi

Namun, hari ini saya menguji replikasi Redis atas kedua metode.
Saya menjalankan tes melalui VM AWS Irlandia, menghubungkan ke AS-Timur AWS VM.
Karena test case saya adalah replikasi Redis, inilah yang saya uji - saya menjalankan server Redis kosong, dan setelah selesai memuat, saya mengeksekusi slaveofserver lain, dan mengukur waktu antara Connecting to MASTERdan MASTER <-> SLAVE sync: Finished with success. Di antara, saya menggunakan

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

Untuk mendapatkan estimasi kasar kecepatan.
SSH dimenangkan oleh pukulan panjang: ~ 11MB / s dibandingkan dengan OpenVPN ~ 2MB / s.
Apakah itu berarti bahwa semua yang saya ulangi salah, atau sudahkah saya salah mengonfigurasi pengaturan saya?

Memperbarui

Saya telah membuat beberapa tes dengan dataset yang sama, dan mendapatkan hasil ini:

OpenVPN
- TCP:
  kompresi: 15m
  tanpa kompresi: 21m
- UDP:
  kompresi: 5m
  tanpa kompresi: 6m
SSH
default: 1m50s
ada kompresi: 1m30s
kompresi: 2m30s

Pembaruan2

Berikut adalah hasil iperf, dengan tes dua arah (kecuali SSH, di mana tidak ada jalur balik yang tersedia)

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

Spesifikasi teknis

Saya menjalankan CentOS 6.3 (server), CentOS 6.5 (klien).
Versi OpenVPN adalah 2.3.2 (sama seperti di Ubuntu 14.10, jadi tidak ada versi berjamur)
tunneling SSH saya terlihat seperti:

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

File konfigurasi saya terlihat seperti:
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

klien

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

networking ssh openvpn

— Nitz
sumber

SSH mendukung kompresi juga, jadi itu tidak selalu sesuatu yang berbeda antara OpenVPN dan SSH. Sudahkah Anda mencoba menonaktifkan kompresi di kedua sisi? Ketika Anda melakukan transfer melalui OpenVPN, jalankan top atau sesuatu di klien / server Anda. Apakah ada tanda-tanda yang jelas bahwa Anda memaksimalkan CPU / Memory / etc dengan koneksi VPN?

— Zoredache

Tampaknya tidak mungkin untuk sistem yang di-host AWS, tetapi ada kemungkinan kecil bahwa UDP mendapatkan tingkat yang terbatas atau sesuatu. Sudahkah Anda mencoba melakukan OpenVPN melalui TCP?

— Zoredache

@Nitz Terowongan TCP di ssh tidak menggunakan TCP apa pun melalui TCP. Sebenarnya klien ssh biasanya dijalankan dengan hak istimewa yang tidak mencukupi untuk melakukannya. Dan tidak, ssh tidak menghapus header TCP dari paket, karena ia bahkan tidak pernah menyentuh paket TCP. ssh hanyalah aplikasi yang memanfaatkan TCP stack di kernel, seperti aplikasi lainnya. Data bergerak melalui satu koneksi TCP dari beberapa program ke klien ssh. Klien ssh mengenkripsi data dan mengirimkannya melalui koneksi TCP ke server. Server mendekripsi dan mengirimnya melalui koneksi TCP ketiga ke sebuah program di ujung lainnya.

— kasperd

Tentu mungkin ada overhead yang sedikit lebih dengan OpenVPN karena memiliki header IP / TCp ekstra. Tapi itu seharusnya tidak membuat perbedaan 4-10 kali lebih lambat. Jika perbedaannya dalam kisaran 5-10% lebih lambat saya mungkin tergoda untuk menyalahkan itu. Alasan Anda mungkin masih ingin menyelidiki adalah bahwa ini bisa menjadi gejala dari beberapa masalah mendasar yang mungkin berdampak pada hal-hal lain dengan cara yang kurang jelas.

— Zoredache

@Nitz Jika saya mengerti Anda dengan benar, Anda mengatakan bahwa paket yang tidak terenkripsi yang memasuki antarmuka virtual adalah 1424 byte, tetapi paket yang dienkripsi mengirim pada antarmuka fisik hanya 160 byte. Itu akan menunjukkan fragmentasi yang cukup ekstrim terjadi pada lapisan VPN atau lapisan UDP / IP di bawahnya. Itu tentu bisa menjelaskan masalah kinerja. Paket-paket pada antarmuka virtual harus ada sesuatu di urutan 1300-1400 byte. Paket-paket pada antarmuka fisik harus berupa sesuatu pada urutan 1400-1500 byte.

— kasperd

Jawaban:

Berkat kasperd 's komentar , saya belajar bahwa SSH tidak menderita dari TCP-over-TCP karena hanya bergerak data paket. Saya menulis posting blog tentang hal itu, tetapi hal yang paling menarik adalah netstathasilnya, membuktikan bahwa SSH memang tidak menyimpan data Layer 3,4:

setelah tunneling, sebelum menghubungkan

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

setelah tunneling dan menghubungkan

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

Jadi saya akan menggunakan tunneling SSH, karena tampaknya OpenVPN saya tidak terkonfigurasi atau apa pun, hanya saja bukan alat yang tepat untuk pekerjaan itu.

— Nitz
sumber

Itu tergantung apa yang Anda coba capai dan apa prioritas Anda. VPN menghubungkan Anda ke jaringan dan SSH ke mesin. VPN sedikit lebih aman dengan enkapsulasi, yang tidak dilakukan SSH.

Juga, VPN memungkinkan semua lalu lintas dengan mudah melewatinya, versus SSH di mana Anda harus memaksa aplikasi.

Apakah Anda akan menggunakan AD sama sekali? Karena VPN akan membiarkan Anda melakukannya dengan lebih mudah.

Saya lebih suka SSH untuk kebutuhan cepat dan VPN untuk aplikasi penting di mana saya harus meluangkan waktu ekstra.

Tergantung pada situasinya, saya telah menggunakan SSH dalam VPN jika VPN itu dikompromikan. Dengan cara ini seseorang yang menyelidik harus melewati penerobosan SSH.

— berima
sumber

Saya menjalankan redis di atas terowongan, jadi satu port sudah cukup bagi saya. Saya hanya kagum dengan kenyataan bahwa VPN tidak selalu merupakan solusi terbaik untuk tunneling jaringan traffic

— Nitz