画像やリンクが無効になっている可能性もあるのでご了承下さい。
筆者は当初、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 の速度テストを行うコマンド ((openssl speed aes-256-gcm と openssl speed aes-256-cbc の結果)) 上では CBC の方が高速な結果が得られたが、そう単純なお話しでは無かったということで。
また VPN を経由しない ASAHI ネット直のスループットは午前中の空いている時間というだけあって爆速だった。GMO の方は画像を残し忘れたが UP/DL 共に 200Mbps は出ていたので、回線に問題は無い。
スループットを左右するのは回線と CPU という事で
サーバー/クライアント共に暗号化する為のエンコードやデコードに CPU パワーが必要とされるので、必然とデスクトップで用いられる CPU よりも非力なスマートフォンだと、どうしてもスループットが低下してしまうという事が分かった。
CPU も出来れば AE-SNI に対応したモデルを選ぶと AES 系の暗号化/復号の速度が何倍にも跳ね上がるので少し気を使いたいかも。改めて Core i3-550 のデータシートを見る限り非対応なのでこの辺も足を引っ張るのかな。
コメント