OpenVPN のスループットを Windows10 から計測する

本記事は最終更新日より 1 年以上経過しております。
スポンサーリンク

 筆者は当初、Android 端末からの利用を目的として OpenVPN による VPN 環境を構築し、検証もしてきた。
 ここに来てクライアントがスマートフォンよりも CPU パワーがあったり 1Gbps でリンクする NIC だった場合にはどうなるだろうかと気になったのでちょっとスループットを計測してみた。

検証環境

  • サーバー側 : CentOS 7 (CPU Intel Core i3-550, Mem 8GB), OpenVPN 2.4.0 (cipher AES-256-GCM)
  • クライアント側 : Windows10, OpenVPN GUI Client (CPU AMD FX-8350@4.2GHz, Mem 16GB)

接続方法

 クライアント側は Windows10 より PPPoE ブリッジにて GMO とくとく BB へ接続。
 サーバー側は常時 ASAHI ネットに接続されている。
 この状態でクライアント側からサーバーに向かって VPN 接続をする変態的な環境となる。

 Client ==(PPPoE Bridge)==> [GMO] ==> the Internet ==> [ASAHI] ==> Router ==> Server

 大まかにこの様な感じで手元にマシンは全てあるけど、パケットは一旦インターネットに向かって出ていって別経路で戻ってくると。

SpeedTest で計測

 Android 端末からの接続だと Wi-Fi だろうがキャリア回線だろうが DL:20~24Mbps 程だったが、やはり暗号のデコードやらで CPU パワーを使う分だけ SoC の性能が足かせになっていたのだろう。
 CPU パワーのあるデスクトップマシンで接続すると DL/UP 共に 80Mbps は出るようだ。十分な速度だ。
 また、cipher のパラメータを変更し AES-256-CBC に切り替えたらこの速度よりも 10Mbps 前後の低下が見られた。openssl の速度テストを行うコマンド*1 上では CBC の方が高速な結果が得られたが、そう単純なお話しでは無かったということで。

 また VPN を経由しない ASAHI ネット直のスループットは午前中の空いている時間というだけあって爆速だった。GMO の方は画像を残し忘れたが UP/DL 共に 200Mbps は出ていたので、回線に問題は無い。

スループットを左右するのは回線と CPU という事で

 サーバー/クライアント共に暗号化する為のエンコードやデコードに CPU パワーが必要とされるので、必然とデスクトップで用いられる CPU よりも非力なスマートフォンだと、どうしてもスループットが低下してしまうという事が分かった。
 CPU も出来れば AE-SNI に対応したモデルを選ぶと AES 系の暗号化/復号の速度が何倍にも跳ね上がるので少し気を使いたいかも。改めて Core i3-550 のデータシートを見る限り非対応なのでこの辺も足を引っ張るのかな。

スポンサーリンク
  1. openssl speed aes-256-gcm と openssl speed aes-256-cbc の結果 []