SSH tünel açma OpenVPN'den daha hızlıdır, öyle olabilir mi?


21

Mantıksal olarak, VPN tünel açma için SSH'den daha hızlı olmalıdır, çünkü:

  • UDP üzerinde çalışıyor ve TCP değil (TCP üzerinden TCP yok)
  • Sıkıştırma var

Ancak bugün Redis replikasyonunu her iki yöntemde de test ettim.
Testi bir ABD-Doğu AWS VM'sine bağlanan bir İrlanda AWS VM'si üzerinden yaptım.
Ben boş Redis sunucu karşılaştık ve bitmiş yükleme sonra ben idam - benim test case Redis çoğaltma olduğundan, bu ben test tam olarak ne slaveofdiğer sunucu ve arasındaki süreyi ölçülür Connecting to MASTERve MASTER <-> SLAVE sync: Finished with success. Arasında ben kullandım

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

Hızın kaba bir tahminini almak için.
SSH uzun bir atışta kazandı: OpenVPN'in ~ 2MB / s ile karşılaştırıldığında ~ 11MB / s.
Bu, yeniden yerleştirdiğim her şeyin yanlış olduğu veya kurulumumu fena halde yanlış yapılandırdığım anlamına mı geliyor?

Güncelleştirme

Aynı veri kümesiyle birkaç test yaptım ve şu sonuçları aldım:

  • OpenVPN
    • TCP:
      sıkıştırma: 15m
      sıkıştırma yok: 21m
    • UDP:
      sıkıştırma: 5m
      sıkıştırma yok: 6m
  • SSH
    varsayılanları: 1m50s
    sıkıştırma yok: 1m30s
    sıkıştırma: 2m30s

Update2

İki yönlü testlerle iperf sonuçları: (SSH hariç, geri dönüş yolunun olmadığı yerler)

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

Teknik özellikler

CentOS 6.3 (sunucu), CentOS 6.5 (istemci) kullanıyorum.
OpenVPN sürümü 2.3.2'dir (Ubuntu 14.10'dakiyle aynıdır, bu nedenle küflü sürüm yoktur)
SSH tünelim şöyle görünür:

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

Yapılandırma dosyam şuna benziyor:
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

müşteri

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

3
SSH de sıkıştırmayı destekler, bu nedenle OpenVPN ile SSH arasında mutlaka farklı bir şey olması gerekmez. Her iki tarafta da sıkıştırmayı devre dışı bırakmayı denediniz mi? OpenVPN üzerinden transfer gerçekleştirdiğinizde, istemcinizde / sunucunuzda en üste geçin. VPN bağlantınızla CPU / Bellek / vb. İşlemlerinizi en üst düzeye çıkardığınıza dair belirgin bir işaret var mı?
Zoredache

2
AWS tarafından barındırılan bir sistem için pek mümkün görünmüyor, ancak UDP'nin oranı sınırlandırması gibi bir şey var. TCP üzerinden OpenVPN yapmaya çalıştınız mı?
Zoredache

4
@Shsh TCP tünelleri TCP üzerinden herhangi bir TCP kullanmaz. Aslında, ssh istemcisi genellikle bunu yapmak için bile yetersiz ayrıcalıklarla çalışıyor. Ve hayır, ssh hiçbir TCP başlığını paketlerden çıkarmaz, çünkü hiçbir zaman bir TCP paketine bile dokunmaz. ssh, çekirdekteki TCP yığınını kullanarak, diğer uygulamalarda olduğu gibi sadece bir uygulamadır. Veriler, bir programdan ssh istemcisine bir TCP bağlantısı üzerinden geçer. Ssh istemcisi verileri şifreler ve sunucuya TCP bağlantısı üzerinden gönderir. Sunucu şifresini çözer ve üçüncü TCP bağlantısı üzerinden diğer uçtaki programa gönderir.
kasperd

2
Ekstra IP / TCp başlıklarına sahip olduğundan, OpenVPN'de biraz daha fazla yük olabileceğinden emin olabilirsiniz. Ancak bu 4-10 kat daha yavaş bir fark yaratmamalı. Fark% 5-10 daha yavaş aralıktaysa, bunu suçlamak için cazip gelebilirim. Halen araştırmak isteyebilmenizin nedeni, bunun başka şeyleri daha az açık bir şekilde etkileyebilecek altta yatan bir sorunun belirtisi olabileceğidir.
Zoredache

2
@Nitz Sizi doğru anlarsam, sanal arabirime giren şifrelenmemiş paketlerin 1424 bayt olduğunu, ancak fiziksel arabirime gönderilen şifreli paketlerin yalnızca 160 bayt olduğunu söylüyorsunuz. Bu, VPN katmanında veya altındaki UDP / IP katmanında gerçekleşen oldukça aşırı bir parçalanmaya işaret edecektir. Bu kesinlikle performans sorununu açıklayabilir. Sanal arabirimdeki paketlerin 1300-1400 baytlık bir sırada olması gerekir. Fiziksel arayüzdeki paketlerin 1400-1500 baytlık bir sırada olması gerekir.
kasperd

Yanıtlar:


7

Kasperd 'in yorumu sayesinde SSH'nin TCP üzerinden TCP'ye maruz kalmadığını öğrendim, çünkü yalnızca paket verilerini taşıyor . Bununla ilgili bir blog yazısı yazdım , ancak en ilginç şey netstatçıktı olduğunu; SSH'nin Katman 3,4 verilerini gerçekten korumadığını kanıtlıyor:

tünelden sonra, bağlamadan önce

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

tünelden ve bağlantıdan sonra

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

Bu yüzden SSH tünelini kullanacağım, çünkü OpenVPN'im yanlış yapılandırılmamış gibi görünüyor, fakat iş için doğru araç değil.


3

Neyi başarmaya çalıştığınıza ve önceliklerinizin ne olduğuna bağlı. VPN sizi bir ağa ve SSH'yi bir makineye bağlar. VPN, SSH'nin yapmadığı kapsülleme ile biraz daha güvenlidir.

Ayrıca VPN, uygulamaları zorlamanız gereken SSH'ye karşı tüm trafiğin kolayca geçmesini sağlar.

AD kullanacak mısın? Çünkü VPN bunu daha kolay bir şekilde yapmanıza izin verecek.

Hızlı ihtiyaçlar için SSH'yi ve fazladan zaman ayırmam gereken kritik uygulamalar için VPN'i tercih ediyorum.

Duruma bağlı olarak, VPN'nin tehlikeye girmesi ihtimaline karşı SSH'yi VPN'de kullandım. Bu şekilde sondalama yapan birinin SSH tünelinden geçmesi gerekir.


2
Tünel üzerinde kırmızılar akıyor, bu yüzden tek bir liman bana yetiyor. VPN'in ağ trafiğini tünellemek için her zaman en iyi çözüm olmadığı gerçeğine şaşırmıştım
Nitz
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.