現代はあらゆる情報がディジタル化され手持ちのパーソナルコンピュータを用いることで、その情報を参照することが可能になっている。インターネットが著しく普及したことで、いつ、どこにいても必要な情報を手に入れることができるようにもなっている。しかし同時にセキュリティに関する懸念も高まっている。 現在、社外から社内ネットワークに安全にアクセスしたり、各支店間に仮想的で安全なネットワークを構築できるバーチャルプライベートネットワーク(VPN)が普及してきている。しかしVPNの方式は多数存在し、それぞれ特徴が異なっている。 本研究では数々のVPN方式に対し、その通信性能や利用の容易さを調査することで各VPN方式の性能評価を行うことが目的である。
VPNとはインターネット回線などの多くの人が共有して使用する公共ネットワーク上で、認証技術や暗号化技術、トンネリング技術などを用いて、プライベートネットワークを仮想的に構築する技術である。
プライベートネットワークとは公共ネットワークから直接にアクセスすることができないネットワークである。プライベートネットワーク内に存在する端末やサービスにアクセスするには、基本的にそのプライベートネットワークに接続している必要がある。プライベートネットワークは、外部ネットワークである公共ネットワークから直接アクセスすることができないので、プライベートネットワーク内で端末間を流れる情報やサービスによって提供される情報は外部から盗聴されたり改ざんされたりすることがない安全なネットワークである。公共ネットワークからアクセスする場合には何らかの中継サーバーを介する必要がある。
純粋なプライベートネットワークとしては通信業者の提供する専用線などのサービスがある。これは依頼者が指定した拠点間に他のネットワークとは独立した回線を設置し、その依頼者のみが使用する。外部のネットワークと接続されていないので、情報が盗聴されたり改ざんされたりすることはない。また回線を独占して利用するので通信帯域も保証される。ただし専用の回線を用意するため、初期導入費用やランニングコストが高価である。
VPNの場合、公共ネットワークを間借りしてプライベートネットワークを構築する。このとき認証技術と暗号技術を用いることで、専用線に近い安全な仮想ネットワークを構築できる。共有回線を利用するので、初期導入費用やランニングコストが安価であるが、インターネット回線を利用したVPNの場合、回線帯域は保証されない。
VPNを実現するために必要な技術の一つにトンネリングがある。これは仮想プライべートネットワークで転送するパケットに新たに他のプロトコルヘッダを付加し、公共ネットワークで転送することができるようにするのが目的である。これをカプセル化という。カプセル化することで公共ネットワーク上に独立した仮想的な伝送路であるトンネルを作り出し、トンネルの端の端末同士があたかも直接接続されている様に振る舞わせることができる。現行の公共ネットワークはIPv4で構築されているので、トンネリングに用いるプロトコルはIPv4であることが一般的である。一方、トンネリングされるプロトコルおよびプロトコルレイヤーはVPNの種類によって異なる。どのプロトコルレイヤーをカプセル化するかによって利点や欠点が異なる。
VPNでは実際のネットワークの構造に縛られることなく仮想プライベートネットワークを構成できる。このため通常のネットワークと異なる流れで相手にパケットを送る仕組みが必要である。
ここで様々なVPN方式を分類するために、カプセル化するネットワークレイアに着目する。
ネットワークレイアには、物理層(レイア1)、データリンク層(レイア2)、ネットワーク層(レイア3)、トランスポート層(レイア4)などがある。インターネットはOSI参照モデルによるプロトコル階層モデルとは異なり通常はセッション層(レイア5)とプレゼンテーション層(レイア6)の区別がない。通常、インターネットの利用によりアプリケーションプロトコルがカプセル化されるのはアプリケーションゲートウェイやプロキシと呼ばれ、これは本研究の対象範囲外である。VPNは仮想プライベートネットワークなので物理層(レイア1)は除く。よってVPNはレイア2以上の接続を仮想的に実現するものである。
どのレイアを仮想化するかで実現できる通信は異なる。例えば、アプリケーション同士を接続し通信させるだけでよいのならば、ネットワークソケットを直接接続させればよいので、ソケットを実装しているトランスポート層(レイア4)同士を仮想的に接続すればよい。一方、プライベートネットワーク自体を仮想的に接続するのであれば、Layer2ネットワーク上に流れるパケットを再現しなければならない。このためにはデータリンク層(レイア2)を仮想化して接続する必要がある。
表1は仮想的に接続するレイアとその特性をまとめたものである。
階層 | 特性 |
---|---|
レイア2(データリンク層) |
|
レイア3(ネットワーク層) |
|
レイア4(トランスポート層) |
|
VPNは既存のプロトコルを通常とは異なる方式で接続することで実現される。そのため基本的なネットワークプロトコルの組み合わせに加えて、異なる方式で接続する役割を担う特定のプロトコルも利用する。
この節ではVPN特有のプロトコルを説明し、次節で基本的なネットワークプロトコルを説明する。
IP tunnelingは内部ネットワーク用のIPパケットに外部用のIPパケットで直接カプセル化することで、他のネットワーク経由で転送可能にするためのトンネリング技術である。
GREはトンネルプロトコルであり、トランスポート層のプロトコルである。IPに限らず様々なパケットをカプセル化するために開発された。
PPPは電話回線を通じてコンピュータをネットワークに接続するダイヤルアップ接続でよく使われるプロトコルである。データリンク層のプロトコルであり、PPPはリンク制御プロトコルによってユーザー認証、接続を確立、切断を管理する。接続を確立した後、ネットワーク制御プロトコルによって上層プロトコルであるネットワーク層のプロトコルに必要な設定を行う。PPPはIPだけでなく、AplleTalk、NetBEUIなどIP以外のネットワーク層のプロトコルもカプセル化し転送する。また将来的に新しいプロトコルをサポートすることもできる。
PPPには上記にあげた様々な機能を搭載しているが、VPNで使用されるのは主にプロトコルの送受信の仕組みの部分である。
インターネット上で情報を暗号化して送受信するプロトコル。トランスポート層(第4層)に属するTCPプロトコルの上層で動作する。元々はHTTPプロトコルを暗号化するために利用されたものであるが、現在は様々なプロトコルを暗号化できる。SSLは公開鍵暗号や秘密鍵暗号、デジタル証明書、ハッシュ関数などのセキュリティ技術を組み合わせ、データの盗聴や改ざん、なりすましを防ぐことができる。SSLは暗号化された安全なトンネルを構築し、HTTPやFTPなどの上位のプロトコルを利用するアプリケーションソフトからは、特に意識することなく透過的に利用することができる。
VPNで利用される場合、セキュリティで保護されたトンネルを構築するのに用いられる。
ここでは、基本的なプロトコルを紹介するとともにそのプロトコルに関連する技術や背景を紹介する。
Ethernetは一般的に用いられているLAN規格である。物理層とデータリンク層を規定している。物理層ではデータリンク層で形成されたMACフレームを電気的に伝送するためのルールが定められている。データリンク層では通信を行う際のMACフレームの解釈に関するルールが定められている。LANではそれぞれの端末にMACアドレスというアドレスが割り当てられている。MACフレームのヘッダには送信元と送信先のMACアドレスと上位のプロトコルの種類が記述される。MACフレームを受信した端末はフレームに記述されている宛先MACアドレスが自分宛であれば受け取り、そうでなければ破棄する。MACフレームのペイロード部分には上層プロトコルであるネットワーク層のプロトコルが収容される。
IPはネットワーク層に位置し、ネットワークに参加している機器の住所付け(アドレッシング)や、相互に接続された複数のネットワーク内での通信経路の選定(ルーティング)をするための方法を定義している。コネクションレス型のプロトコルであるため、確実にデータが届くかどうかは保証されない。データ到達の保証するためには、上位層でTCPを用いる。ネットワーク層のプロトコルとしてIPversion4(以後IPv4)は現在世界でもっとも普及している。IPによって世界規模で相互に接続された巨大なコンピュータネットワークをインターネットと呼ぶ。
インターネット上では各端末に世界で唯一無二のグローバルアドレスを割り当ててネットワークを構成する。一方、インターネットには直接接続しない端末には、そのネットワーク内では唯一無二のプライベートアドレスを割り当てて構成する。
プライベートアドレスを割り当てられた端末がインターネット上の端末にアクセスするとき、NATを用いる。NATは数の少ないグローバルIPアドレスを複数のコンピュータで共有する技術である。プライベートアドレスを持つ端末がインターネットにアクセスするとき、NATがプライベートアドレスとグローバルアドレスを透過的に相互変換する。これにより、グローバルアドレスを持たない端末もインターネットにアクセスできるようになる。不足がちなグローバルアドレスを節約することができるが、同時に通信できるのは、割り当てられたグローバルアドレスの数都道等の端末数だけである。インターネット側から内部ネットワークにアクセスするためには、別途設定が必要である。また、一部のアプリケーションソフトが正常に動作しなくなるなどの制約がある。
NAPTはNATのようにグローバルアドレスとプライベートアドレスを相互変換するが、同時にTCP/UDPのポート番号まで動的に変換される。そのため一つしかグローバルアドレスが割り当てられていない場合でも複数のマシンから同時に接続することが可能である。ただし、ポート番号の変換を行うため、TCPやUDP以外のトランスポート層のプロトコルを用いた通信には利用できない。「IPマスカレード」と表記されたり、場合によっては「NAT」と表記していることもある。
TCPはインターネットで利用されるトランスポート層の標準プロトコルである。ネットワーク層のIPと、セッション層以上のプロトコル(HTTP、FTP、SMTP、POPなど)の橋渡しをする。IPはパケットが相手に到達したかどうかは保証されないコネクションレスプロトコルである。この欠点を補いTCPはパケットが相手に正常に送信されたかを保証するコネクション型プロトコルである。通信を保証するためのパケットが届いたことを送信元に知らせるACKパケットが別途転送されるため、データの転送効率は多少低くなる。
トンネルを構築する際にTCPを用いるVPN方式がいくつか存在する。このときトンネル内でさらにTCPを用いると「TCP over TCP問題」が発生する。「TCP over TCP問題」とはトンネル外のTCPとトンネル内のTCPが個別に通信の信頼性を維持しようとすることで発生する。
TCPは送信先からACKパケットを受信することでデータパケットが正常に転送されたことを確認する。TCPにはタイムアウト値が設定され、タイムアウト前にACKパケットが返ってこないと、データパケットは正常に到達していないと見なし、再送信を試みる。このときタイムアウト値はより長く設定を修正される。
トンネルを構築するTCPとトンネル内のTCPでは通常、構築する側のTCPの方がタイムアウト値が長い。これは構築する側のTCPが通信環境に合わせて適切なタイムアウト値で安定化しているからである。一方トンネル内のTCPはコネクションが生成されたばかりであり、タイムアウト値は小さめに設定される。このとき構築する側のTCPでパケットの欠落が起きたとする。構築する側のTCPは再送を開始するが、トンネル内のTCPはタイムアウト値が小さいので、より頻繁に再送を行う。構築する側のTCPはデータパケットが正常に到着するまでトンネル内のプロトコルにデータパケットを提供しないため、トンネル内のTCPではいつまでたってもデータを転送できなくなりコネクションが切断されてしまう。
よってTCPにTCPを重ねて使用することは無用な輻輳を誘発するためよくないとされている。
UDPインターネットで利用されるトランスポート層の標準プロトコルである。ネットワーク層のIPと、セション層以上のプロトコルの橋渡しをする。TCPとは異なりパケットが相手に届いたかどうかは保証されないコネクションレスプロトコルであるが、通信効率や遅延に対する性能はTCPより有利である。また、UDPではブロードキャスト通信やマルチキャスト通信などのIPプロトコルの機能を利用できる。
HTTPはWebサーバとWebブラウザなどのクライアントがデータを送受信するのに使われるアプリケーション層のプロトコルである。HTML文書や、文書に関連付けられている画像、音声、動画などのファイルを、表現形式などの情報を含めてやり取りするのが目的である。HTTPは下層レイアのプロトコルにTCPを用いることが前提で設計されている。
HTTPSとはSSLによって暗号化されたトンネル内でHTTP通信を行うプロトコルのことである。HTTP over SSLとも表現される。主にウェブページ上でユーザー名やパスワード、クレジットカード番号やその他の個人情報など、他人に知られては困る情報の通信をしなければならない場合に用いられる。トンネル内でやりとりされるHTTP通信はSSLによって暗号化や改ざん検出などが行われる。
プロキシサーバーとは外部と直接通信ができないプライベートネットワーク内に存在する端末に代わって代理で公共ネットワークとの通信を行うサーバーのことである。HTTP通信に関してプロキシとして動作するサーバーを特にHTTPプロキシサーバーという。HTTPクライアントはプロキシサーバーに接続をし、プロキシサーバーはクライアントの要求した接続先へ接続を行う。HTTPプロキシサーバーは、プロキシ経由のHTTP通信を一元管理することができ、アクセスを許可しないサイトなどを指定することもできる。
HTTPS通信をサポートしたプロキシサーバーもある。これはクライアントが指定した接続先にHTTPSプロトコルをトンネリングして通信することで実現される。
ホテルなどで公衆ネットワークに接続しインターネットに接続できるサービスを提供している施設がある。ただしこのような施設ではインターネットへの接続が制限されている場合がある。具体的にはHTTP通信やHTTPS通信しか許可されてないネットワークなどがある。このような制限のあるネットワークではウェブブラウザによる通信以外は行えない。また、ブラウザによるHTTP通信やHTTPS通信に関してもプロキシサーバー経由でないと外部との通信が行えない環境もある。
ここでは数あるVPN方式をカプセル化するレイアによって分類する。接続するレイアによってカプセル化するプロトコルは異なる。そのため、各VPN方式の説明とともに図でカプセル化されたパケットを再現している。背景が白のパケットは公共ネットワークを流れるプロトコルを意味し、背景が灰色のパケットは仮想プライベートネットワーク内を流れるプロトコルを意味する。
なおVPNはカプセル化するレイアはいくつか存在するが、カプセル化したパケットを転送するのはほとんどの場合IPである。これは、IPで構成されるインターネットを利用して仮想プライベートネットワークを構築することを前提としているためである。
ここではレイヤー3(主にIP)をカプセル化するVPNの方式を紹介する。
Layer3VPNではVPNトンネルをルーター上の一つの経路として取り扱う。プライベートネットワーク内からルータに対し、もう一方のプライベートネットワーク宛のIPパケットが到着すると、ルータはIPパケットをカプセル化しVPN接続先のルータへ送る。このパケットを受信した相手側のルータはカプセル化を解除しIPパケットを元の宛先へ送る。この様に、VPNトンネルを作っているルータは、VPNトンネルを相手先のプライベートネットワーク専用の経路として取り扱う。
プライベートネットワークでの通信のためのIPパケットを公共ネットワークでの通信のためのIPパケットでカプセル化し、公共ネットワークを介してプライベートネットワーク同士の通信をする方法である。この方法はプロトコルスタックがシンプルであり、カプセル化による通信データのオーバーヘッドは少ない。しかし、IP自体にはセキュリティに関する対策がないため、各アプリケーションが通信セキュリティ対策をしていないと盗聴や改ざんの可能性がある。
IP in IP tunnelingと比べ、よりカプセル化に特化したプロトコルである。各トンネルに固有のKeyを識別することで、明示的に複数のトンネルを同時に通信させることができる。GREは後に説明するPPTPにも採用されている。
GRE(47番)はTCP(6番)やUDP(17番)による通信ではないので、ポートという概念がない。そのため一般的なNAPTを介した通信ができない。また、GRE自体には暗号化や改ざん防止機能は搭載されていない。この場合、後述するIPsecのトランスポートモードを併用することで暗号化や改ざん防止機能を付加する方法が一般的に用いられている。
IPsecはIPにセキュリティを付加するためのプロトコル群のことを言う。IPv6では標準で搭載されている。またIPv4でも利用可能である。IPsecではPayload部を暗号化して送信するトランスポートモードと、IPパケットごと暗号化して公共ネットワークでの通信用のIPヘッダを付加するトンネルモードがある。主にVPNで用いる場合、トランスポートモードを用いて通信を行う。
もともと改ざんや盗聴に対する対策を提供するプロトコルなので、多数の暗号化方式やセキュリティプロトコルの種類を選択して利用することで、安全な通信が確保できる。しかし、設定可能な組み合わせが多く、通信する相手と設定が同一でなければ通信が成立しない。また、IPsecは単一のプロトコルを指すわけではなく、主に認証や暗号化、改ざん防止を担当するプロトコルと暗号化に必要な鍵を交換するプロトコルに分かれている。このプロトコルと入れ替えることで新しい機能や強固な暗号技術を用いることが可能なのがIPsecの一つの利点であるが、プロトコルが多数存在し設定可能なプロトコルの組み合わせが膨大であり、各端末のプロトコルの組み合わせが一致してないと通信が不可能なため、総じて高度な知識と煩雑な設定が必要である。
ここではLayer2(EthernetやPPPなど)をカプセル化する方式を紹介する。この方式ではIPレベルではなくLayer2でプライベートネットワークを接続するので、IP以外のAppleTalkやNetBEUIなどのプロトコルもVPNで利用することができる。
Layer2VPNではVPNサーバー上に1つの仮想ネットワークインタフェースが作られる。このインタフェースに送られたパケットは、仮想インタフェースによってLayer2パケットになる。このパケットをIPパケットでカプセル化して相手先のVPNサーバーに送られる。
PPTPはプライベートネットワーク内のLayer2フレームをPPPフレームにし、GREでカプセル化した後に公共ネットワーク用のIPパケットでカプセル化し送信する。通信制御は別にTCPコネクションで行う。
Microsoftが独自に拡張したPPPを使用することで、認証や暗号化を可能にしている。
クライアントはwindowsとMacOSで標準搭載されていて、サーバはwindowsの上位版に搭載されている。またLinuxでも利用が可能である。リモートアクセスを想定して機能するものだが、Windowsのネットワークブリッジを使用することでLAN同士の接続も行える。
プロトコルにGREを使用しているので、接続するネットワークのどちらかがNAPTを介して通信している場合、PPTPは使用できない。
L2Fはプライベートネットワーク内のLayer2フレームをPPPフレームにし、UDPでカプセル化した後に公共ネットワーク用のIPパケットでカプセル化し送信する。
L2F自体には改ざんや盗聴防止の能力はない。この場合、IPsecのトランスポートモードを併用することで暗号化や改ざん防止機能を付加する方法が一般的に用いられている。
L2Fはプライベートネットワーク内のLayer2フレームをPPPフレームにし、UDPでカプセル化した後に公共ネットワーク用のIPパケットでカプセル化し送信する。また、UDPを用いずに直接IPでカプセル化もできる。プロトコルスタックはL2Fを継承し、トンネル制御はPPTPを継承している。
クライアントはWindowsやMacOSに標準搭載されている。
L2TP自体は改ざんや盗聴を防ぐ機能は搭載されていない。この場合、IPsecのトランスポートモードを併用することで暗号化や改ざん防止機能を付加する方法が一般的に用いられている。
Secure Shell(以後SSH)のポートフォワーディング機能を用いてPPPをトンネリングする方法である。
SSHは広く普及しておりどのようなパーソナルコンピュータでも設定をすれば使用が可能である。SSHにより認証、暗号化、改ざん防止もサポートされているが、TCPを使用している。そのためトンネル内で更にTCP通信を行うと「TCP over TCP問題」が発生し、回線の状況によっては通信状態が著しく悪化する。
SoftetherはHTTPSライクなプロトコル上にプライベートネットワーク内のMACフレームに独自のヘッダを付加してカプセル化し送信する方式である。PacktiX VPNという名称に変えてからは有償になった。
Windows、MacOSX、Linuxで利用できる。プロトコルスタックは他の方式と比べて深いため通信量のオーバーヘッドは大きい。データを圧縮して通信する機能も搭載されていてある程度緩和できる。なおEthernet上に流れるTCP/IPのパケットに対して、このプロトコルでもTCP/IPを用いているのでSoftetherでは「TCP over TCP問題」が発生する。ただし、TCPパラメータを独自に調整することで改善が図ることができるとされている。また、SSLv3を採用しているので、認証や暗号化も可能である。
Softetherの最大の特徴はTCPとSSLを採用したことで、SSL通信ができる環境であればプロキシ経由でもVPNが構築できるようになったことである。これにより、前述したホテルなどの制約の多い公衆ネットワーク内からでもHTTPS通信ができればVPNを構築できる。またGUIによる簡単な操作をサポートすることで、技術者だけでなく一般のPCユーザーでもVPNを構築できるようにしたことも大きい。
Layer4VPNではトランスポート層のソケットを接続することで特定のアプリケーションのみ相手側のプライベートネットワーク内のサービスに接続することができる。他のレイアのVPNに比べ臨時的に接続する場合は設定が簡単である。ただし接続したいサービスの数だけソケットを接続する必要があるので、多数のサービスを利用する場合は他のレイアのVPN方式を利用した方が効果的である。
SSL-VPNは専用のソフトウェアや環境を用意することなく、利用者が一般のブラウザ経由でプライベートネットワーク内のサーバーにリモートアクセスするVPNである。
他のVPNとは異なりネットワークに接続するわけではなく、サービス(Webやメール、データベースなど)単位でアクセスする方式である。VPNサーバーはブラウザを用いてアクセスしてきたユーザーの指示に従ってネットワーク内の各サービスにアクセスし、取り出した情報をブラウザで表示できるように処理してユーザーに提供する。
ユーザーは特別な環境を用意することなくブラウザでプライベートネットワークにリモートアクセスができる。しかしVPNサーバーの機能次第でアクセスできるサービスの種類は限られてしまう。
SSHで提供されるポートフォワード機能を用いてLayer4VPNを実現することができる。ポートフォワードとは、SSHクライアント側で設定した自端末のTCPポートに接続すると、接続しているSSHサーバー側のネットワークにある端末のTCPポートに転送される機能である。これにより特定のアプリケーションのみ相手のプライベートネットワーク上のサービスにアクセスすることができる。
ウェブブラウザほどではないがSSHは広く普及しておりどのようなパーソナルコンピュータでも設定をすれば使用が可能である。
本研究では、実際に使用されているVPNプロトコルの解析と、効率の計測を行う。これにより、各VPNの性能面からの長所短所を把握し、プロトコルの選択の材料として活用したい。
SoftetherはLayer2のVPNである。このプロトコル使用の詳細は現段階では公開されていないが、公式発表によるとHTTP over SSLプロトコルに準拠した通信上でMACフレームをやりとりするというのが特徴である。
本研究ではSoftetherのパケットの流れを分析し、特徴を解析する。
分析は以下の表2のPC2台でそれぞれVirtualPC2007を起動し、バーチャルマシン上のWindowsXP ProffesionalでSoftetherを実行する。なおこのバーチャルマシンには512MBの物理メモリを割り当てる。
PC1 | PC2 | |
---|---|---|
OS | Microsoft Windows Vista x64 | Microsoft Windows Vista x86 |
CPU | Intel Core 2 Duo(1.86GHz) | Intel Core 2 Duo(2.00GHz) |
物理メモリ | 4GB | 2GB |
ネットワークカード | Intel Gigabit Ethernet | Marvell Gigabit Ethernet |
2台のPCをLANケーブルで接続し単一のネットワークを構築する。PC1のバーチャルマシン上でPacketiX VPN Server 2.0 Enterprise Edition Build 5280(以降PacketiX Server)を起動させる。PacktiX ServerはClient間の通信を中継するものなので、2つのバーチャルマシン間でVPNを使用した通信を行うために、両方のPCのバーチャルマシンでPacketiX VPN Client 2.0 Build 5280(以降PacketiX Client)を起動してPacktiX Serverにそれぞれ接続する。
この環境でPC1のバーチャルマシンでWiresharkというパケット解析ソフトを起動させて分析を行う。分析は、
の3カ所を対象に行う。
ここではWiresharkを利用して分析した結果、判明した事実を説明する。
Softetherのネゴシエーションはユーザーの暗号化設定にかかわらず常に暗号化される。このときSoftether Serverで指定したSSLv3の暗号化方式が使用される。
「application/octet-stream」で送信されるデータには「pencore」という文字列が必ず存在し、この文字列以降に解読のできないバイナリデータが常に添付されている。このバイナリデータはさらに暗号化されている部分だと推測される。
Softetherのネゴシエーション中、サーバポートに対して別のSSLコネクションが発生する。このコネクションでやり取りされるデータの中に、暗号化されていない状態で「PX-VPN2-PROTOCOL」という文字列が存在する。この文字列はSoftetherで通信を行っていることを検出するために送信される。よってファイアーウォル等でSoftetherの通信を遮断することが可能である。
ネゴシエーションの際はSSLトンネル内でHTTPプロトコルを用いるが、VPN通信を行う際はHTTPは用いずに、独自のヘッダを付加してプライベートネットワーク内のEthernetフレームを送信する。ヘッダは8byteでSoftether Client同士の送信元、送信先などの情報が記述されていると考えられる。ヘッダ以降はVPN上を流れるMACフレームが送信される。
通信を切断する場合は特別な手順はなく、TCPコネクションの切断を行うだけである。
ここではSoftetherでVPNを構築したときの通信性能を測定する。
測定は4.1.1.と同様の測定環境で行う。
Softetherには「通信スループット測定ツール」というベンチマークソフトが付属している。これは2つの端末間に任意の数のTCPコネクションを行い、一定時間の間に通信したデータ量を計測するものである。
まずはこれを用いて物理ネットワーク自体の性能を計測する。
各バーチャルマシン上で「通信スループット測定ツール」を起動し、それぞれ「測定サーバー」と「測定クライアント」に設定する。「データ通信の方向」の設定を「測定サーバから測定クライアントに伝送」にして、「通信の詳細設定」の「並列接続してデータ伝送に使用するTCPコネクション数」を増加させていく。「データ転送時間」は15秒間で行う。
以下の表と図が実験の結果である。
TCPコネクション数 | ダウンロードデータ量(Byte) | 平均スループット(Bit/Sec) |
---|---|---|
1 | 129,693,766 | 68,981,000 |
2 | 159,446,657 | 85,033,000 |
3 | 185,726,193 | 98,777,000 |
4 | 208,204,699 | 110,590,000 |
5 | 232,714,790 | 123,940,000 |
6 | 291,150,276 | 154,950,000 |
7 | 303,527,632 | 161,540,000 |
8 | 336,241,773 | 178,960,000 |
9 | 352,539,714 | 187,870,000 |
10 | 369,251,940 | 196,780,000 |
11 | 387,625,471 | 206,290,000 |
12 | 397,721,872 | 212,090,000 |
13 | 407,021,038 | 216,920,000 |
14 | 420,474,034 | 223,630,000 |
15 | 440,379,320 | 234,530,000 |
16 | 445,549,616 | 237,290,000 |
17 | 464,622,892 | 247,290,000 |
18 | 491,087,848 | 261,700,000 |
19 | 459,510,694 | 244,710,000 |
20 | 503,003,705 | 267,880,000 |
21 | 526,797,331 | 280,380,000 |
22 | 511,452,212 | 272,210,000 |
23 | 529,010,718 | 281,350,000 |
24 | 532,996,839 | 284,040,000 |
25 | 526,200,345 | 280,060,000 |
26 | 534,831,821 | 284,450,000 |
27 | 545,730,272 | 290,650,000 |
28 | 551,480,798 | 293,690,000 |
29 | 558,399,299 | 297,200,000 |
30 | 563,039,655 | 299,870,000 |
31 | 581,102,951 | 309,060,000 |
32 | 589,819,437 | 313,900,000 |
TCPコネクションが1個のとき平均スループットは68,981,000bit/secで、そこから増加し32個のときは313,900,000bit/secに達し、1個のときに比べ4.5倍の転送量になっている。TCPコネクション数を増やすとデータの転送効率は上がるということがわかる。
次にVPN上で測定を行う。SoftetherはVPNに用いるTCPコネクション数を設定することができる。開発者の発表によるとコネクション数をある程度増やすと通信効率が上がるとのことである。ここでは実際に数値を測定し、通信効率は改善するのか、また、どの程度改善するのかを調べたい。
先ほどの「通信スループット測定ツール」を使用する。「データ通信の方向」の設定を「測定サーバから測定クライアントに伝送」にして、「通信の詳細設定」の「並列接続してデータ伝送に使用するTCPコネクション数」は1で固定し、SoftetherのTCPコネクション数を1から増加させていく。「データ転送時間」は15秒間で行う。
以下の表と図が実験結果である。
TCPコネクション数 | ダウンロードデータ量(Byte) | 平均スループット(Bit/Sec) |
---|---|---|
1 | 31,474,904 | 16,747,000 |
2 | 22,893,561 | 12,185,000 |
3 | 20,228,471 | 10,773,000 |
4 | 24,825,167 | 13,213,000 |
5 | 22,170,352 | 11,786,000 |
6 | 21,473,636 | 11,405,000 |
7 | 23,035,337 | 12,268,000 |
8 | 21,713,931 | 11,546,000 |
9 | 23,067,889 | 12,278,000 |
10 | 21,534,846 | 11,471,000 |
グラフを見てみるとTCPコネクションが1個のときがもっともスループットが大きく、その他は大体11,000,000Bit/Secである。公式で発表とは異なりTCPコネクションは1個のときが一番効率のよい通信ができている。
次はSoftetherのTCPコネクション数を固定して、計測ツールのTCPコネクション数を変化させる。
先ほどの「通信スループット測定ツール」を使用し、「データ通信の方向」の設定を「測定サーバから測定クライアントに伝送」にして、「通信の詳細設定」の「並列接続してデータ伝送に使用するTCPコネクション数」を1から増加させていく。SoftetherのTCPコネクション数は10で固定する。「データ転送時間」は15秒間で行う。
以下の表と図が実験結果である。
TCPコネクション数 | ダウンロードデータ量(Byte) | 平均スループット(Bit/Sec) |
---|---|---|
1 | 21,534,846 | 11,471,000 |
2 | 42,041,677 | 22,341,000 |
3 | 54,307,269 | 28,883,000 |
4 | 67,774,984 | 36,063,000 |
5 | 81,064,908 | 43,172,000 |
6 | 86,765,811 | 46,158,000 |
7 | 96,166,030 | 51,227,000 |
8 | 101,309,716 | 53,943,000 |
9 | 105,594,634 | 56,249,000 |
10 | 111,268,550 | 59,233,000 |
グラフを見てみると、TCPコネクション数を増加させるほどスループットが大きくなっていることがわかる。
ここからはJAVAで製作したHTTPサーバとApacheに付属している「ApacheBench」を用いて測定を行う。HTTPはウェブサイトの通信などでよく用いられるプロトコルであり、HTTPプロトコルを用いた測定を行うことで、より実際の利用環境下での通信性能に近い値の測定ができると考えられる。
Softetherは通信の暗号化をするかどうか、暗号化方式はどうするかを選択することができる。Softetherの暗号化はSSLv3に依存しておりSSLv3がサポートする暗号化方式のみ選択可能である。
100,000,000ByteのバイナリファイルをPC1のバーチャルマシン上に置き、HTTPサーバが送信可能な状態にしておく。これをPC2のバーチャルマシン上で起動したApacheBenchで取得して計測を行う。データ転送時間は15秒間である。暗号化方式を変更して順次測定を行う。
以下の表と図が実験結果である。
暗号化方式 | 平均ダウンロードデータ量(Byte) | 平均スループット(KByte/Sec) |
---|---|---|
暗号なし | 102,257,355 | 6,633.2 |
RC4-MD5 | 76,164,456 | 4,958.1 |
RC4-SHA | 71,248,964 | 4,638.1 |
AES128-SHA | 57,125,535 | 3,718.2 |
AES256-SHA | 51,713,510 | 3,365.0 |
DES-CBC-SHA | 45,539,387 | 2,964.5 |
DES-CBC3-SHA | 29,058,753 | 1,890.6 |
グラフを見てみるとやはり暗号化をしていない状態のときが最もスループットが大きい。また、暗号化方式を複雑なものにすればするほど通信速度は低下している。すでに脆弱性が指摘されている暗号化方式を用いることは通信効率面でもセキュリティ面でも利点はないと考えられるが、VPN上に流れる情報の重要度に応じて適切な暗号化形式を選択するのがよいと考えられる。
続いて、SoftetherのTCPコネクション数の違いによる性能差を計測する。ApacheBenchでの計測することで、実際の利用環境下に近い計測値が求められると考えられる。
100,000,000ByteのバイナリファイルをApacheBenchで取得して計測を行う。データ転送時間は15秒間である。SoftetherのTCPコネクション数を順次増加させて測定する。
以下の表と図が実験結果である。
TCPコネクション数 | 平均ダウンロードデータ量(Byte) | 平均スループット(KByte/Sec) |
---|---|---|
1 | 102,257,355 | 6,633.2 |
2 | 104,016,354 | 6,771.1 |
3 | 101,994,803 | 6,639.6 |
4 | 102,380,827 | 6,654.3 |
5 | 99,909,829 | 6,503.8 |
6 | 102,421,995 | 6,667.4 |
7 | 98,467,074 | 6,411.7 |
8 | 98,020,218 | 6,380.8 |
9 | 97,120,141 | 6,322.2 |
10 | 96,002,002 | 6,249.4 |
11 | 96,808,961 | 6,302.0 |
12 | 97,671,195 | 6,357.3 |
13 | 92,884,931 | 6,046.5 |
14 | 92,979,990 | 6,050.2 |
15 | 93,180,650 | 6,065.0 |
16 | 90,682,693 | 5,902.4 |
グラフと見てみると、コネクション数を増やすとスループットが低下していく傾向があることがわかる。先ほどの「通信スループット測定ツール」を用いた計測のときは低下する傾向はなかった。
Softetherには「TCP通信設定最適化ユーティリティ」というツールが付属している。これはTCPの送受信ウインドウサイズをSoftether用に最適化することでVPNの通信効率を高めるためのものである。ここでは、このツールを用いた場合、どの程度通信効率が改善するのかを調査する。
「TCP通信設定最適化ユーティリティ」で、推奨値を指定しOSを再起動してから実験を行う。100,000,000ByteのバイナリファイルをApacheBenchで取得して計測を行う。データ転送時間は15秒間である。SoftetherのTCPコネクション数を順次増加させて測定する。
以下の表と図が実験結果である。
TCPコネクション数 | 平均ダウンロードデータ量(Byte) | 平均スループット(KByte/Sec) |
---|---|---|
1 | 107,647,534 | 7,006.6 |
2 | 101,092,148 | 6,531.6 |
3 | 131,534,627 | 8,562.5 |
4 | 130,278,080 | 8,479.5 |
5 | 128,846,069 | 8,384.2 |
6 | 119,230,147 | 7,710.1 |
7 | 121,337,167 | 7,895.4 |
8 | 120,983,746 | 7,820.1 |
9 | 119,135,064 | 7,752.5 |
10 | 127,228,794 | 8,245.7 |
11 | 130,036,866 | 8,463.7 |
12 | 118,655,314 | 7,763.1 |
13 | 129,836,485 | 7,445.2 |
14 | 122,186,456 | 7,954.0 |
15 | 126,249,370 | 8,213.1 |
16 | 107,896,524 | 7,008.4 |
グラフで比較すると、「TCP通信設定最適化ユーティリティ」を用いた場合、1,000KByte/Secほどスループットが向上することがわかる。ただし、この設定のままVPNを使用せず外部のWebページなどにアクセスすると悪影響がある可能性もある。「TCP通信設定最適化ユーティリティ」の使用は、Softetherを介してのみ通信を行う端末の場合に使用したほうがよいと考えられる。
次にPPTPでVPNを構築した場合の通信性能を調査する。
4.1.1.と同じネットワークの実験環境で行う。PC1のバーチャルマシン上でPPTPサーバーを起動させる。PC2のバーチャルマシンではPPTPクライアントを起動させ、PPTPサーバーに接続する。この状態で100,000,000ByteのバイナリファイルをPC1のバーチャルマシン上に置き、JAVAで製作したHTTPサーバで送信可能な状態にしておく。これをPC2のバーチャルマシン上で起動したApacheBenchで取得して計測を行う。PPTPサーバー及びクライアントはWindowsXP Professionalに標準搭載されているものを用い、暗号化する場合と暗号化しない場合の両方を計測する。
以下の表と図が実験結果である。
暗号化 | 平均ダウンロードデータ量(Byte) | 平均スループット(KByte/Sec) |
---|---|---|
なし | 177,092,883 | 11,528.2 |
あり | 100,215,877 | 6,523.7 |
測定結果によるとSoftether同様、暗号化すると暗号化しない場合と比べスループットが大幅に低下する。
また、Softetherと比較するとPPTPの方が通信効率がよいことがわかる。これはSoftetherが通信にTCP を用いていることが原因であると考えられる。
本研究ではSoftetherとPPTPの2つの性能測定を行った。どちらもLayer2のVPNであるが、PPTPはGREでPPPフレームを、SoftetherはSSLでMACフレームをカプセル化する違いがある。特に大きな違いはSoftetherはカプセル化にTCPプロトコルを用いていることである。これにより、GREやUDPを用いた場合より通信性能は低下し、通信環境によっては「TCP over TCP問題」を引き起こすこともある。実際にこの2種類のVPN方式の通信性能を比較すると、同じ条件下ではPPTPの方が通信性能は高いという結果が出た。
Softetherは通信性能を改善するために「TCPの送受信バッファの最適化」と「複数のTCPコネクションによるVPN」という2つの改善策を提案している。このうち送受信バッファの最適化はわずかではあるが通信性能の向上が測定できた。一方TCPコネクションを増やす方法は今回の実験方法では通信性能の向上は測定できなかった。TCPコネクション数で通信性能を改善するのであればSoftether側ではなくVPN上で動作するアプリケーションのTCPコネクションを増やした方が効果がある。
このことから単にVPNの通信性能を求めるだけであればSoftetherよりPPTPの方がよい。
しかし、VPNでは高いセキュリティ性能も求められる。PPTPではMPPEという暗号方式を採用している。これはRC4という暗号方式を拡張したものである。しかしこの方式は適切な運用方法でないと解読されてしまう可能性があり安全性を保つことができなくなる。SoftetherはSSLv3で採用されている暗号化方式を自由に選択して利用することができる。SSLv3ではより強固な暗号化方式も採用されているので、より安全性の高い通信を行うことが可能である。
このことからより強固な安全性を確保したい場合、PPTPよりSoftetherの方を利用するのがよい。
また、通信性能や安全性以外にも重要視されるのはVPNソリューションとしての使いやすさである。いくら性能が優れていても操作が煩雑であれば十分に能力を引き出すのは難しくなる。PPTPクライアントは現行のWindows、MacOSに標準搭載されている。OSに統合されているため、設定画面を呼び出すのに多少の慣れが必要であるが設定項目自体は少なくウィザード形式のGUIが用意されているので簡単に利用できると考えられる。しかしプロトコルにGREを使用しているためNAPTを介して通信ができない。企業の拠点間の接続に利用する場合は大きな問題はないと思われるが、片拠点が一般家庭などNAPTを利用しているネットワークの場合、PPTPは利用できない。
Softetherは付属のGUIを用いてすべての設定を行うことができ、PPTP同様、簡単に環境を構築できる。またTCPプロトコルを使用しているので、NAPTも通過できる。インターネットに接続されているほとんどのネットワークで利用することができると考えられる。またSoftetherは単体でルーティング機能やアクセス制御機能を含んでいるので、より大規模なネットワークにも対応できる。
このことから、あらゆる環境でVPNの構築に対応できるのはPPTPよりSoftetherであるといえる。
最後にVPNを利用するためにかかる費用も検討する。PPTPはメジャーな商用OSに標準搭載されている。OSの利用費用はかかるが、その費用のみで使用できる。またほとんどのLinuxではOSの利用費用自体が必要でない。現在ではSoftetherはそれ自体が有償のソフトウェアである。このためOSの利用費用に加えSoftetherの利用料も必要である。
このことからコスト面ではPPTPが有利と考えられる。
以上のように検討する項目によってどちらが有利であるか異なるが、VPNを利用したい環境を考慮に入れるとどちらが適合しているのかが判断できる。NAPTがないネットワークで小規模なVPNを構築したい場合、PPTPが有利と考えられる。逆にNAPTがあるネットワークや大規模なVPNを構築したい場合、またより強固な安全性が必要な場合はSoftetherが有利であると考えられる。
本研究では数々のVPN方式に対し、その通信性能や利用の容易さを調査することで各VPN方式の性能評価を行なった。今回は主にLayer2VPNであるPPTPとSoftetherに焦点を当て検討したが、VPN方式はほかにも多数存在する。このため、よりどのような環境にどの方式を採用するのが最適であるかを見極めるには、より多くのVPN方式での通信性能や利用の容易さを調査する必要がある。VPN方式によって長所や短所が異なるため一概に性能の優劣は述べられないが、実際に利用する環境に応じて検討すればより最適なVPN方式を選択することが可能である。