SSHトンネリングはOpenVPNよりも高速です。


21

論理的に、VPNはトンネリングでSSHよりも高速である必要があります。理由は次のとおりです。

  • TCPではなくUDPで実行されているため(TCP over TCPはありません)
  • 圧縮されています

ただし、今日は両方の方法でRedisレプリケーションをテストしました。
アイルランドのAWS VMでテストを実行し、US-East AWS VMに接続しました。
私は空白のRedisのサーバーを実行し、それ仕上がっロードした後、私は実行-私のテストケースは、Redisのレプリケーションがあるので、これは私がテストした、まさにあるslaveof他のサーバを、との間の時間を測定 Connecting to MASTERしてMASTER <-> SLAVE sync: Finished with success。間に、私は使用しました

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

速度の大まかな見積もりを取得します。
SSHはロングショットで勝ちました:OpenVPNの〜2MB / sと比較して〜11MB / s。
それは、私が再調査したすべてが間違っていたことを意味しますか、それとも私はセットアップをひどく誤って構成しましたか?

更新

同じデータセットでいくつかのテストを行ったところ、次の結果が得られました。

  • OpenVPN
    • TCP:
      圧縮:15m
      圧縮なし:21m
    • UDP:
      圧縮:5m
      圧縮なし:6m
  • SSH
    デフォルト:1m50s
    圧縮なし:1m30s
    圧縮:2m30s

Update2

双方向テストでのiperfの結果を以下に示します(リターンパスが利用できないSSHを除く)

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

技術仕様

CentOS 6.3(サーバー)、CentOS 6.5(クライアント)を実行しています。
OpenVPNのバージョンは2.3.2(Ubuntu 14.10と同じなので、カビの生えたバージョンはありません)
SSHトンネリングは次のようになります。

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

私の設定ファイルは次のようになります
サーバー

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

クライアント

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は圧縮もサポートしているため、OpenVPNとSSHで必ずしも異なるものではありません。両側で圧縮を無効にしようとしましたか?OpenVPN経由で転送を実行するときは、クライアントまたはサーバーでtopまたは何かを実行します。VPN接続でCPU /メモリ/などを最大化している明らかな兆候はありますか?
ゾレダチェ14

2
AWSがホストするシステムではありそうにないようですが、UDPがレート制限などを受けている可能性はわずかです。OpenVPN over TCPを試しましたか?
ゾレダチェ14

4
sshの@Nitz TCPトンネルは、TCP over TCPを使用しません。実際、sshクライアントは通常、実行するのに十分な権限で実行されていません。いいえ、sshはTCPパケットに触れないため、パケットからTCPヘッダーを削除しません。sshは、他のアプリケーションと同様に、カーネル内のTCPスタックを利用する単なるアプリケーションです。データは、あるプログラムから1つのTCP接続を介してsshクライアントに移動します。sshクライアントはデータを暗号化し、TCP接続を介してサーバーに送信します。サーバーはそれを解読し、3番目のTCP接続を介して相手側のプログラムに送信します。
カスペルド14

2
確かに、OpenVPNには余分なIP / TCpヘッダーがあるため、もう少しオーバーヘッドがあるかもしれません。しかし、それによって4〜10倍の差が生じることはありません。差が5〜10%遅い範囲にあった場合、私はそれを非難したくなるかもしれません。あなたがまだ調査したい理由は、これは他の事柄にあまり明白でない方法で影響を与えているかもしれないいくつかの根本的な問題の徴候である可能性があるからです。
ゾレダチェ14

2
@Nitz正しく理解できれば、仮想インターフェイスに入力される暗号化されていないパケットは1424バイトですが、物理インターフェイスで送信される暗号化されたパケットは160バイトだけであると言っています。これは、VPNレイヤーまたはその下のUDP / IPレイヤーで非常に極端な断片化が発生していることを示します。それは確かにパフォーマンスの問題を説明できます。仮想インターフェイス上のパケットは、1300〜1400バイトのオーダーである必要があります。物理インターフェイス上のパケットは、1400〜1500バイトのオーダーである必要があります。
カスペルド14

回答:


7

kasperdコメントのおかげで、SSHはパケットデータのみを移動するため、TCP-over-TCPの影響を受けないことがわかりました。私はそれについてブログ記事を書きましたが、最も興味深いのはnetstat出力です。SSHが実際にレイヤー3,4データを保持しないことを証明しています:

トンネリング後、接続前

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

トンネリングと接続後

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

だから私はSSHトンネリングを使用するつもりです。なぜなら、私のOpenVPNが誤って設定されているわけでも、何でもないようで、仕事に適したツールではないからです。


3

それはあなたが何を達成しようとしているか、そしてあなたの優先事項が何であるかによります。VPNはユーザーをネットワークに接続し、SSHをマシンに接続します。VPNはカプセル化により少し安全ですが、SSHではできません。

また、VPNは、アプリケーションを強制する必要があるSSHとは対照的に、すべてのトラフィックが簡単に通過できるようにします。

ADを使用する予定はありますか?VPNを使用すると、はるかに簡単にこれを実行できるためです。

スピーディな必需品にはSSHを、余分な時間を割くべき重要なアプリケーションにはVPNを好みます。

状況によっては、VPNが侵害された場合に備えて、VPNでSSHを使用しました。この方法では、誰かが調査する際にSSHトンネリングを通過する必要があります。


2
トンネル上でredisを実行しているので、1つのポートで十分です。私はちょうどVPNトンネリングネットワークトラフィックのための最善の解決策常にではないという事実に驚いた
NITZ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.