3

特集●ソフトウェア論文

SoftEther VPN Server: マルチプロトコル対応の クロスプラットフォームなオープンソース VPN サーバ

登 大遊 新城靖 佐藤聡

SoftEther VPN Server はマルチプロトコル対応のクロスプラットフォームなオープンソース VPN サーバソフト ウェアであり，既存の VPN サーバプログラムにない 2 つの特徴がある．1 つ目は，単一 VPN サーバインスタンス で複数の VPN プロトコルをサポートしている点にある．管理者は，複数の VPN プロトコルによる多種類の VPN デバイスからのリモートアクセスおよび拠点間接続を受付ける VPN サーバを容易に管理することができる．そのた めに，SoftEther VPN Server 内に L2 アダプタと呼ばれるモジュールを実装し，レイヤ 2 VPN プロトコルとレイ ヤ 3 VPN プロトコルとの間の通信を，共通のバスである仮想 L2 スイッチを経由させ，シームレスに実現にした． 2 つ目は，ユーザ管理やネットワークの機能を仮想化するマルチテナント機能である．これは，仮想ホスティング サービスのために必須である．本プログラムは複数の OS 間の移植性を有する．本プログラムは 2013 年 3 月から 2014 年 9 月までの間に，世界中で 242,000 回インストールされた実績を有する．また，異なる VPN プロトコル間 での通信速度実験では，従来の VPN プロトコルのネイティブな VPN サーバプログラムを組み合わせて用いた場合 と比較して高速な結果が得られた．

SoftEther VPN Server is an open-source cross-platform multi-protocol VPN server which has two advan- tages over existing VPN servers. First, it supports multiple VPN protocols in a single VPN server instance. This makes it easy for an administrator to configure and manage a VPN server which supports remote access and site-to-site connection from a variety of VPN client devices. To realize that, SoftEther VPN Server includes a module called an L2 adapter to exchange messages between layer-3 VPN protocols and layer-2 VPN protocols seamlessly via common virtual L2 switches. The second advantage is that it can virtualize user management and networking, which is an essential function in multi-tenant virtual hosting. SoftEther VPN Server is portable among several operating systems. SoftEther VPN Server gained a total of 242,000 installations around the world from March 2013 to September 2014. The experimental result indicates that SoftEther VPN Server is faster than combinations of native VPN servers when exchanging messages between different VPN protocols.

社内 LAN や自宅のネットワークに接続することがで 1 はじめに きる．各デバイスには，予め組み込みの VPN クライ インターネット上では，パーソナルコンピュータ アントプログラムが搭載されている．これらの組み (PC) やスマートフォンを含めた多くの種類のデバイ 込み VPN クライアントプログラムを使用すれば，対 スが使用されている．仮想プライベートネットワー 応している VPN プロトコルに追加ソフトウェアのイ ク (VPN) を用いることにより，それらのデバイスを ンストールなしで接続でき，便利である．このよう な組み込み VPN クライアントプログラムで対応し SoftEther VPN Server: An Open-source Cross- ている VPN プロトコルを，ネイティブ VPN プロ platform Multi-protocol VPN Server. トコルと呼ぶ．例えば，Layer 2 Tunneling Protocol Daiyuu Nobori, Yasushi Shinjo and Akira Sato, 筑波大 学大学院システム情報工学研究科コンピュータサイエンス (L2TP) [27] over IPsec および Point-to-Point Tun- 専攻 , Department of Computer Science, University neling Protocol (PPTP) [8] 等は iOS，Mac OS X お of Tsukuba. よび におけるネイティブ プロトコルで コンピュータソフトウェア, Vol.32, No.4 (2015), pp.3–30. Android VPN [ソフトウェア論文] 2014 年 10 月 29 日受付. ある．これらの VPN プロトコルに加え，Windows は 4 コンピュータソフトウェア

Secure Socket Tunneling Protocol (SSTP) [21] をネ 計と実装を行った．SoftEther VPN Server は，単一 イティブ VPN プロトコルとしてサポートしている． のインスタンスで多数の VPN プロトコルをサポー CentOS Linux においては，OpenVPN [26] Layer 3 トする．サポートされる VPN プロトコルは，L2TP (L3) をサポートしている．これらのリモートアクセ over IPsec，Ether IP over IPsec，OpenVPN L3 お ス用の VPN プロトコルに加え，複数の拠点間を拠点 よび L2，L2TPv3 over IPsec，EtherIP over IPsec， 間接続するための VPN プロトコルとして OpenVPN SSTP および SoftEther VPN Protocol (SEVP: Eth- Layer 2 (L2)，Layer 2 Tunneling Protocol version ernet over HTTPS を実現するプロトコル) である． 3 (L2TPv3) [18] および EtherIP [9] がある．Open- これらの複数の VPN プロトコルに対応することによ VPN L2 は CentOS に，L2TPv3 は Cisco IOS に， り，広範囲に渡るリモートアクセス用途の VPN クラ EtherIP は NEC IX ルータにおいてネイティブ VPN イアント (PC やスマートフォンなど) や拠点間接続用 プロトコルとしてサポートされている．同一の目的で 途の VPN デバイス (ルータなど) が単一の SoftEther 利用できる複数の VPN プロトコルは，環境や用途に VPN Server のインスタンスに接続できるようにな よって使い分けられることがある．例えば，UDP 通 る．SoftEther VPN Server を使用することにより， 信が可能な環境では高速な L2TP over IPsec (UDP) システム管理者は単一のインスタンスを稼働させ管理 を使用し，UDP 通信ができない環境では速度が低 するだけで，複数の VPN プロトコルをサポートし運 下するものの TCP により通信ができる SSTP over 用することができる．管理者は，サポートする各々の TCP を使用することがある． VPN プロトコルを意識することなく，ユーザ管理， 社内 LAN において複数の VPN プロトコルをサ VPN クライアントへの IP アドレスの割り当て，ア ポートしたい場合，システム管理者は問題に直面する． クセス制御およびログの保存などの設定・運用を行う 単一の VPN サーバソフトウェアでは一部の VPN プ ことができる．さらに，SoftEther VPN Server は， ロトコルしかサポートしていない場合，サポートし サービスプロバイダが顧客に VPN サービスを提供す たいすべての VPN プロトコルのために複数の VPN るために利用可能な，単一の VPN サーバインスタン サーバソフトウェアをインストールし同時に稼働させ スにおける複数の顧客向けの仮想 VPN サーバ (テナ なければならない．複数の VPN サーバを同時に設定 ント) のホスティング機能を提供する． し運用するためには，たとえばアクセス制御リスト 本論文では，SoftEther VPN Server の設計，実装お (ACL) を設定する場合はそれぞれの VPN サーバに よび評価について述べる．SoftEther VPN Server の 対して設定する必要がある．これは管理コストの増大 最大の特徴は，VPN サーバ内において，IPv4，IPv6 につながる． および Internetwork Packet Exchange (IPX) 等の任 マルチテナント仮想ホスティングサービスにおい 意のレイヤ 3 パケットを含む MAC フレームを交換 て，メールサービスや Web サービスに加え，新たに することができるソフトウェアベースのレイヤ 2 ス VPN サービスを提供しようとする場合，サービスプ イッチを実装している点にある．しかしながら，単純 ロバイダは問題に直面する．多くのメールサーバや なレイヤ 2 スイッチ機能だけでは，レイヤ 3 である Web サーバには，単一のサーバプログラムのインス IP パケットを直接取扱うことができない．複数のレ タンスで，複数の顧客のための互いに分離された仮 イヤ 3 VPN プロトコルをサポートするため，我々は 想ホストを作り出すための仮想ホスティング機能が L2 アダプタと呼ばれるアダプタモジュールを用いて， 搭載されている．しかしながら，同様の仮想ホスティ レイヤ 3 パケットをレイヤ 2 フレームに変換するこ ング機能を搭載した広く使われている VPN サーバプ とで，この問題を解決した．L2 アダプタは Address ログラムは存在しない． Resolution Protocol (ARP) および Dynamic Host これらの問題を解決するため，我々は SoftEther Configuration Protocol (DHCP) パケットを必要に VPN Server と呼ばれる VPN サーバプログラムの設 応じて受発信することにより，レイヤ 3 パケットとレ Vol. 32 No. 4 Nov. 2015 5

イヤ 2 フレームとの間の交換を実現する． 2. 1 多数の VPN プロトコル SoftEther VPN Server は OS 間の移植性を有する． 表 1 は広く利用されている VPN プロトコルを示 現在対応している OS は，Windows，Linux，Mac したものである．これらの VPN プロトコルは，レ OS X，FreeBSD および Solaris である．我々は Soft- イヤ 3 およびレイヤ 2 に分類することができる．レ Ether VPN Server のバイナリパッケージは 2013 年 イヤ 3 VPN プロトコルは IP データグラムの交換を † 3 月に公開 1し，2014 年 1 月にソースコードを GNU 実現し，レイヤ 2 VPN プロトコルはローカルエリア General Public License (GPL) Version 2 として公 ネットワーク (LAN) で使用されている Ethernet の † 開 2した．SoftEther VPN Server は，2014 年 9 月 フレームの交換を実現する． までの間に，世界中で 242,000 回インストールされた レイヤ 2 VPN プロトコルには，レイヤ 3 VPN プ 実績を有する．SoftEther VPN Server は，商用ソフ ロトコルにはないいくつかの利点がある．まず，PC トウェアである PacketiX VPN Server 3.0 の後継版 をレイヤ 2 VPN プロトコルを用いてネットワークに である．PacketiX VPN Server の新たなバージョン VPN 接続すれば，IP プロトコルだけではなく，非 IP 4.0 は，SoftEther VPN Server で実装したマルチプ プロトコル，例えば Microsoft の NetBIOS Extended ロトコルのサポート機能のコードが搭載されている． User Interface (NetBEUI) や Novell の Internetwork PacketiX VPN Server は 5,500 社に導入されている． Packet Exchange (IPX) / Sequenced Packet Ex- 本論文の構成は次のとおりである．第 2 章では，複 change (SPX) および Apple Talk 等を使用すること 数の VPN プロトコルおよびマルチテナント機能を提 ができる．次に，レイヤ 3 VPN プロトコルを用いる 供する上での問題について述べる．第 3 章では，Soft- 場合に必要なルーティングやプロキシ ARP 等の複雑 Ether VPN Server の設計について，第 4 章では実装 な仕組みを使用しなくても，リモートアクセスおよび について述べる．第 5 章では SoftEther VPN Server 拠点間接続を容易に実現できる．拠点間接続におい の性能評価について述べる．第 6 章では SoftEther ては，両方の拠点のコンピュータを同一の IP ネット VPN Server，商用版 PacketiX VPN Server および ワークに所属させることができ，管理が容易になる． これらの元となった SoftEther 1.0 の制作および普及 最後に，レイヤ 2 VPN においては，マルチキャスト の努力の過程を述べる．第 7 章では関連研究につい およびブロードキャストベースのプロトコルをその て述べる．第 8 章は，本論文のまとめである． まま利用することができる．例えば，Multicast DNS (mDNS) [2] プロトコルを用いてマルチキャスト対応 2 既存の VPN サーバソフトウェアの問題点 のサービスを検索したり，NetBIOS over TCP/IP プ この章では，まず広く使われている多数の VPN ロトコルや Link-Local Multicast Name Resolution プロトコルおよび各プロトコルの特徴を述べる．次 (LLMNR) プロトコルを用いることで遠隔拠点のコ に，これらの複数の VPN プロトコルを既存の VPN ンピュータの名前解決を行ったり，コンピュータを列 サーバソフトウェアで運用する場合の問題点を述べ 挙したりすることができる． る．最後に，既存の VPN サーバソフトウェアで複数 表 1 の VPN プロトコルの多くは，リモートアクセ の VPN 顧客をマルチテナント仮想ホスティングを実 スをサポートしている．リモートアクセスには，ユー 現しようとする際の問題と，マルチテナント仮想ホス ザ認証および IP アドレスの割り当てが必要である． ティングのために VPN サーバソフトウェアに要求さ 表 1 の VPN プロトコルのうち，SSTP，OpenVPN れる機能について述べる． (L3 および L2) および SEVP は，PC がリモートの VPN サーバに HTTP 対応のプロキシを経由して接続 することを許容する．このうち，SSTP および SEVP

†1 http://www.softether.org/ は正規の SSL プロトコルを TCP コネクション上で †2 https://github.com/SoftEtherVPN/SoftEtherVPN/ 使用するため，PC はステートフルファイアウォール 6 コンピュータソフトウェア

表 1 広く利用されている VPN プロトコルの一覧

レイヤ 3(IP パケット) を伝送する VPN プロトコル レイヤ 2(MAC フレーム) を伝送する VPN プロトコル 機能 IPsec トン L2TP/ PPTP SSTP OpenVPN OpenVPN L2TPv3/ EtherIP/ SEVP ネルモード IPsec L3 L2 IPsec IPsec リモートアクセ ✓ ✓ ✓ ✓ ✓ ス 暗号化 IPsec IPsec MPPE SSL SSL SSL IPsec IPsec SSL 下位レイヤ ESP/UDP ESP/UDP GRE HTTPS TCP, TCP, ESP/UDP ESP/UDP HTTPS /TCP UDP UDP /TCP HTTP プロキシ ✓ ✓ ✓ ✓ を通過 ステートフルフ ✓ ✓ ァイアウォールを 通過 Windows 上 の サードパー ネイティブ ネイティブ ネイティブ サードパー サードパー サードパー クライアント ティ ティ ティ ティ Mac OS X 上の ネイティブ ネイティブ ネイティブ サードパー サードパー サードパー サードパー クライアント ティ ティ ティ ティ iOS 上のクライ ネイティブ ネイティブ ネイティブ サードパー サードパー アント ティ ティ Android 上のク ネイティブ ネイティブ ネイティブ サードパー サードパー ライアント ティ ティ Linux 上のクラ 実装あり 実装あり 実装あり 実装あり 実装あり 実装あり 実装あり イアント FreeBSD 上のク 実装あり 実装あり 実装あり 実装あり 実装あり 実装あり ライアント

「SEVP」=SoftEther VPN Protocol．「MPPE」=Microsoft Point-to-Point Encryption．「ESP」=Encapsulating Security Payload．「GRE」 =Generic Routing Encapsulation．「HTTPS」=HTTP over SSL．「リモートアクセス」とは，VPN クライアントへの IP アドレス割り当て機能を有す る VPN 接続が可能であることを意味する．「ステートフルファイアウォール」とは，SSL の通信のステートを検査し，非 SSL プロトコルを遮断する機能を有する ファイアウォールを意味する．「ネイティブ」とは，OS ベンダが OS に組み込んでいる VPN クライアントによりサポートされていることを意味する．「サードパー ティ」とは，サードパーティの提供する VPN クライアントのインストールにより利用可能となることを意味する．「実装あり」とは，1 つ以上のオープンソース実装 が利用可能であることを意味する．

を経由して VPN サーバに接続できる．ステートフル る．複数の VPN プロトコルをサポートする必要があ ファイアウォールは Deep Packet Inspection (DPI) る例として，例えば，iOS のデバイスからの VPN 接 機能により，TCP ストリームが真正な SSL 通信であ 続を受付けるために L2TP をサポートし，PC から るかどうか見分け，SSL 通信に偽装した非 SSL 通信 の VPN 接続において mDNS をサポートする目的で をブロックすることができる． レイヤ 2 通信のために OpenVPN L2 をサポートす 表 1 に列挙されているように，各クライアントデ る必要がある場合等が挙げられる． バイスは特定のプロトコルをネイティブ VPN プロト 複数の VPN プロトコルのサポートは，ホスティン コルとしてサポートしている．ネイティブ VPN プロ グサービスにおいて重要である．サービスプロバイ トコルとは，OS に組み込まれているドライバによっ ダは，顧客の要求を満たすために，できるだけ多くの てサポートされている VPN プロトコルのことであ VPN プロトコルをサポートする必要がある． る．例えば，iOS は IPsec トンネルモード，L2TP お よび PPTP の 3 つをネイティブ VPN プロトコルと 2. 2 既存の VPN サーバソフトウェアで複数の して有している．それぞれの OS がサポートしている VPN プロトコルをサポートする際の問題 VPN プロトコルは互いに異なる．例えば，SSTP は 必要な複数の VPN プロトコルの組み合わせによっ Windows においてのみネイティブ VPN プロトコル ては，単一の VPN サーバによってこれら複数の VPN である． プロトコルをサポートすることができることがある． 社内 LAN 管理者は，サポートする必要があるデバ 例えば，L2TP，PPTP および SSTP をサポートし イスや実現したい機能等の要求に基づき，1 個または たい場合は，Microsoft Windows に搭載されている 複数の VPN プロトコルをサポートすることを選択す Routing and Remote Access (RRAS) を用いてこれ Vol. 32 No. 4 Nov. 2015 7

らの VPN プロトコルをサポートできる．しかしな きる． がら，いずれの VPN サーバも，必要とする複数の VPN プロトコルすべてをサポートしていない場合は， 2. 3 マルチテナント仮想ホスティングサービスの 2 個またはそれ以上の異なる VPN サーバプログラム 提供時の問題 を同時に稼働させる必要が生じる．例えば，L2TP お マルチテナント仮想ホスティングサービスとして， よび OpenVPN をサポートしたい場合は，RRAS と サービスプロバイダは Web やメール等のサービスを OpenVPN Server の両方を同時に稼働させる必要が サポートしていることが多い．広く利用されている 生じる．複数の VPN サーバを同時に稼働させる場合 Web サーバやメールサーバは，仮想ホスティングを は，以下のような問題が発生する． サポートしている．仮想ホスティングとは，単一の 1. VPN サーバの管理が難しくなる．ネットワー サーバに複数の内部インスタンスを持たせ，複数の顧 ク管理者は IP アドレスの割り振り，ユーザ管理， 客に対して論理的に分離した仮想専用サーバを提供 アクセス制御およびログの保存を VPN サーバの することである． 管理業務の一部として実施しなければならない． 例えば，Apache HTTP サーバや Postfix メール ユーザインターフェイスや設定ファイルの書式 サーバはマルチテナント仮想ホスティング機能を有 は，VPN サーバ毎に異なる．例えば，Microsoft する．複数の顧客の複数のドメインを単一の HTTP RRAS と OpenVPN とでは，IP アドレスの割り サーバやメールサーバでホストし，顧客ごとにユーザ 振りやユーザ管理の設定のためのユーザインター リストやコンテンツを分離することができている．顧 フェイスが異なる．VPN サーバの数が増加する 客の数が増加しても，その都度，割当グローバル IP と，管理に要するコストも，それに応じて増加 アドレスを増加させたり，新たにサーバソフトウェア する． をインストールしたりする必要がないため，サービス 2. より多くのハードウェア資源が必要となる．単 プロバイダはコストを節約でき，集約効果を実現する 一のプラットフォームにおいて 2 個またはそれ以 ことができる． 上の VPN プロトコルのサーバ機能を稼働するこ これと同様に，もし単一の VPN サーバがマルチテ とができない場合，2 個またはそれ以上の物理的 ナント仮想ホスティング機能を有するならば，多数 なハードウェアが必要となる．例えば，L2TPv3 の顧客ごとに分離された VPN サーバ機能を，単一の と SSTP の両方をサポートしたい場合は，Cisco 割当グローバル IP アドレスを共有させて提供するこ ルータと Windows サーバ PC とを購入しなけれ とができ，また，インストールし管理する VPN サー ばならない． バソフトウェアは 1 個で良いことになる．これによ 3. 異なる VPN プロトコル間の通信速度が低下す り VPN サービスプロバイダはコストを節約でき，集 る．2 台の VPN クライアントが 2 個の異なる 約効果を実現しつつ，顧客に代わって VPN サーバを VPN サーバプログラムに接続されているとき， 運用することができる．しかしながら，既存の VPN パフォーマンスが低下する．これは，2 個の VPN サーバはマルチテナント仮想ホスティング機能を有し サーバプログラム間におけるメッセージコピーお ていない． よびコンテキストスイッチの回数の増加が原因で 仮想ホスティング機能を実現するためには，VPN 発生する． サーバは以下の機能を提供しなければならない． 広く利用されている VPN プロトコルすべてをサ 1. 分離されたユーザ管理．各テナントは，VPN 接 ポートする単一の VPN サーバソフトウェアは存在し 続に係るユーザ認証の設定について，それぞれ独 ていない．広く利用されている VPN プロトコルすべ 立した認証領域を持たなければならない．各テナ てをサポートする単一の VPN サーバソフトウェアを ントの顧客は，ユーザの新規作成や既存ユーザの 新たに制作すれば，上記の問題を解決することがで 削除等の操作を，サービスプロバイダに毎回依頼 8 コンピュータソフトウェア

せずに行うことができる必要がある． テナント仮想ホスティング機能について述べる． 2. ネットワークの分離．ある顧客の VPN クライ アントは，別の顧客の VPN クライアントと通信 3. 1 サポートされている VPN プロトコル できてはならない． SoftEther VPN Server の設計においては，広く利 3. 設定およびログの分離．顧客は，VPN サーバ 用されている以下のデバイスに組み込み VPN クライ に接続したデバイス間の通信に適用されるアク アントとして実装されている VPN プロトコルをサ セスコントロールリスト (ACL) やその他のネッ ポートすることを目標とした． トワークパラメータを設定したい場合がある．同 1. PC (Windows, Mac OS X, Linux および BSD) 様に，顧客は，デバイスからの VPN 接続のログ 2. スマートフォンおよびタブレット端末 (iOS お や通信のログを閲覧したい場合がある．これらの よび Android) 設定や保存されるログは，顧客間で分離されてい 3. 企業向けルータ (Cisco, Extreme Networks, なければならない． Brocade, F5 Networks, その他) 既存の VPN サーバソフトウェアでマルチテナント 仮想ホスティングに必要なすべての機能を提供するも すべてのクライアントデバイスをサポートするた † † のは存在しない 3 4．そこで，そのような機能を提供 めに，我々は，SoftEther VPN Server に以下のよう し，同時に 2.2 節で述べた複数 VPN プロトコル対応 なプロトコルをサポートさせることにした． の単一の VPN サーバソフトウェアが必要である． 1. レイヤ 3 VPN プロトコル L2TP/IPsec, SSTP および OpenVPN L3 3 SoftEther VPN Server の設計 2. レ イ ヤ 2 VPN プ ロ ト コ ル OpenVPN L2, 第 2 章では既存の VPN サーバにおける 2 つの問 L2TPv3/IPsec, EtherIP/IPsec および SEVP 題について述べた．まず，複数 VPN サーバの同時稼 働は，ネットワーク管理を複雑にさせる．次に，既存 SoftEther VPN Server においては，PPTP のサ の VPN サーバはマルチテナント仮想ホスティング機 ポートを除外した．PPTP は表 1 にあるように広く利 能を有していない．この章では，これらの問題を解決 用されている VPN プロトコルの 1 つである．しかし， するための我々の SoftEther VPN Server の設計につ 我々のターゲットとするデバイスはすべて L2TP と いて述べる． PPTP の両方をサポートしており，PPTP のサポー 節の構成は次のとおりである．3.1 節では，Soft- トを除外することによりサポートするデバイス数が Ether VPN Server がサポートする VPN プロトコル 減ることにはならない．加えて，PPTP には既知の について述べる．3.2 節では，VPN サーバの基本的 脆弱性があり，代替として L2TP の使用が推奨され および発展的な機能を概説する．3.3 節では，レイヤ ている [22]． 2 およびレイヤ 3 の VPN プロトコル間の相互変換に サポートするデバイスが減ることにつながらない ついて述べる．3.4 節では，レイヤ 2 およびレイヤ 3 こと，およびユーザ認証や IP アドレス割り当てのプ の間でメッセージを変換するためのアダプタにおける ロトコルが標準化されていないことを理由に，IPsec ARP および DHCP の処理について述べる．最後に， トンネリングモードのサポートも除外した． 3.5 節では，SoftEther VPN Server におけるマルチ 3. 2 SoftEther VPN Server の機能 †3 本論文で述べる PacketiX VPN は除く． †4 一部の機能を提供するものは存在する．たとえば， SoftEther VPN Server は以下のような基礎的な Cisco 社の IOS のサ ー ビス プロバイダ 向けバージョ VPN サーバ機能を提供する． ンは，Virtual Routing and Forwarding (VRF) に対 リモートアクセスおよび拠点間接続の 通 応しており，複数の VPN 顧客を 1 台の Cisco ルータ 1. VPN ハードウェアに収容し，顧客ごとの通信を分離できる． 信機能． Vol. 32 No. 4 Nov. 2015 9

2. ユーザ管理機能．ユーザの追加，削除，Re- トモニタリングや，必要な種類のパケットのヘッ mote Authentication Dial In User Service (RA- ダまたはペイロードすべてをログに保存するロ DIUS)，Microsoft Active Directory および公開 ギング機能． 鍵認証基盤 (PKI) のサポートを含む． 5. 物理的な 1 個の IP アドレスを複数の VPN ク 3. 既存の外部の DHCP サーバ，または SoftEther ライアントで共有するためのネットワークアドレ VPN Server に組み込まれている DHCP サーバ ス変換 (NAT) 機能． を用いた IP アドレスの割り当て機能．クライア 6. コマンドラインおよびグラフィカルユーザイン ントデバイスがレイヤ 2 およびレイヤ 3 のいず ターフェイス．日本語，英語および簡体字中国語 れでも，IP アドレスを割当てることができる． 版が提供されている． 4. VPN サーバが物理的に接続されている LAN へ 7. IP 優先度機能．IP ヘッダの Quality of Service のレイヤ 2 ブリッジまたはレイヤ 3 ルーティン (QoS) フィールドに応じて優先キューと非優先 グ機能． キューに振り分ける．

SoftEther VPN Server は，さらに，以下のような これらの機能は，商用製品である PacketiX VPN 発展的な VPN サーバ機能を提供する． Server 3.0 から派生したものである．PacketiX VPN 1. フォールトトレランスおよびロードバランス機 3.0 は VPN プロトコルとして SEVP のみをサポー 能．複数のサーバをグループ化し，1 台のサーバ トしていた．今回新たに設計，実装した SoftEther で障害が発生したときは，そのサーバの接続さ VPN Server は，PacketiX VPN 3.0 に複数の VPN れていた VPN セッションは他のサーバにハンド プロトコルのサポートを追加したものである． † オーバされる 5． 2. 基本的なアクセスリスト機能．多くのルータや 3. 3 レイヤ 3–2 間の変換 L3 スイッチに搭載されているパケットフィルタ SoftEther VPN Server は，3.1 節で述べたいくつ 機能と同等のものである．VPN サーバを流れる かの VPN プロトコルをサポートする．これらのプロ IPv4 および IPv6 パケットのヘッダを検査し，ア トコルは，レイヤ 2 およびレイヤ 3 に分類すること クセスコントロールリスト (ACL) に従ってパ ができる．これらの異なるレイヤの VPN プロトコ ケットフィルタリングを行う． ルを同時に取扱うためには，何らかの形でのレイヤ 3. 拡張的なセキュリティポリシー機能．一部の高 変換が必要となる．例えば，VPN サーバがレイヤ 3 性能な L3 スイッチに搭載されているセキュリ VPN プロトコルである L2TP トンネルを経由して受 ティ機能と同等のものである．基本的なアクセス 信されたとき，受信されるメッセージはレイヤ 3 パ リスト機能では検査することができない，パケッ ケットである．これをレイヤ 2 VPN プロトコルであ ト内のセキュリティに関わるフィールドの値を検 る OpenVPN L2 トンネルに対して送信するときに 査し，遮断するか否かを決定する．例えば，ARP は，レイヤ 3 パケットをレイヤ 2 フレームに変換す や DHCP の偽装パケットを遮断したり，DHCP る必要がある． スヌーピングを実施して DHCP によって割り当 我々は，図 1 に示すように，以下の 3 つの変換手 てられた IP アドレスの使用を強制したりする． 法を検討した． 4. トラブルシューティングや監査のためのパケッ 手法 1. 単一のレイヤ 2 スイッチを用いてメッセー ジを交換する (図 1 の手法 1)．すべての受信レ †5 本機能は VPN プロトコルである SEVP におけるリダ イヤ 3 パケットは，レイヤ 2 フレームに変換さ イレクション機能を用いて実装されている．その他の れる． 表 4 の VPN プロトコルには，リダイレクション機能 がない． 手法 2. 単一のレイヤ 3 スイッチ (ルータ) を用い 10 コンピュータソフトウェア

トのためにはレイヤ 3 スイッチを用いる．この 2 931 931 931 931 つのスイッチの間は，レイヤ変換機構によって接 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 嵔崌嵌 嵔崌嵌 嵔崌嵌 嵔崌嵌 続される．

崌嵛崧嵤崵崫崰 上記 3 手法のうち，手法 3 を選択すると，プログ ラムの実装が複雑になる．例えば，3.2 節で述べたア 崊崨崿崧 崊崨崿崧 クセス制御やログ保存の機能を実装する場合を考え てみる．手法 1 または手法 2 の場合は，これらの機 2 嵔崌嵌 崡崌崫崩 能はレイヤ 2 スイッチ内部にのみ実装すれば良い．一 931崝嵤崸 方，手法 3 の場合，これらの機能をレイヤ 2 スイッチ 㻔ᡭἲ㻌㻝㻕㻌༢୍䛾䝺䜲䝲㻌㻞㻌䝇䜲䝑䝏䜢⏝䛔䛶䝯䝑䝉䞊䝆䜢஺᥮ およびレイヤ 3 スイッチの両方に実装しなければな らない． 931 931 931 931 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 また，手法 2 を選択すると，レイヤ 2 VPN プロト 嵔崌嵌 嵔崌嵌 嵔崌嵌 嵔崌嵌 コルを正しくサポートすることができなくなる．例 えば，社内ネットワークにおいて拠点間通信のために 崌嵛崧嵤崵崫崰 L2TPv3 や EtherIP などのレイヤ 2 VPN プロトコ ルを使用したい場合がある．同一 L2 セグメントに収 崊崨崿崧 崊崨崿崧 容されていなければ動作しないプロトコルやアプリ ケーションを遠隔地間で使用したい場合などである． 嵔崌嵌 3 崡崌崫崩 931崝嵤崸 手法 2 は，このようなプロトコルの利用を不能にし 㻔ᡭἲ㻌㻞㻕㻌༢୍䛾䝺䜲䝲㻌㻟㻌䝇䜲䝑䝏䜢⏝䛔䛶䝯䝑䝉䞊䝆䜢஺᥮ てしまう． 一方，手法 1 は，手法 3 と比較して，プログラム 931 931 931 931 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 崗嵑崌崊嵛崰 の実装が簡単であり，また，手法 2 と比較して，レイ 嵔崌嵌 嵔崌嵌 嵔崌嵌 嵔崌嵌 ヤ 2 VPN プロトコルを正しくサポートすることがで きるようになる．そこで，SoftEther VPN Server に 崌嵛崧嵤崵崫崰 おいては，我々は手法 1 を選択した．

3. 4 レイヤ変換モジュールにおける ARP および 3 2 嵔崌嵌 崡崌崫崩 崊崨崿崧 嵔崌嵌 崡崌崫崩 DHCP の処理

931崝嵤崸 3. 4. 1 L2 アダプタ

㻔ᡭἲ㻌㻟㻕㻌䝺䜲䝲䛤䛸䛻䝇䜲䝑䝏䜢⏝䛔䛶䝯䝑䝉䞊䝆䜢஺᥮ 3.3 節で述べたように，SoftEther VPN Server は レイヤ 3 パケットをレイヤ 2 フレームに変換する．こ 図 1 レイヤ 3 パケットとレイヤ 2 フレームの間の 変換のための 3 つの手法 のような変換を実施するモジュールを L2 アダプタと 呼ぶ．図 1 の手法 1 に示すように，L2 アダプタのイ てメッセージを交換する (図 1 の手法 2)．すべて ンスタンスは，接続中の VPN クライアントごとに作 の受信レイヤ 2 フレームは，レイヤ 3 パケット 成される．L2 アダプタが VPN クライアントからレ に変換される． イヤ 3 パケットを受信したときは，L2 アダプタはそ 手法 3. レイヤごとにスイッチを用いてメッセージ れをレイヤ 2 フレームに変換し，レイヤ 2 スイッチ を交換する (図 1 の手法 3)．レイヤ 2 フレーム に転送する．同様に，レイヤ 2 スイッチが VPN クラ のためにはレイヤ 2 スイッチを，レイヤ 3 パケッ イアントへの送信のために L2 アダプタにレイヤ 2 フ Vol. 32 No. 4 Nov. 2015 11

レームを転送したときには，L2 アダプタはこれをレ イヤ 3 パケットに変換し，VPN クライアントに送信 3& 3& する． ,3崊崱嵔崡 ,3崊崱嵔崡 IP ARP IP ARP L2 アダプタの 2 つの重要な機能は，ARP の処理 NIC NIC および DHCP の処理である． 0$& 0$& 崊崱嵔崡 崊崱嵔崡 3. 4. 2 ARP の処理 ARP の処理においては，L2 アダプタは，通常の 2 PC における OS の IP スタックおよびネットワー 嵔崌嵌 崡崌崫崩 NIC: Network Interface Card クインターフェイスカード の役割を果たす． (NIC) 㻔㼍㻕㻌䝝䞊䝗䜴䜵䜰䝺䜲䝲㻌㻞㻌䝇䜲䝑䝏䜈䛾᥋⥆ 図 2 は，通常の Ethernet LAN と，SoftEther VPN Server における，ARP 処理の比較である．図 2 (a) 931崗嵑崌崊嵛崰 931崗嵑崌崊嵛崰 では，PC1 と PC2 の 2 台の PC がレイヤ 2 スイッチ 3& 嵔崌嵌 3& 嵔崌嵌 ,3崊崱嵔崡 ,3崊崱嵔崡 に接続されている．各 PC には，IP スタック，ARP IP IP ARP

処理モジュールおよび NIC がある．また，各 PC は vNIC 0$& 崊崱嵔崡 IP アドレスおよび MAC アドレスを有する． この図において，PC1 はレイヤ 3 パケット (IPv4 崌嵛崧嵤崵崫崰 データグラム) を PC2 に送信する．PC1 が PC2 に レイヤ 2 スイッチを経由してメッセージを送信する L2 1 場合，PC1 は PC2 の MAC アドレスを知る必要が 崊崨崿崧 vNIC ARP ある．PC1 は PC2 の MAC アドレスを知らないの 0$&崊崱嵔崡 で，PC1 は PC2 の IP アドレスをクエリとして書き ෘ୳ HUB 6RIW(WKHU 込んだ ARP Request パケットをブロードキャスト 9316HUYHU MAC アドレスに対して送信する．レイヤ 2 スイッチ vNIC: Virtual は，ARP Request パケットをネットワークにあるす 㻔㼎㻕㻌௬᝿㻌㻴㼁㻮㻌䜈䛾᥋⥆ Network べての PC に配信する． Interface Card PC2 は当該 ARP Request パケットを受け取ると， 図 2 2 台の PC を接続する場合におけるハードウェ アスイッチング HUB と仮想スイッチング HUB ARP Reply パケットを PC1 に対して返信する．こ との比較 の ARP Reply パケットには，PC2 の MAC アドレス が記載されている．PC1 は，PC2 の MAC アドレス HUB と呼ばれる．VPN サーバに接続中のリモート を ARP Reply パケットから抽出する．そして，PC1 PC である PC1 は，レイヤ 3 VPN プロトコルによっ は，元々送信する予定であったレイヤ 3 パケットに， て VPN サーバに接続している．もう 1 台のリモート 宛先として PC2 の MAC アドレスを追加し，レイヤ PC である PC2 は，レイヤ 2 VPN プロトコルによっ 2 フレームを構築する．最後に，PC1 は当該レイヤ て VPN サーバに接続している．PC1 と PC2 の両方 2 フレームをレイヤ 2 スイッチに送信し，フレームは は，IP アドレスを割当てられている．PC1 と VPN PC2 に配信される． サーバはレイヤ 3 パケット (IP データグラム) を交 一方，図 2 (b) は VPN サーバ内における L2 ア 換するが，PC2 と VPN サーバはレイヤ 2 フレーム ダプタの動作を示している．SoftEther VPN Server (MAC フレーム) を交換する．PC1 は TUN デバイ は，MAC アドレスを宛先として用いることでメッ スのようなレイヤ 3 の仮想ネットワークインターフェ セージを交換するための Ethernet レイヤ 2 スイッチ イスを有しており，PC2 は TAP デバイスのようなレ モジュールを有している．このモジュールは，仮想 イヤ 2 の仮想ネットワークインターフェイスを有して 12 コンピュータソフトウェア

いる．レイヤ 2 の仮想ネットワークインターフェイス パケットを送受信する際の ARP パケットの数が削減 を仮想 NIC (vNIC) と呼ぶ．PC2 の vNIC は MAC される． アドレスを有しているが，PC1 には MAC アドレス SoftEther VPN Server がレイヤ 3 VPN クライア がない．PC1 は仮想 HUB に対して L2 アダプタのイ ントからのパケットをレイヤ 2 VPN クライアントに ンスタンスを経由して間接的に接続されており，L2 対してレイヤ 2 フレームとして配信する際の仕組み アダプタは MAC アドレスを有している．一方，PC2 は，前述のとおりである．これとは反対方向の通信 は仮想 HUB に対して直接的に接続されており，L2 が行われる場合，すなわちレイヤ 2 VPN クライア アダプタのインスタンスは不要である． ントがレイヤ 3 VPN クライアントに対してメッセー 図 2 (b) において，PC1 はレイヤ 3 パケット (IPv4 ジを送信しようとする場合においては，L2 アダプ データグラム) を PC2 に送信する．PC1 が VPN サー タインスタンスは，ARP Request パケットを受け取 バに VPN トンネルを通じて当該パケットを送信する り，ARP Reply パケットを返信する．また，レイヤ とき，パケットは最初に PC1 用の L2 アダプタイン 3 VPN クライアント同士がメッセージを交換しよう スタンスに到達する．パケットには L3 (IPv4) ヘッ とする場合は，両方の VPN クライアント用に作られ ダしか含まれておらず，PC2 の MAC アドレスは記 たそれぞれの L2 アダプタのインスタンス間で，同様 載されていない．L2 アダプタは初期状態では PC2 の の ARP 処理が行われる．レイヤ 2 VPN クライアン MAC アドレスを知らないため，PC2 の IP アドレス ト同士がメッセージを交換するときは，L2 アダプタ を対象とした ARP Request パケットをブロードキャ は関係せず，両方のクライアント PC 上の IP スタッ スト MAC アドレス宛に送信する．このときの送信元 クにおける ARP モジュールによって ARP 処理が行 MAC アドレスは，PC1 用の L2 アダプタインスタン われる． スの持つ MAC アドレスである．仮想 HUB は ARP 3. 4. 3 DHCP の処理 Request パケットを，接続されているすべての PC お ARP 処理に加えて，DHCP 処理も L2 アダプタの よび L2 アダプタインスタンスに配信する． 重要な仕事である．VPN クライアントは，リモート PC2 が VPN トンネルを経由して ARP リエクス アクセスにおいて接続先の LAN 内の IP アドレスを トパケットを受信したときは，PC2 は PC1 用の L2 割当てられることを必要とする．IP アドレスは，多 アダプタインスタンスの持つ MAC アドレスを宛先 くの場合，LAN 内の既存の DHCP サーバに割り振 とする ARP Reply パケットを返信する．この ARP られた IP プールから割当てられる必要がある． Reply パケットには，PC2 の MAC アドレスが記載さ レイヤ 2 VPN クライアントが VPN サーバに接 れている．ARP Reply パケットは仮想 HUB を経由 続したときは，レイヤ 2 VPN クライアント上の IP して，PC1 用の L2 アダプタインスタンスに配信され スタック上で動作する DHCP クライアントが直接 る．当該 L2 アダプタインスタンスは，ARP Reply パ DHCP Discovery および DHCP Request パケット ケットを受信し，PC2 の MAC アドレスを抽出する． を送信し，DHCP サーバからの DHCP Offer およ そして，元々送信する予定であったレイヤ 3 パケット び DHCP Acknowledgement パケットを受信して， を元にレイヤ 2 フレームを構築し，PC2 の MAC ア vNIC に IP アドレスを割当てる．これらの処理にお ドレス宛に送信する．このフレームは，仮想 HUB お いては，L2 アダプタは必要ない． よび VPN トンネルを経由して PC2 に配信される． 一方，レイヤ 3 VPN クライアントが VPN 接続し L2 アダプタインスタンスは，通常の PC の IP ス ようとしたときには，レイヤ 3 VPN クライアント タックにおける ARP モジュールと同様に，ARP Re- 用の L2 アダプタ上に実装されている DHCP クライ ply パケットを受け取ったときは，一定期間，IP アド アントが VPN クライアント PC に代わって DHCP レスと解決された MAC アドレスとの組み合わせを Discovery および DHCP Request パケットを送信し， キャッシュに保持する．これにより，多数のレイヤ 3 DHCP サーバからの DHCP Offer および DHCP Ac- Vol. 32 No. 4 Nov. 2015 13 knowledgement パケットを受信する．そして，DHCP と，SoftEther VPN Server 上の顧客とをマッピング から割当てられた IP アドレスを DHCP パケットか することにより，各顧客はそれぞれの IaaS サービス ら抽出し，これをレイヤ 3 VPN プロトコル毎に規 上の仮想ネットワークに接続することができる．こ 定された IP アドレス割り当てメッセージに変換して の利用形態は，リモートアクセスおよび拠点間接続 VPN クライアントに送信する．レイヤ 3 VPN プロ VPN の両方の目的で活用できる． トコル毎に規定された IP アドレス割り当てメッセー ジとは，例えば L2TP over IPsec および SSTP の場 4 SoftEther VPN Server の実装 合は Internet Protocol Control Protocol (IPCP) で この章では，SoftEther VPN Server の実装につい あり，OpenVPN L3 の場合は OpenVPN プロトコル て述べる．4.1 節では内部モジュールの概要について 中におけるメタデータメッセージである． 述べ，4.2 節ではこれらのモジュールがどのように複 数の VPN プロトコルをサポートしているかを述べ 3. 5 マルチテナント仮想ホスティング る．4.3 節では我々が用いた最適化の手法について述 2.3 節において，VPN サーバにおけるマルチテナ べる．4.4 節では管理機能について述べる．最後に， ント仮想ホスティング機能の必要性を述べた．この 4.5 節ではマルチプラットフォームを実現するための 節では，マルチテナント仮想ホスティングを実現す プラットフォーム抽象化レイヤについて述べる． るために SoftEther VPN Server に実装されている 2 つの機能について述べる． 4. 1 内部モジュール 1 つ目は，単一の VPN サーバインスタンスに複数 図 3 は SoftEther VPN Server の内部モジュール の仮想 HUB を作成することができる機能である．単 を示したものである．最も重要なモジュールとして， 一の VPN サーバ内の複数の仮想 HUB 同士は，デ 以下のものがある． フォルト状態で，互いに分離されている．ホスティン 1. VPN プロトコルモジュール．7 個の VPN プロ グサービスプロバイダは，VPN サーバにおける最上 トコルをサポートする． 位の権限 (VPN サーバ全体の管理者としての権限) を 2. VPN プロトコル間の共有コンポーネント．こ 持つ．VPN サーバ全体の管理者のみが，仮想 HUB れらのコンポーネントは，SSL，HTTP，Point- の作成や削除，および各仮想 HUB の管理権限の顧客 to-Point Protocol (PPP)，IPsec およびユーザ への割り当てを行うことができる．顧客は，自己に 認証を実装する． 割当てられた仮想 HUB の管理者権限を有する．仮想 3. 3.3 節および 3.4 節で述べた L2 アダプタおよび HUB の管理者は，仮想 HUB 内にユーザを作成した 仮想 HUB． り，削除したり，その他の設定を変更したりすること 図 4 に 7 個の VPN プロトコルモジュールが受け ができる．これらの管理作業を行う際に，顧客はその 取った 7 種類の VPN プロトコルのメッセージが共有 都度，VPN サーバ全体の管理者に依頼をする必要が コンポーネントを経由して仮想 HUB に到達する様子 ない． を示す． 2 つ目は，タグ付き VLAN によるトランキング機 我々は SoftEther VPN Server を C 言語で記述し 能である．サービスプロバイダが IaaS 型のクラウ た．合計プログラムサイズは，約 390,000 行である． ドサービスを提供しており，顧客ごとに仮想ネット このうち，3.1 節から 3.4 節までに述べた複数 VPN プ ワークを定義している場合，当該仮想ネットワーク ロトコル対応機能を実装するプログラムは，約 25,000 を集約したタグ付き VLAN [13] インターフェイスを 行である．VPN プロトコル別の実装の行数は，表 2 SoftEther VPN Server の物理ホストに接続すること の通りである． ができる．IaaS 型のクラウドサービス側の顧客ごと の仮想ネットワークに割当てられている VLAN ID 14 コンピュータソフトウェア

ProtocolProtocol modulesmodules 表 2 SoftEther VPN Server のうち複数 VPN L2TPL2TP OpenVPNOpenVPN SSTPSSTP EtherIPEtherIP SEVPSEVP プロトコル対応のためのプログラムの行数の分布 LL2TPv32TPv3 LL3/L23/L2 モジュール ソースコード名 行数 (概算) SSharedhared protocolprotocol mmodulesodules L2 アダプタ IPsec IPC.c 2,100 行 PPPPPP IPsecIPsec L2L2 adapteradapter HTTPHTTP SSLSSL IPsec モジュー IPsec.c, 10,700 行 ル IPsec.h, UUII modulesmodules CCoreore VVPNPN pprocessingrocessing modulesmodules UserUser IPsec IKE.c, interfaceinterface VirtualVirtual switchingswitching hubhub IPsec IKE.h,

SSystemystem mmodulesodules IPsec IkePacket.c, UserUser AccessAccess PlatformPlatform LoggingLogging IPsec IkePacket.h aabstractionbstraction aauthenticationuthentication controlcontrol L2TP モジュー IPsec L2TP.c, 2,700 行 ル IPsec L2TP.h 図 の内部モジュール 3 SoftEther VPN Server PPP モ ジュー IPsec PPP.c, 2,800 行 ル IPsec PPP.h SoftEther VPN Server EtherIP モ ジ IPsec EtherIP.c, 500 行 Virtual switching hub ュール IPsec EtherIP.h SSTP モジュー Interop SSTP.c, 1,300 行 L2 adapter ル Interop SSTP.h L2TPv3 SEVP PPP OpenVPN モジ Interop OpenVPN.c, 3,100 行 L2TP ュール Interop OpenVPN.h HTTP EtherIP Windows Vista IPsec Win7.c, 1,800 行 OpenVPN SSL IPsec / 7 / 8 用カー IPsec Win7.h, ネルモードモジ IPsec Win7Inner.h, SEVP L2TP SSTP L2TPv3 EtherIP listener listener listener listener listener listener listener ュール Wfp.c, Wfp.h 図 4 7 種類の VPN プロトコルのメッセージが共有 合計 25,000 行 コンポーネントを経由して仮想 HUB に到達す る様子 番号を管理し，受信メッセージについてはシーケンス 4. 2 VPN プロトコル固有のモジュールおよび 番号順に並び替える処理などが必要である． 共有コンポーネント 4. 2. 2 OpenVPN モジュール 4. 2. 1 L2TP モジュール 本モジュールは OpenVPN L2 および L3 を実装す 本モジュールは VPN プロトコルである L2TP over る．これらのプロトコルは OpenVPN プロジェクト IPsec および L2TPv3 over IPsec を実装する．これ および OpenVPN Technologies, Inc. によって策定 らのプロトコルは，仕様上は 1 本の L2TP トンネル されている．これらのプロトコルは伝送レイヤとし 内に複数本のチャネルを確立することができる．通 て UDP および TCP を使用する．したがって，我々 常の VPN クライアントは 1 本のチャネルしか使用し のモジュールは，2 つの VPN プロトコルを 2 つの ないが，本モジュールは将来の拡張のために複数の 伝送レイヤ上でサポートするように実装されている． チャネル確立に対応している．L2TP および L2TPv3 OpenVPN プロトコル上における SSL の取扱いを実 の仕様はシンプルなものであるが，実装の段階では 装する際には，特に努力を要した．OpenVPN プロト 複雑なプログラミングが必要とされる．具体的には， コルは，当初は UDP のみをサポートしており，UDP L2TP トンネルおよび L2TP チャネルの確立に必要 上で SSL を用いてセキュアチャネルを確立するため なメッセージ交換において，TCP と同様のメッセー に，UDP 上に独自の TCP と同様のメッセージ再送 ジ再送機能の実装を要する．届いたメッセージに対す 機能が実装されていた．OpenVPN はその後に新た る確認応答メッセージの返信処理，送信したメッセー に TCP をサポートすることになった．したがって， ジに対する確認応答メッセージの受信を確認するまで OpenVPN プロトコルは，再送機能がもともと実装 再送キューに入れておきタイマーを用いて一定時間ご されている TCP の上に UDP がカプセル化され，そ とに再送する処理，各送受信メッセージのシーケンス の UDP 上でさらに再送機能が実装されるという複雑 Vol. 32 No. 4 Nov. 2015 15

な仕様となっている．しかし，これらの仕様は十分に 4. 2. 3 IPsec モジュール ドキュメント化されておらず，OpenVPN のソース 本モジュールは IPsec を実装する．IPsec は，L2TP， コードを解析しつつ実装を行った． L2TPv3 および EtherIP によって共有されている．本 OpenVPN L3 モジュールは，OpenVPN L3 クラ モジュールは IPsec v2 および Internet Key Exchange イアントに対して，接続時に IP アドレスを割当て， (IKE) v1 をサポートしている．IPsec v3 および IKE メタデータとしてクライアントに通知する必要がある v2 をサポートしている VPN クライアントは少数 (同時に，LAN 内で使用すべき DNS サーバの IP アド であり，これらの VPN クライアントは IPsec v2 お レスも通知することができる)．IP アドレスは，仮想 よび IKE v1 もサポートしているため，我々はこ HUB に組み込まれている DHCP サーバ機能か，ま れらのプロトコルをサポートから除外した．本モ たは既存の LAN 上の外部 DHCP サーバのいずれか ジュールは，次の追加的仕様も実装している．Ne- の IP プールから取得される必要がある．IP アドレス gotiation of NAT Traversal in the IKE from RFC の取得が完了しなければ，OpenVPN L3 モジュール 3947 [17]，draft-ietfipsec-nat-t-ike-08 [16] および a はクライアントからの接続要求を完了することができ Traffic-Based Method of Detecting Dead IKE from ない．したがって，OpenVPN L3 モジュールでユー RFC 3706 [11]．本モジュールは，伝送レイヤとして， ザ認証が完了したら，直ちに L2 アダプタのインス Encapsulating Security Payload (ESP) および ESP タンスが作成され，DHCP Discovery および DHCP over UDP の両方をサポートしている [5] [12] [15]． Request パケットが仮想 HUB を経由してブロード 4. 2. 4 PPP モジュール キャストされる．ところが，OpenVPN プロトコルは， 本モジュールは PPP を実装している．PPP は 既存の OpenVPN クライアント (Windows) 側の実 L2TP および SSTP で共有されている．本モジュール 装で独自の PPP アダプタを利用しており，PPP アダ においては，我々は PPP における複雑なユーザ認証 プタの利用の実装上の固有の問題により，割り当てら 処理を実装した．本モジュールは，広く使用されてい れる IP アドレスの第 4 オクテットが，「4 の倍数+1」 る 2 つの認証プロトコルである Password Authenti- でなければならないという制約がある．OpenVPN cation Protocol (PAP) および Microsoft Challenge L3 プロトコルは本来，OpenVPN 専用に大きな IPv4 Handshake Authentication Protocol version 2 (MS- サブネットを割当てておく利用方法を想定して開発 CHAPv2) をサポートしている．ユーザ認証は，Soft- されていたため，SoftEther VPN Server の実装上の Ether VPN Server 内部のユーザデータベースによる 目標である，VPN プロトコルにかかわらず共通の パスワード認証だけではなく，外部の RADIUS およ IP アドレス割り当ての仕組み (既設 DHCP サーバ び Microsoft Active Directory サーバによる認証に の利用) と親和性に欠けることが分かった．なぜな も対応している． らば，DHCP サーバに対して「第 4 オクテットが 4 VPN クライアントが PAP を用いる場合，VPN ク の倍数+1 となる IP アドレスをください．」というよ ライアントから VPN サーバへは，平文でパスワード うな要求はできないためである．そこで，解決策と が送信される．実際には IPsec によって暗号化される しては DHCP サーバから，第 4 オクテットが「4 の が，これは危険であり，多くの VPN クライアントでは 倍数+1」となるような IP アドレスの割り当てがオ デフォルトで無効化されている．デフォルトで有効な ファーされるまでの間は繰り返し IP アドレスを要求 MS-CHAPv2 は Microsoft 独自の CHAP 認証プロト し，そのような IP アドレスがようやく提示された後 コルであるが，事実上の標準となっており，Microsoft にその他に仮に取得した全 IP アドレスを解放すると の OS のほか，Mac OS X，iOS および Android で いう仕組みを実装した． もサポートされている．したがって，MS-CHAPv2 への対応は必須である．ところが，SoftEther VPN Server が外部の Microsoft Active Directory サーバ 16 コンピュータソフトウェア

に対して MS-CHAPv2 の認証要求を転送する方法が 崯嵤崧ଡୗ ન৳岿島峉嵉嵊嵒୩ୠ峘崝崌崢 LQWPHPVL]H ドキュメント化されておらず，対応に苦労した．最 ન৳岿島峉嵉嵊嵒୩ୠ ৰ崯嵤崧୩ୠ 終的には，我々は Windows 2000 Server 組み込みの 嵂崌嵕嵤崱ಉ

RRAS サーバのプログラムを吟味することにより， ৰ崯嵤崧୩ୠ峘崝崌崢 LQWVL]H

LsaLogonUser API において MS-CHAPv2 の認証要 ન৳岿島峉 ৰ崯嵤崧୩ୠ峘੔୍ 嵉嵊嵒୩ୠ峘੔୍ 峘ਜ਼઼ 求を出すための隠し構造体利用方法を発見し，これを XQVLJQHGFKDU S LQWSRV 利用することで解決した． 嵀崫崨୯੶崒嵂嵔嵤崟嵏嵛SRV峼৏୐岿峅峵 ન৳岿島峉嵉嵊嵒୩ୠ峘崝崌崢 LQWPHPVL]H PPP モジュールは，IP アドレスをリモートの VPN 嵀崫崨 嵂崌嵕嵤崱 クライアントに対して割当てる役割も担っている． ୯੶

OpenVPN L3 プロトコルと同様，PPP の接続確立 ৰ崯嵤崧୩ୠ峘崝崌崢 LQWVL]H 峼 嵀崫崨ীਸ઴峃峵 に先立って，L2 アダプタのインスタンスを作成し， ৰ崯嵤崧୩ୠ峘੔୍峘ਜ਼઼ LQWSRV 峼嵀崫崨ী੖઴峃峵 DHCP サーバから IP アドレスを取得する．取得し 嵀崫崨చ௾崒嵂嵔嵤崟嵏嵛SRV峼৐ਤ岿峅峵 た IP アドレスは，PPP トンネル上で動作する IPCP ન৳岿島峉嵉嵊嵒୩ୠ峘崝崌崢 LQWPHPVL]H

を用いてクライアントに通知される． 内で利用 嵀崫崨 LAN 嵂崌嵕嵤崱 చ௾ すべき DNS サーバの IP アドレスもオプションとし ৰ崯嵤崧୩ୠ峘崝崌崢 LQWVL]H て通知することができる． 峼嵀崫崨ী੖઴峃峵 ৰ崯嵤崧୩ୠ峘੔୍峘ਜ਼઼ 4. 2. 5 Windows カーネルドライバモジュール LQWSRV 峼嵀崫崨ীਸ઴峃峵 IPsec サーバ機能を Windows Vista およびそれ以降 図 5 ヘッダの取り付け，取り外しにおいてメッセー のバージョンの Windows 上で実装するために，カー ジコピーの回数を削減するためのデータ構造とオ ペレーション ネルハックを行う必要があった．Windows カーネル は，IPsec データグラムをネットワークインターフェ 装を行うと，メッセージコピーやスレッド同期による イスから受け取った後，たとえそのデータグラムのた オーバーヘッドが大きく発生する． めに bind されているユーザプロセスのソケットが存 SoftEther VPN Server 内部においては，OS カー 在したとしても，そのユーザプロセスにデータグラム ネル内で用いられるのと同様の，不必要なメッセー を渡さずに，カーネル内で自ら IPsec 処理をしてしま ジコピーの回数の削減を行う手法を部分的に用いた． う．このドキュメント化されていない挙動は，ユーザ 多くの OS カーネルでは，受信したメッセージや送信 プロセスが IPsec データグラムを独自に処理するこ しようとするメッセージを複数のモジュール間で交換 とを不可能にしている． する．また，この際にヘッダを取り外したり取付けた この Windows における問題を解決するため，我々 りする処理を行う．この際のメッセージコピーの回数 は Windows Filtering Platform 用のカーネルドライ を削減するため，例えば BSD では mbuf，Linux で バを実装した．本ドライバは Windows カーネルが は skbuf，Windows では NET BUFFER LIST およ IPsec データグラムを読み取るよりも前に，IPsec デー び NET BUFFER などのデータ構造体が利用されて タグラムのヘッダを一時的に書き換える．Windows いる．SoftEther VPN Server においては，これらの カーネルはこれを IPsec データグラムではないと解 既存のデータ構造体の機能を簡素化したデータ構造 釈し，ユーザプロセスに渡す．ユーザプロセスでは書 体を用いた (図 5)．このデータ構造体では，当初必要 き換えられたヘッダを元に戻して処理をする． なデータの領域の前後のメモリ領域も予約しておき， データの先頭位置および末尾位置を前進または後退 4. 3 最適化手法 させる方法により，メモリのコピーや再確保なしで， VPN サーバは内部に多数のメッセージキューおよ データの追記と削除ができる．本データ構造体のオペ びスレッドを有している．十分な考慮を行わずに実 レーションでは，汎用メモリ管理関数しか使用してい Vol. 32 No. 4 Nov. 2015 17

ないため，OS 間の移植性を有する． SoftEther VPN Server は，モジュール間の同期と メッセージ交換におけるオーバーヘッドを削減する ために，2 種類のメッセージキューを実装している． 1 つ目はロック付きの通常のキューであり，2 つ目は 高速に動作するロックなしのキューである．我々はま た，同一の VPN コネクションから同時に届いたメッ セージを処理する際のロックの回数を削減した．これ らのキューは OS の同期機能を内部で利用しているた め，移植性を確保するために，プラットフォーム抽象 化レイヤ内に実装されている．

図 6 SoftEther VPN Server で 複 数 の 仮 想 4. 4 管理機能 HUB を管理する画面 2.2 節で述べたとおり，複数の VPN プロトコルの サポートのために複数の VPN サーバを稼働させるこ とは，設定や運用作業を複雑にする．SoftEther VPN Server では，この問題を解決するために，すべての VPN プロトコル間で，ユーザ認証やアクセスコント ロール，ログ管理等を共通化している． ネットワーク管理者やマルチテナント仮想ホスティ ング機能を利用する場合の各顧客は，VPN プロトコ ルを意識せずに共通化されたインターフェイスを用い て SoftEther VPN Server の管理を行うことができ 図 7 SoftEther VPN Server の仮想 HUB のア る．利用可能なインターフェイスは，以下の 3 種類で クセスリストを設定する画面 ある． 4. 4. 1 GUI 装して SoftEther VPN Server に RPC 接続すること VPN Server Manager と呼ばれるグラフィカルユー により，GUI または CUI ツールと同様に VPN サー ザインターフェイス (GUI) を実装した．Windows お バを操作することができる．GUI および CUI ツール よび WINE 環境のインストールされた Linux 上で動 は，内部的には RPC を呼び出している． 作する．図 6 および図 7 は，GUI の画面例を示す． 4. 4. 2 CUI 4. 5 プラットフォーム抽象化レイヤ vpncmd と呼ばれるコマンドラインユーザインター SoftEther VPN Server は，VPN サーバ機能を実 フェイス (CUI) を実装した．SoftEther VPN Server 装する上位のプログラムコードと，それらのプログラ のサポートするすべての OS で動作する． ムが呼び出す下位のプラットフォーム抽象化レイヤの 4. 4. 3 RPC コードとに分離されている．これにより，VPN サー SoftEther VPN Server は Remote Procedure Call バ機能を提供するプログラムを 1 回書くだけで，複 (RPC) を受け付ける．マルチテナント仮想ホスティ 数の OS 用にプログラムをコンパイルでき，それぞれ ングサービス等で，管理用ポータルサイトや顧客管理 の OS 上で同等に動作させることができる． システムから SoftEther VPN Server を制御したい プ ラット フォー ム 抽 象 化 レ イ ヤ は ，Windows， 場合は，これらのシステムに RPC クライアントを実 Linux，Mac OS X，FreeBSD および Solaris 用に 18 コンピュータソフトウェア

実装されている．Windows とそれ以外の UNIX 互換 りする部分を吸収する．また，文字コード変換におい OS とは大きく異なるが，UNIX 互換 OS でもそれぞ て Windows では Native Language Support (NLS) れ細かな違いがある． API を，UNIX では iconv を使用する． プラットフォーム抽象化レイヤが実装する機能は， 4. 5. 5 モノトニック時刻の供給 以下のような低レベル処理である． モノトニック時刻とは，OS 起動中に常にインクリ 4. 5. 1 メモリ管理 メントされる，相対的な，逆戻りすることがないこと 一般的なメモリ管理関数である malloc，realloc， が保証されている時計の値である．システム時計の free に加え，OS が提供するより高速な API が利用 変更に応じてモノトニック時刻が影響されてはなら 可能である場合は利用する．例えば，Windows では ない．VPN 通信のタイムアウトや再送処理，内部的 デバッグ時にはヒープ破損のチェックが可能な malloc な仮想 TCP/IP スタックの処理等に多用されている． 系を利用するが，リリース時には HeapAlloc 系 API SoftEther VPN Server で必要な 10ms の精度を，低 を利用することによりオーバーヘッドを軽減する． いオーバーヘッドで得る必要がある． 4. 5. 2 スレッドおよび同期 Windows においては timeGetTime() API で確 システム間のスレッドモデルの違いを吸収する． 実 に 取 得 で き る が ，UNIX 互 換 OS に よって は Windows では Win32 スレッド，イベント，クリティ clock gettime() を用いても正しく取得できない場 カルセクションを使用し，UNIX 互換 OS では pthread 合がある．また，取得できてもオーバーヘッドが大き によるスレッド，cond (条件変数)，パイプ，mutex お い場合もある．これらの差異を吸収するだけではな よび futex を使用する．これらのオブジェクトの取扱 く，OS によってはオーバーヘッドを削減するために い (特に待機関数の性質や再帰ロックの可否等) の差 モノトニック時刻を 10ms 間隔で取得し続ける専用の 異を吸収する．また，スレッドプールを実装し，一部 スレッドを作成している． の環境でのライブラリ側におけるスレッド作成時にメ 4. 5. 6 デバッグ支援モジュール モリリークが生じるバグを回避する． 開発時においてメモリリークおよびリソースリー 4. 5. 3 ソケット クを発見するために，独自のオブジェクト管理コード TCP および UDP 通信を行う際のソケット API は を実装した．メモリ以外にもファイルディスクリプタ OS によって挙動が異なる．たとえば非同期通信を やソケット，ロック等のリソースの作成，削除を追跡 実現するためには Windows ではオーバーラップ IO， できる．また，リークしている行番号も表示可能であ IO 完了ポート (I/O completion ports) およびイベ る．デッドロックが発生した場合は，ロックの参照元 ントへの関連付けが利用可能であり，UNIX 互換 OS を辿り循環参照を発見することもできる．これらの では select，poll，epoll が利用可能である．UNIX 互 デバッグ支援機能は，リリース時には自動的に削除さ 換系における差異としては，非同期モードに関係す れ，高速なコードが生成される． る ioctl のコードが異なったり，すでに受信キューに データが入っている場合に新たにデータを受信した 5 評価 際の通知の有無が異なったり，送信バッファが空いた 本章では，SoftEther VPN Server について定性的 のに通知されないといった細かな部分がある．また， および定量的な側面から評価を行う．定性的な評価に connect() や accept() を別スレッドからキャンセル おいては，複数の VPN プロトコル間における相互運 する方法についても違いがある．このような差異を吸 用性およびマルチテナント機能について評価を行う． 収する． 定量的な評価においては，パフォーマンスの計測お 4. 5. 4 文字列処理 よび SoftEther VPN Server の普及度合いについて wchar t 型のサイズやフォーマットが異なったり， 評価を行う．これらの結果により，我々は SoftEther sprintf 系関数におけるフォーマット書式が異なった VPN Server が第 2 章において述べた問題を最小の Vol. 32 No. 4 Nov. 2015 19

オーバーヘッドで解決できることを示す．さらに， 表 3 SoftEther VPN Server への接続テストに SoftEther VPN Server を実運用環境に導入した結果 用いた VPN クライアントの一覧 プロトコル クライアント について評価を行う．これにより，我々は SoftEther VPN VPN L2TP/IPsec iPhone (iOS 4, 5, 6, 7, 8) VPN Server が既存の VPN サーバと同等の安定性を iPad (iOS 4, 5, 6, 7, 8) Android (2, 3, 4) 有していることを示す． Windows Vista, 7, 8, 8.1, RT Mac OS X ( 10.6, 10.7, 10.8, 10.9) SSTP Windows Vista, 7, 8, 8.1, RT 5. 1 相互運用性 OpenVPN L3 OpenVPN Client 2.2 for Linux 表 3 は SoftEther VPN Server をテストする際に用 OpenVPN Client 2.2 for Windows OpenVPN Connect for iOS いた VPN クライアントの一覧である．これらのすべ OpenVPN Connect for Android ての VPN クライアントは，SoftEther VPN Server OpenVPN L2 OpenVPN Client 2.2 for Linux OpenVPN Client 2.2 for Windows に接続することができた． OpenVPN Connect for iOS OpenVPN Connect for Android 表 は，広く利用されている サーバおよび 4 VPN L2TPv3/IPsec Cisco 892J, Cisco 1812J, IIJ SEIL x86 それらの VPN サーバがサポートしている VPN プ EtherIP NEC IX2015 SEVP SoftEther VPN Client for Windows ロトコルの一覧である．SoftEther VPN Server は， SoftEther VPN Client for Linux PPTP および IPsec トンネリングモードを除き，本 表にあるすべての VPN プロトコルをサポートして 5. 3 SoftEther VPN Server のインストール数 いる．我々が SoftEther VPN においてこれら 2 個の SoftEther VPN Server は，2013 年 3 月から 2014 VPN プロトコルをサポートしなかった理由は，3.1 年 9 月までの間に，世界中で 242,000 回インストール 節で述べたように，これらのプロトコルには脆弱性 された．インストール数は，SoftEther VPN Server および互換性の問題があり，また，サポートの除外に に組み込まれておりデフォルトで有効化されている よって，サポートする VPN クライアントの種類が減 ダイナミック DNS (DDNS) クライアントプログラ 少しないためである．これらの結果は，我々が 2.2 節 ムの DDNS ホスト登録数によって推計した．インス で述べた，複数の VPN プロトコルのサポートのため トール数の推移は，図 8 のとおりである．図 9 は， に複数の VPN サーバを同時稼働させる場合に生じる SoftEther VPN Server がインストールされたサーバ 以下の問題を解決できたことを意味する． の IP アドレスによって分析した所在国の分布を示す． 1. VPN サーバの管理が複雑となる問題． 第 1 位は日本 (26 %) であるが，残りの 74 % はその 2. 複数のハードウェアリソースが必要となる問題． 他の国 (米国，中国，ヨーロッパ，その他) である．

5. 2 相互運用性 5. 4 パフォーマンス 2.3 節において，VPN サーバはマルチテナント仮想 本節では，SoftEther VPN Server のパフォーマン ホスティングが必要である旨を述べた．また，3.5 節 スについて述べる．特に，SoftEther VPN Server が において，SoftEther VPN Server におけるマルチテ 複数の VPN プロトコルの通信を同時に処理する際 ナント仮想ホスティングの実装について述べた．我々 のオーバーヘッドが小さく，通信速度が従来の VPN は単一の VPN サーバインスタンスにおいて複数の仮 サーバと比較して高速である点について述べる． 想 HUB の作成，およびタグ付き VLAN のサポート 5. 4. 1 実験環境およびベンチマークプログラム を実装した．これにより，サービスプロバイダは顧客 実験においては，3 台の同一仕様の PC を使用した． のために VPN サーバを運用することができる．した 各 PC は Intel Xeon E3-1230 3.2GHz CPU，16GB がって，SoftEther VPN Server はマルチテナント仮 のメモリおよび 1 枚の 10 Gigabit Ethernet NIC (In- 想ホスティングをサポートしている． tel 10 Gigabit CX4 Dual Port Server Adapter，2 個の CX4 ポートを有する) を有する．PC の OS は 20 コンピュータソフトウェア

表 4 広く利用されている VPN サーバおよび各 VPN サーバがサポートしている VPN プロトコルの一覧

レイヤ 3(IP パケット) を伝送する VPN プロトコル レイヤ 2(MAC フレーム) を伝送する VPN プロトコル VPN サーバ IPsec ト L2TP / PPTP SSTP OpenVPN OpenVPN L2TPv3 / EtherIP / SEVP ンネルモー IPsec L3 L2 IPsec IPsec ド Microsoft RRAS ✓ ✓ ✓ Mac OX X Server ✓ ✓ OpenVPN ✓ ✓ 企業向けルータ ✓ ✓ ✓ ✓ PacketiX VPN 3.0 ✓ SoftEther VPN ✓ ✓ ✓ ✓ ✓ ✓ ✓ Server 「企業向けルータ」とは，Cisco，Extreme Networks，Brocade，F5 Networks 等の販売する専用ルータ装置を意味する．

300,000 3& 3& ) 250,000 ྎ ( 200,000 NIC1 NIC2 150,000 NIC1 NIC2

100,000

䜲䞁䝇䝖䞊䝹ᩘ 50,000

0 NIC1 NIC2 12/08 12/10 12/12 13/02 13/04 13/06 13/08 13/10 13/12 14/02 14/04 14/06 14/08 ୡ⏺ ᪥ᮏᅜෆ 3&

図 8 SoftEther VPN Server のインストール数累計 NIC: Network Interface Card (Intel 10GbE CX4 Dual Port Server Adapter) 図 10 3 台の実験用 PC の物理的な接続図

Other 187 Japan, Hong regions, 63,635 我々の TrafficServer / TrafficClient ツールを使用し Kong, 61,926 4,472 た．本ツールは iperf [7] と同様に，一定期間内にで きる限り多くのパケットを送受信し，スループットを Canada, 測定する． と異なり，本ツールは同時に 本の 5,126 iperf 32 France, United TCP コネクションを確立し，そのうち 16 本は送信方 5,218 States, India, 5,804 36,060 向，残り 16 本は受信方向でスループットを同時に測 Korea, 5,905 China, 定可能である．本ツールのソースコードは SoftEther Russia, 6,542 24,337 Germany, United VPN Server のソースコードの一部として公開されて Taiwan, 7,184 Kingdom, 8,546 いる． 8,866 図 10 に，3 台の実験用 PC の物理的な接続を示す． 図 9 SoftEther VPN Server がインストール VPN 通信速度を計測する前に，まず，PC1 をルータ されたサーバの所在国とインストール数 として，PC2 と PC3 との間のスループットを測定し Windows Server 2008 R2 x64 を基本として使用し， た．スループットは約 9.95Gbps であった．これによ 実験の必要上 Linux が必要な場合 (OpenVPN を用い り，PC1 の CPU は 10Gbps の接続を十分利用でき た実験を行う場合) においては Linux Kernel 2.6.32 る程度に高速であることを確認した．以下の実験で (x64) を使用した． は，CPU によって処理される暗号化のためにスルー 速度測定には，Windows および Linux で動作する プットはより低速となっている． Vol. 32 No. 4 Nov. 2015 21

表 5 性能測定に利用した VPN プロトコル，既存のネイティブ VPN サーバおよび VPN クライアント

VPN プロトコル 暗号化アルゴリズム 比較対象の VPN サーバ VPN クライアント L2TP IPsec (AES128-CBC) Microsoft RRAS (Windows Server 2008 R2 上) Windows Server 2008 R2 組み込み L2TP IPsec (AES128-CBC) xl2tpd 1.3.6 (Linux 2.6.32 上) xl2tpd 1.3.6 (Linux 2.6.32 上) SSTP RC4 Microsoft RRAS (Windows Server 2008 R2 上) Windows Server 2008 R2 組み込み OpenVPN AES128-CBC OpenVPN 2.2.2 (Linux 2.6.32 上) OpenVPN 2.2.2 SEVP RC4 SoftEther VPN Server SoftEther VPN Server

5. 4. 2 VPN プロトコル 我々は表 5 にある各 VPN プロトコルについて， 3& SoftEther VPN Server と既存の VPN サーバプロ VPN client グラムとの間でのパフォーマンスの比較を行った． SoftEther VPN Server は実際には表 4 にある VPN プロトコルすべてに対応しているが，これらの中の いくつかの VPN プロトコルには，ハードウェアルー 3& 3& タが必要となるなど，Windows および Linux 環境に VPN server おいて動作させることが困難なものがある．そこで， これらのプロトコルは速度測定から除外し，表 5 の プロトコルのみ測定を行った． /$1 OpenVPN を含むテストにおいては，OpenVPN 㻔㼍㻕㻌㼂㻼㻺㻌䜽䝷䜲䜰䞁䝖䛸㻌㻸㻭㻺㻌ୖ䛾㻌㻼㻯㻌䛸䛾㛫䛾㻌㼂㻼㻺㻌㏻ಙ L3 プロトコルを用いた．また，当初は Windows 環境 において実験を行ったが，OpenVPN Technologies, Inc. によるオリジナルの OpenVPN の Windows 版 3& 3& プログラムにおける UDP データグラムの扱いが最 VPN client VPN client 適化されておらず，そのプログラムがボトルネック となったために 100Mbps 以上の速度が出なかったた め，代わりに Linux 環境で実験を行った． L2TP を含むテストにおいては，OpenVPN との 3& 組み合わせ実験の際にはサーバ，クライアント共に VPN server xl2tpd 1.3.6 (Linux 2.6.32 上) を用い，それ以外の 実験の際には Windows Server 2008 R2 組み込みの ソフトウェアを用いた． 㻔㼎㻕㻌㻞㻌ྎ䛾㻌㼂㻼㻺㻌䜽䝷䜲䜰䞁䝖ྠኈ䛾㏻ಙ 5. 4. 3 実験の構成 図 11 実験環境における論理的接続図 スループット測定実験は，図 11 に示すように 2 種 類の構成で行った． ロトコル単体での性能を測定することができる． 1. 実験 A. 1 台の VPN クライアントと LAN 上の この構成は，社内 LAN へのリモートアクセスで 1 台の PC との VPN 通信 (図 11 (a))． よく見られる構成である． PC1 は VPN サーバとして動作し，PC2 は VPN 2. 実験 B. 2 台の VPN クライアント同士の通信 クライアントとして動作する．PC3 では VPN (図 11 (b))． ソフトウェアは動作させず，PC1 上のソフトウェ PC1 は VPN サーバとして動作し，PC2 および アブリッジを経由して，PC1 に VPN 接続してい PC3 は VPN クライアントとして動作する．こ る PC2 と通信を行う．したがって，各 VPN プ の構成においては，2 個の VPN クライアントは， 22 コンピュータソフトウェア

実験 B1 においては同一，実験 B2 においては異 ᐇ㦂A. VPN 䜽䝷䜲䜰䞁䝖䛸 LAN ୖ䛾 PC 䛸䛾㏻ಙ (༢୍ VPN 䝥䝻䝖䝁䝹) なる VPN プロトコルを使用して VPN サーバに 1200 1000 接続する．したがって，異なる VPN プロトコル 800 (Mbps) 600 同士の各種組み合わせにおける性能を測定する 400 200 ことができる． 0 L2TP SSTP OpenVPN SEVP 䝇䝹䞊䝥䝑䝖 OpenVPN との組み合わせ実験は，ネイティブ VPN 䝥䝻䝖䝁䝹 Linux 上で動作が可能な L2TP/IPsec および ẚ㍑ᑐ㇟䛾䝛䜲䝔䜱䝤 VPN 䝋䝣䝖䜴䜵䜰 So Ether VPN Server SEVP のみを対象とした．Linux 上で動作す 図 12 1 台の VPN クライアントと LAN 上の 1 る SSTP サーバの実装は我々の SoftEther VPN 台の PC との VPN 通信スループット Server 以外には存在しなかったため，SSTP と ᐇ㦂 B1. VPN 䜽䝷䜲䜰䞁䝖䛸 VPN 䜽䝷䜲䜰䞁䝖䛸䛾㏻ಙ (ྠ୍ VPN 䝥䝻䝖䝁䝹) OpenVPN との組み合わせは行っていない． 1200 1000 5. 4. 4 実験結果 800 (Mbps) 600 図 12 に実験 A の結果を示す．これは，単一の VPN 400 200 プロトコルを用いて，VPN クライアントと LAN 上 0

䝇䝹䞊䝥䝑䝖 L2TP SSTP OpenVPN SEVP の PC との VPN 通信を実施したものである．L2TP VPN 䝥䝻䝖䝁䝹 においては，SoftEther VPN Server は Windows 標 ẚ㍑ᑐ㇟䛾䝛䜲䝔䜱䝤 VPN 䝋䝣䝖䜴䜵䜰 So Ether VPN Server 準の RRAS 機能とほぼ同等の速度となった．SSTP 図 13 同一 VPN プロトコルを用いた 2 台の VPN においては，Windows 標準の RRAS 機能のほうが クライアント同士の VPN 通信スループット SoftEther VPN Server よりも高速な結果となった． ᐇ㦂 B2. VPN 䜽䝷䜲䜰䞁䝖䛸 VPN 䜽䝷䜲䜰䞁䝖䛸䛾㏻ಙ (┦㐪 VPN 䝥䝻䝖䝁䝹) これは，RRAS の VPN モジュールがすべて Windows 800 700 カーネルに実装されているのと比較して，SoftEther 600 (Mbps) 500 400 VPN Server の大部分はユーザプロセスとして実装さ 300 200 れていることが理由である．SSTP および SEVP は 100 䝇䝹䞊䝥䝑䝖 0 L2TP よりも高速となった．これは，SSL において L2TP-SSTP L2TP-SEVP SSTP-SEVP OpenVPN-L2TP OpenVPN-SEVP 軽量なアルゴリズムである RC4 が使用されているた VPN 䝥䝻䝖䝁䝹䛾⤌䜏ྜ䜟䛫 ẚ㍑ᑐ㇟䛾䝛䜲䝔䜱䝤 VPN 䝋䝣䝖䜴䜵䜰 So Ether VPN Server めである．OpenVPN においては，SoftEther VPN Server よりも OpenVPN のオリジナル実装のほうが 図 14 異なる VPN プロトコルを用いた 2 台の VPN クライアント同士の VPN 通信スルー 約 12%高速な結果となった．OpenVPN のオリジナ プット ル実装は，OS のカーネルドライバ (tun ドライバ) とのメッセージ交換と OpenVPN クライアントとの メッセージ交換の双方ともレイヤ 3 のメッセージであ る．SoftEther VPN Server は 3.3 節で述べたように レイヤ 3–2 変換を行う．この変換オーバーヘッドが， 約 12%の速度差に含まれているものと思われる． 図 13 に実験 B1 の結果を示す．これは，同一の プロトコルを用いて， 台の クライアン VPN 2 VPN 図 15 異なる OS において SoftEther VPNServer を ト間で VPN サーバを経由した通信を実施したもの 動作させた場合の VPN 通信スループット である．L2TP，SSTP および SEVP においては実 験 A と同等の結果となったが，OpenVPN において は SoftEther VPN Server のほうが高速となった．そ Vol. 32 No. 4 Nov. 2015 23

の理由として，実験 B1 では VPN サーバは 2 本の ている． VPN コネクションを同時に処理しなければならず， 5. 5. 1 VPN Gate Server への組み込み その際に AES の復号化と暗号化の処理を行わなけれ 我々は ，SoftEther VPN Server を 用 い て VPN ばならないが，OpenVPN はシングルスレッドで複数 Gate [25] システムを実装した．VPN Gate は，Great の VPN セッションを処理しているため AES の処理 Firewall of China 等の検閲用ファイアウォールを回 を同一のプロセッサで実行しなければならず，一方， 避するための中継システムである．VPN Gate で SoftEther VPN は複数スレッドで複数の VPN セッ は，Tor と同様に，組織化されたボランティアによっ ションを処理しているため 2 個の AES 処理が並列し て提供される VPN サーバを提供する．Tor [4] と異 て動作するため高速な結果となっている点が挙げら なり，VPN Gate は匿名性を提供しないが，任意の れる． TCP/UDP パケットを高速に中継することができる． 図 14 に実験 B2 の結果を示す．これは，異なる VPN Gate システムにおけるボランティアの Win- VPN プロトコルを用いて，2 台の VPN クライアン dows PC 上では，VPN Gate Server と呼ばれる中継 ト間で VPN サーバを経由した通信を実施したもの サーバが稼働する．VPN Gate Server は SoftEther である．実験 B1 の結果と異なり，すべての組み合わ VPN Server を組み込んだプログラムである．VPN せについて SoftEther VPN Server のみを使用した Gate Server は，本研究において実装した L2TP， 場合が，比較対象の 2 つのネイティブ VPN ソフト SSTP，OpenVPN L3 および SEVP のクライアント ウェアを使用した場合と，少なくとも同じ程度の速 を受け付ける． 度か，または高速な速度を実現している．L2TP およ 我々は VPN Gate を 2013 年 3 月に公開した．2014 び SSTP の組み合わせの場合については，SoftEther 年 9 月時点では，常時約 8,000 台のボランティアサー VPN Server は RRAS と比較して 7%も高速である． バが世界中で稼働している．このうち 32 台は，我々 高速な結果となった理由は，2 個の VPN サーバを組 によってホストしているサーバである．全世界のボ み合わせて使用する場合と比較して，SoftEther VPN ランティアサーバには，2013 年 3 月から 2014 年 9 Server の単一インスタンスで処理を行うほうがメッ 月までに合計 7.8 億本の VPN コネクションが接続 セージコピーおよびコンテキストスイッチの回数が減 され，12.7 ペタバイトのトラフィックが中継された． 少するためである． このうち，我々がホストする 32 台のサーバは，合計 SoftEther VPN Server は，Windows だけではな 4,469 万本の VPN コネクションを受け付け，2.5 ペタ く Linux，Mac OS X，FreeBSD および Solaris で バイトのトラフィックを中継した．これらの期間中に も動作する．図 15 は，特に Windows Server 2003 我々がホストする 32 台のサーバの VPN Gate Server R2 x64，Windows Server 2008 R2 x64 および Linux には 1 件のクラッシュにつながるバグが発見された． カーネル 2.6.32 を動作させた CentOS 6 において同 当該バグは，SoftEther VPN Server とは無関係の， 一条件で VPN 通信を行った際のスループットの比較 VPN Gate Server への拡張時に記述されたコードに である．この実験においては，実験 A と同様に SEVP 関係するバグであった．当該バグ以外に，VPN Gate を用いて実験を行った．古いバージョンの Windows Server のクラッシュやメモリリークは発見されてい Server が最も高速な結果となった．Linux において ない． は Windows よりも 6%低速であり，さらなる最適化 5. 5. 2 仮想 HUB レンタルサービスの実験 の余地が残されている． 我々は，SoftEther VPN Server のマルチテナント 仮想ホスティング機能を評価するため，8 台の Soft- 5. 5 安定性 Ether VPN Server をインストールしたサーバをイ SoftEther VPN Server は，以下のような多様な環 ンターネットに接続し，誰でも Web サイトから仮 境で安定して動作することから，十分な安定性を有し 想 HUB を作成し登録することができるようにした． 24 コンピュータソフトウェア

本仮想 HUB レンタルサービスは，2006 年 10 月に， 発見されていない． SoftEther VPN Server の元となった商用版 PacketiX 5. 5. 3 製品版ソフトウェア等の実績 VPN Server を用いて開始された．2014 年 9 月まで SoftEther VPN Server の元となった商用版 Pack- に作成された仮想 HUB の数は合計 141,270 個であ etiX VPN Server の最初のバージョンである Version り，合計 4 ペタバイトのトラフィックを転送した．仮 2.0 は，ソフトイーサ株式会社より 2005 年 12 月に 想 HUB は，ユーザ登録により自動的に作成され，2ヶ 発売された．IPv6 への対応等が実施された次のバー 月以上 1 度も利用されない場合は自動的に削除される ジョンである Version 3.0 は，2010 年 3 月に発売さ 仕組みである．これには，4.4.3 節で述べた RPC が れた．SoftEther VPN Server によって実装された複 利用されている．また，8 台のサーバは 3.2 節で述べ 数 VPN プロトコル対応バージョンは，Version 4.0 † たフォールトトレランスおよびロードバランス機能を として 2013 年 7 月に発売された 8．これらの製品版 使用してグループ化し，ユーザからは 1 個のシステ を導入した企業等の顧客数は，2014 年 9 月時点で約 ムに見えている．2014 年 9 月時点では，グループ全 5,500 である．これらの企業ユーザからは，PacketiX 体で常時約 2,300 個の仮想 HUB をホストしており， VPN Server のプログラムが原因でクラッシュが発 グループ全体で約 3,000 本の VPN セッションが確立 生する報告はない．同様に，5.3 節で述べたオープン † † されている 6 7．したがって，1 台のサーバには平均 ソース版のユーザからも，SoftEther VPN Server が 約 375 本の VPN セッションが接続されている．本仮 原因でクラッシュが発生する報告は，パーソナルファ 想 HUB レンタルサービスは，2006 年 10 月から現在 イアウォールソフトウェアのカーネルモードモジュー まで安定して稼働している．サービス開始当初はデッ ルの不具合であると考えられる問題を除き，寄せられ ドロックが発生する問題が 1 件，サーバが再起動し ていない． た後に全 VPN クライアントから大量の SSL 通信が 5. 5. 4 ハードウェアへの組み込みの実績 同時に接続されようとして CPU 負荷が高くなり，全 商用版 PacketiX VPN Server 4.0 は，複数のハー VPN クライアントの接続処理でタイムアウトが生じ ドウェアベンダから VPN アプライアンスとして出 † て再接続が繰り返される問題が 1 件発見された．デッ 荷されている 9．これらのハードウェアは，異なる ドロックの問題についてはデバッグにより，SSL 通信 CPU で動作している Linux アプライアンスである． の大量接続時の問題は SSL ネゴシエーションフェー ハードウェアの出荷数は非公開であるが，おおむね数 ズに進入することを許可する同時コネクション数の上 百程度である．これらのハードウェア上の PacketiX 限数を設定することにより解決した．当該バグ以外 VPN Server における安定性に関する問題の報告は寄 に，本サーバシステムのクラッシュやメモリリークは せられていない．

†6 平均的にみると，約 5 割の仮想 HUB には VPN セッ 5. 6 商用 ISP の電気通信サービスへの採用 ションが接続されておらず，約 1 割の仮想 HUB には 商用版 PacketiX VPN Server は，複数の商用 In- VPN セッションが 1 本接続されており，約 2 割の仮想 HUB には VPN セッションが 2 本接続されており，約 ternet Service Provider (ISP) において，顧客向け 1 割の仮想 HUB には VPN セッションが 3 本接続さ VPN 接続サービスを提供する電気通信サービスの れており，残りの約 1 割の仮想 HUB には VPN セッ † VPN サーバとして採用されている 10．一部のサー ションが 4 本から 50 本程度まで接続されている． †7 VPN セッションが 1 本だけ常時接続されている仮想 ビスでは，顧客からの申込みや解約，VPN 内におけ HUB が約 1 割ある．これは，ユーザ拠点へのリモー トアクセス VPN サーバとして利用するために，ユー ザ拠点側で常時稼働している VPN サーバからの VPN †8 http://www.softether.jp/1-product/11-vpn/ セッションが常時接続されているものである．そして， †9 http://openblocks.plathome.co.jp/productsebpacke モバイル環境等からユーザが必要に応じて同一の仮想 tix, http://www.bias.jp/product/packetix\ on\ bias/ HUB に VPN 接続している間のみ，セッション数が 2 †10 http://www.interlink.or.jp/service/myip/, 以上となる． http://vpn.kozukata.co.jp/ Vol. 32 No. 4 Nov. 2015 25

る IP アドレスの割り当て等に際して PacketiX VPN 2013 年 12 月に，同事業の成果としてフリーウェアと Server に対して投入するリクエストを自動化してい して配布を開始したところ，1 件の地方自治体から， る．自動化には，4.4.3 節で述べた RPC が利用され 「SoftEther を使用すると，ファイアウォールの内側 ている．このような自動化プログラムは，ISP がサー にあるシステムにインターネット側からアクセスす ビスを構築する際に ISP 側において開発された． ることができる．このような危険なソフトウェアは， これらの商用 ISP サービスにおいては，PacketiX IPA の事業の成果として配布するべきできない．」と VPN Server 側が原因の不具合としては 1 件のみ発 いう苦情が IPA に寄せられた．我々は IPA から配布 生した．それは，アクセスリストとして N 個のエン 停止を指示され，12 月 24 日に配布を停止した．その トリが登録されている場合，大量の IP ブロードキャ 後，ダウンロードページに「SoftEther は危険なソフ ストパケットが仮想 HUB を流れる際に N 2 回分のア トウェアである」旨を記載すればダウンロードを再開 クセスリストエントリに対する走査が行われるとい して良いことになり，12 月 27 日から配布を再開した． う問題に起因していた．あるサービスでは仮想 HUB 2004 年になっても，引き続き SoftEther 1.0 を危険 に約 1,000 個のアクセスリストエントリが登録され なソフトウェアであるとして問題視するネットワーク ていたため，ブロードキャストパケットを処理するパ 管理者の声は収まらなかった．SoftEther 1.0 の危険性 † フォーマンスが低下し，スループットの低下と遅延の を指摘する雑誌記事も掲載された 11．その主たる理由 増加が生じた．この問題を解決し，ブロードキャスト は，SoftEther 1.0 の VPN 通信と，一般的な HTTPS パケットであっても N 回分のアクセスリストエント 通信とを，従来のファイアウォールで区別することが リの走査で処理が完結するようにした．この問題以外 困難である点にあった．そこで，我々は任意の Linux に PacketiX VPN Server 側の不具合が原因の問題は マシンをファイアウォールにして SoftEther 1.0 の † 発生していない． 通信を検出する SoftEther Alert 12および SoftEther † 1.0 の通信を自動遮断する SoftEther Block 13を制作 6 制作および普及の努力の過程 し，無償で配布した．当該検出アルゴリズムの実装で 6. 1 SoftEther 1.0 は，SoftEther 1.0 の開発者である我々自身が苦労を SoftEther 1.0 は，我々が 2003 年に開発し，2013 した．暗号化されている HTTPS 通信の内容を検査 年 12 月に公開した最初の VPN ソフトウェアである． することができないため，HTTPS コネクションを往 SoftEther 1.0 の特徴は，VPN 通信の伝送に，従来 復するパケットの長さ情報の特徴を用いて検出を行っ † の L2TP/IPsec や PPTP ではなく，HTTPS (HTTP た 14． over SSL) を用いている点にある． 当時，筑波大学の学内無線 LAN システムは HTTP 6. 2 PacketiX VPN 2.0 および HTTPS プロトコルしか通信を許可してい SoftEther 1.0 はファイアウォールが存在する環境 なかった．そのため，教室に持ち込んだノート PC であっても簡単に利用でき柔軟な VPN を構築でき から自宅の Windows コンピュータに Remote Desk- るという評判が高まったため，2004 年には，ソフト top Protocol (RDP) によって接続して操作をしたり， †11 「ファイアウォールを無効化してやりたい放題!!」, P2P アプリケーションを利用したりすることができ アスキー PC Explorer 誌 2004 年 3 月号 p. 40 他． なかった．そこで，HTTP および HTTPS 以外のプ †12 http://www2.softether.jp/jp/vpn2/old/alert/ † ロトコルの通信を禁止しているファイアウォールを通 13 http://www2.softether.jp/jp/vpn2/old/block/ †14 TCP コネクションごとにステートを管理し，何個か 過することができる VPN ソフトウェアを制作するこ の往復パケットのパケット長のパターンで検出を行っ とを思い付いた． た．パケットロスが発生せず，また TCP コネクショ ン・トラッキングのステートメモリが不足しない限り は独立行政法人情報処理推進機構 SoftEther 1.0 は，検出精度は 100%であったが，誤検出の可能性も (IPA) の未踏ソフトウェア創造事業に採択された． あった. 26 コンピュータソフトウェア

イーサ株式会社を起業し，ある企業と商用化のための 欲が発生しなかった可能性が高い．従って，当初経 ライセンス契約を締結した．しかし，当該ライセンス 済的余裕がなく，安価な「B フレッツ」の利用しか選 契約について，締結した後に，ライセンス料に関する 択肢がなかったことは，PacketiX VPN 3.0 において 問題が発生した．さらに，「SoftEther」という商標権 IPv6 対応を行う良いきっかけとなった． の一部は，当該企業が有する状態となっているという 問題も生じた． 6. 4 VPN Gate 我々はこれらの問題を解決するため，SoftEther 1.0 我々は PacketiX VPN 3.0 の製品版からいくつかの のコードを再利用せずに，新たな VPN ソフトウェア 企業向け機能を削除したフリーウェアを制作し，Uni- を制作することにした．商標の問題を避けるために， versity of Tsukuba VPN (UT-VPN) として 2010 年 † PacketiX VPN 2.0 という名称で 2005 年 12 月に販 5 月に配布を開始した 15．UT-VPN は Great Fire- 売した．もともと，SoftEther 1.0 は新たな VPN プ wall がある中国の人々によって頻繁にダウンロード ロトコルを追加したり，マルチテナント仮想ホスティ され，利用されるようになった．しかしながら，中 ング機能を搭載したりするための拡張性に乏しい設 国政府は中国国内からの 2012 年 7 月に UT-VPN の 計となっていた．結果として，このようなビジネス上 Web サイトへのアクセスを Great Firewall で遮断す の出来事は，一から PacketiX VPN 2.0 を設計・実装 るようになった．我々はこの件について関係部局に抗 する良いきっかけとなった． 議をしたが，適切な回答を得られず，通信遮断は継続 されたままとなった． 6. 3 PacketiX VPN 3.0 そこで，我々はこのような検閲を困難にするための ソフトイーサ社は 2006 年から 2008 年の間に茨城 システムを開発したいと考え，組織化されたボラン 県つくば市内に合計 4 個の拠点を設置した．これら ティアによる VPN 中継システムである VPN Gate の拠点間は当初 PacketiX VPN 2.0 を用いた拠点間 を設計した．VPN Gate を PC だけではなくスマー VPN によって接続されていた．VPN はインターネッ トフォンやタブレット端末を含むできるだけ多くの ト上に構築されていた．しかし，同一市内にある複数 種類のデバイスから利用可能にするためには，VPN の拠点同士で通信をする場合でも，ISP のルータがあ Gate の中継サーバプログラムは SEVP だけではなく る東京を折り返して通信が行われるため，10ms から L2TP，OpenVPN，SSTP 等の多くの種類の VPN 20ms 程度の遅延が生じていた． プロトコルをサポートする必要がある．VPN Gate ISP を経由せずに，NTT が提供する FTTH サービ の中継サーバは，ボランティアの数を増やすため，イ ス「B フレッツ」の網内折り返し通信を使用すること ンストールが容易なユーザプロセスとして動作する 1 により，通信はつくば市内を折り返すことができ，遅 つのプログラムである必要がある．これを実現する 延は約 3ms 程度に減少することが分かった．しかし， ために，本研究における複数 VPN プロトコル対応モ 網内折り返し通信においては IPv6 のみがサポートさ ジュールの制作を行った． れていた．そこで，もともと IPv4 上でのみ VPN を 仮に中国政府による UT-VPN の Web サイトの遮 構築できていた PacketiX VPN 2.0 を改良し，IPv6 断が実施されなかったか，または実施されても抗議後 上でも構築できるようにした．その他の機能拡張も実 に遮断が解除されたとしたら，我々には複数 VPN プ 施し，PacketiX VPN 3.0 として発売した． ロトコル対応モジュールの制作のための意欲が発生し 2009 年になると，ソフトイーサ社は経済的余裕が なかった可能性が高い．従って，このような中国政府 でき，つくば市内の拠点間を高速かつ遅延 1ms 以内 による遮断は，SoftEther VPN Server において複数 の広域 Ethernet で接続することができるようになっ VPN プロトコル対応を行う良いきっかけとなった． た．仮に 2006 年の時点から広域 Ethernet が利用で きる状態であれば，VPN の遅延の問題を解決する意 †15 http://utvpn.tsukuba.ac.jp/ Vol. 32 No. 4 Nov. 2015 27

VPN Gate は 2014 年 9 月時点で世界中から毎日 けではなく，良いソフトウェアが制作され多くのユー 40 万ユニークユーザに利用されている．VPN Gate ザの役に立つことにもつながる．これは単に愉快であ を利用するユーザの多くは，SoftEther VPN Client るだけではなく，ソフトウェアの発展にも貢献できて を拡張した VPN Gate Client を利用している．これ 大変良い． らのユーザのうち，当初は VPN Gate を用いて VPN 通信を行いて VPN の概念を理解し，しばらくして自 7 関連研究 分専用の VPN サーバ構築してみたいという意欲が生 ルータやその他のネットワークデバイスを構築する じた人々は，VPN Gate Client と類似の操作性を持 ためのソフトウェアアーキテクチャとして，Click [23] つ SoftEther VPN を使ってみようと考えるようにな がある．Click においては，開発者は C++言語を用 ると思われる．このようなユーザが SoftEther VPN いて element と呼ばれるモジュールを記述すること Server のダウンロードを行うことで，SoftEther VPN ができ，モジュール間を，ドメイン固有言語を用いて Server のユーザ数の 5.3 節のような増加に貢献して 結合することができる．多くの開発者が Click を研 いると考えられる． 究に利用している [1] [19] [20]．しかしながら，VPN サーバを実装する場合において Click の手法が有効で 6. 5 本ソフトウェアの開発意欲の発生原因 あるかどうかは未知である． 上記で述べた経緯のように，我々が本ソフトウェア 多くの VPN サーバは，オープンソースのフリー における重要な機能を制作しようとする意欲は，我々 ソフトウェアとしてリリースされている [10] [14]． 自身が困った状態になったときに，これを解決する手 OpenVPN は有名なオープンソース VPN ソフトウェ 段として自動的に生ずることが多い．たとえば，ファ アである [6] [25]．OpenVPN は独自の OpenVPN L3 イアウォールが存在していることに困り，これを解 および L2 プロトコルを用いて通信を行うため，独 決するために制作した SoftEther 1.0 は，同様に困っ 自の VPN サーバ及びクライアントを必要とする． ていたユーザ間に普及した．また，中国政府によっ SoftEther VPN Server には OpenVPN やその他の て我々のサーバへの通信が遮断されたことに不満足 オープンソースのフリーソフトウェアの VPN サーバ であった我々が制作した VPN Gate は，中国国内を と比較していくつかの優位性がある．最初に，Soft- はじめとして世界中から広く利用されるようになっ Ether VPN Server は OpenVPN L3 および L2 だけ た．そして，VPN Gate の制作の途中で実装した複 ではなく，L2TP，SSTP，L2TPv3，EtherIP および 数 VPN プロトコルのサポートのためのモジュール SEVPN に対応している．したがって，ユーザは他の は，VPN Gate だけではなく SoftEther VPN Server VPN サーバを SoftEther VPN Server に置換えるこ にも搭載され，SoftEther VPN Server の利用用途の とができる．次に，SoftEther VPN Server はマルチ 拡大に貢献した． テナント仮想ホスティング機能を提供している． 当初，SoftEther VPN Server の開発のために必要 SoftEther VPN Server は，独自のネイティブ VPN な知識が我々に不足している点も多々あった．このよ プロトコルである SEVP に対応している．SEVP は うな場合は，必要な知識やノウハウを勉強し習得する HTTP/SSL を用いて MAC フレームをカプセル化す 必要がある．そのためには単なるプログラミングと比 る．SEVP の最初のバージョンは 2003 年に実装し 較してより大きな意欲が必要である．必要な意欲を生 公開した SoftEther 1.0 に搭載されている [24]．Mi- じさせるためには，困っている問題が目前にあるとい crosoft が SSTP において HTTP/SSL を初めて採用 う状態が，結果的に非常に役立った． したのは 2006 年である．SEVP はさらにロードバラ 従って，何らかの問題が生じた場合ときに，できる ンシングおよびフォールトトレランスのためのリダイ 限りソフトウェアを制作する方法によってその問題を レクションをサポートしている． 解決しようとする考え方は，その問題が解決できるだ 中央サーバを必要としない P2P 型の VPN ソフト 28 コンピュータソフトウェア

ウェアがある [3] [28]．SoftEther VPN Server は中央 おける OS における ARP 処理および NIC における サーバを必要とするが，中央サーバ同士で VPN 接続 MAC フレーム送受信処理に相当する機能を有する． を行うことも可能である．P2P 型の VPN ソフトウェ 我々の実験結果は，本研究の解決策による複数 VPN アと異なり，SoftEther VPN Server は 3.2 節で述べ プロトコルのサポートの際のオーバーヘッドが最小 たような強力なユーザ認証機能を提供する． であることを示している．単一の VPN プロトコルを 処理する場合においては，SoftEther VPN Server の 8 まとめ パフォーマンスは Microsoft Windows の RRAS 機 本論文においては，我々は既存の VPN サーバと 能と同等程度または低速な結果となった．一方で，2 比較して 2 つの特徴を持つ SoftEther VPN Server 個の VPN クライアントが異なる VPN プロトコルを に関する設計と実装について述べた．1 つ目の特徴 用いて通信を行う場合においては，SoftEther VPN は，SoftEther VPN Server は単一の VPN サーバイ Server を単体で用いた場合が，従来の VPN サーバ ンスタンスで複数の VPN プロトコルをサポートす プログラムを複数用いた場合と比較して高速な結果 る点にある．サポートされる VPN プロトコルは， となった． L2TP over IPsec，SSTP，OpenVPN L3 および L2， 我々は SoftEther VPN Server のバイナリパッケー EtherIP over IPsec，L2TPv3 over IPsec およびネ ジを 2013 年 3 月にフリーウェアとして公開した． イティブの SoftEther VPN Protocol (SEVP) であ また，2014 年 1 月にソースコードを GNU General る．これらのプロトコルは，PC，スマートフォンお Public License (GPL) Version 2 として公開した． よび VPN ルータを含む幅広い VPN クライアントを SoftEther VPN Server は，2014 年 9 月までの間に， カバーする．複数の VPN プロトコルを単一の VPN 世界中で 242,000 回インストールされた実績を有する． サーバによってサポートすることにより，管理者は SoftEther VPN Server は，商用ソフトウェアである VPN サーバの設定や管理が容易に行えるようになる． PacketiX VPN Server 3.0 の後継版である．PacketiX 2 つ目の特徴は，ユーザ管理およびネットワークの仮 VPN Server の新たなバージョン 4.0 は，SoftEther 想化ができることにある．これはマルチテナント仮 VPN Server で実装したマルチプロトコルのサポー 想ホスティングを実現するために重要である．ユー ト機能のコードが搭載されている．PacketiX VPN ザ管理の仮想化としては，各テナントは VPN 接続を Server は 5,500 社に導入されている． 受付けるための独立したユーザ認証領域を持つ機能 今後は，SoftEther VPN Server の他のプラット がある．ネットワークの仮想化としては，複数の仮想 フォームへの移植およびさらなる最適化を目指す．ま HUB を 1 つの VPN サーバインスタンスに定義でき， た，SoftEther VPN Server の持つロードバランシン それぞれの仮想 HUB 間の通信を分離することができ グおよびフォールトトレランス機能の性能について る機能がある． 評価を行う．また，SEVP のネイティブ VPN クラ SoftEther VPN Server の実装における鍵となる特 イアントである SoftEther VPN Client を iOS およ 徴は，レイヤ 2 およびレイヤ 3 プロトコルの両方を び Android に移植することを目指す．さらに，多数 経由して接続された VPN コネクション間のメッセー の拠点間を SoftEther VPN Server で接続する場合 ジを相互に交換するためのソフトウェアベースのレイ における遅延をさらに小さくし，単一障害点を無く ヤ 2 スイッチにある．この仕組みにより，管理者は集 すために，通常 Multiple Protocol Label Switching 中化された操作によりアクセス制御やログの管理を (MPLS) 上で利用されている Virtual Private LAN 行うことができる．VPN クライアントがレイヤ 3 パ Service (VPLS) と似た Ethernet over IP のフルメッ ケットを送信したときは，L2 アダプタと呼ばれるモ シュネットワークを構築する機能の実現を目指す． ジュールがレイヤ 3 パケットをレイヤ 2 フレームに変 換する．L2 アダプタは，一般的な OS および PC に 謝辞 本論文の SoftEther VPN Server の設計・実 Vol. 32 No. 4 Nov. 2015 29

装にあたって貴重なアドバイスをいただいた板野肯三 2004. [17] Kivinen, T., Huttunen, A., Swander, B. and 先生 (筑波大学名誉教授)，加藤和彦先生 (筑波大学)， Volpe, V.: Negotiation of NAT-Traversal in the 高木浩光先生 (産業技術総合研究所) および SoftEther IKE, RFC 3947, 2005. [18] Lau, J., Townsley, M. and Goyret, I. (eds.): VPN Server のユーザの皆様に感謝します． Layer Two Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, 2005. 参 考 文 献 [19] Louati, W., Jouaber, B. and Zeghlache, D.: Con- figurable Softwarebased Edge Router Architecture, [ 1 ] Chen, B. and Morris, R.: Flexible Control Computer Communications,Vol. 28, No. 14(2005), of Parallelism in a Multiprocessor PC Router, pp. 1692–1699. in USENIX Annual Technical Conference, 2001, [20] Mandke, K., Choi, S.-H., Kim, G., Grant, R., pp. 333–346. Daniels, R.C., Kim, W., Heath, R.W. Jr. and Net- [ 2 ] Cheshire, S. and Krochmal, M.: Multicast DNS, tles, M.S.: Early results on Hydra: A Flexible RFC 6762, 2013. MAC/PHY Multihop Testbed, in Vehicular Tech- [ 3 ] Deri, L. and Andrews, R.: N2N: A Layer Two nology Conference, 2007, pp. 1896–1900. Peer-to-Peer VPN, Resilient Networks and Services, [21] Microsoft: Secure Socket Tunneling Pro- Springer Lecture Notes in Computer Science 5127, tocol (SSTP), http://msdn.microsoft.com/en-us/ pp. 53–64, 2008. library/cc247338.aspx, 2013. [ 4 ] Dingledine, R. Mathewson, N. and Syverson, P.: [22] Microsoft: Unencapsulated MS-CHAP v2 Au- Tor: the Second-Generation Onion Router, in the thentication Could Allow Information Disclosure, 13th conference on USENIX Security Symposium, https://technet.microsoft.com/library/security/ 2004, pp. 303–320. 2743314.aspx, 2012. [ 5 ] Eastlake, 3rd D. E.: Cryptographic Algorithm [23] Morris, R., Kohler, E., Jannotti, J. and Implementation Requirements for Encapsulating Kaashoek, F.: The Click Modular Router, in the Security Payload (ESP) and Authentication Header seventeenth ACM symposium on Operating systems (AH), RFC 4305, 2005. principles, 1999, pp. 217–231. [ 6 ] Feilner, M.: OpenVPN: Building and Integrat- [24] 登 大遊: SoftEther の内部構造, 情報処理, Vol. 45, ing Virtual Private Networks, Packt Publishing, No. 10(2004), pp. 1057–1062. 2006. [25] Nobori D. and Shinjo, Y.: VPN Gate: A [ 7 ] Gates, M. Warshavsky, A., Dugan, J. et al.: Volunteer-Organized Public VPN Relay System iperf - Perform Network Throughput Tests, http: with Blocking Resistance for Bypassing Government //iperf.sourceforge.net/, 2010. Censorship Firewalls, in 11th USENIX NSDI, 2014, [ 8 ] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., pp. 229–241. Little, W. and Zorn, G. : Point-to-Point Tunneling [26] OpenVPN Community: OpenVPN Community Protocol (PPTP), RFC 2637, 1999. Software. http://openvpn.net/index.php/open- [ 9 ] Housley, R. and Hollenbeck, S.: EtherIP: Tun- source/overview.html. neling Ethernet Frames in IP Datagrams, RFC [27] Townsley, W., Valencia, A., Rubens, A., Pall, 3378, 2002. G., Zorn, G. and Palter, B.: Layer Two Tunneling [10] Howarth, P., Cameron, J. and Gillham, M.: Protocol ”L2TP” , RFC 2661, 1999. Poptop - An Open Source Implementation of [28] Wolinsky, D. I., Lee, K., Boykin, P. O. and a PPTP Server, http://sourceforge.net/projects/ Figueiredo, R.: On the Design of Autonomic, De- poptop/. centralized VPNs, in 6th Intrenational Conference [11] Huang, G., Beaulieu, S. and Rochefort, D.: A on Collabrative Computing: Networking, Applica- Traffic-Based Method of Detecting Dead Internet tions and Worksharing (CollaborateCom) , pp. 1– Key Exchange (IKE) Peers, RFC 3706, 2004. 10, 2010. [12] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and Stenberg, M. : UDP Encapsulation of IPsec ESP Packets, RFC 3948, 2005. [13] IEEE 802.1Q: IEEE Standards for Local and 登 大 遊 Metropolitan Area Networks: Virtual Bridged Lo- cal Area Networks, 2003. 2007 年筑波大学第三学群情報学類卒． [14] Katalix Systems Ltd: The manual page of 2013 年同大学大学院システム情報工 openl2tpd. [15] Kent, S. : IP Encapsulating Security Payload 学研究科コンピュータサイエンス専 (ESP), RFC 4303, 2005. 攻博士前期課程修了．現在，同専攻 [16] Kivinen, T., Huttunen, A., Swander, B. and Volpe, V.: Negotiation of NAT-Traversal in the 博士後期課程在籍．2004 年ソフトイーサ株式会社を IKE, in Internet Drafts draft-ietf-ipsec-natt-ike-08, 30 コンピュータソフトウェア

設立．修士 (工学)．情報処理学会会員． 佐 藤 聡 1996 年筑波大学大学院工学研究科単 新 城 靖 位取得退学．同年広島市立大学情報科 1988 年筑波大学第三学群情報学類卒 学部助手．2001 年筑波大学 電子・情 業．1993 年同大学大学院工学研究科 報工学系講師．2013 年筑波大学 シス 電子・情報工学専攻博士課程修了．同 テム情報系准教授．現在，同大学学術情報メディアセン 年琉球大学工学部情報工学科助手． ター勤務．博士 (工学)．キャンパスネットワークの企 1995 年筑波大学電子・情報工学系講師，2003 年同助 画管理運用，ネットワークデータベース，言語処理等の 教授，2004 年同大学院システム情報工学研究科助教 研究に従事．情報処理学会，ACM-SIGMOD-JAPN 授．2007 年同准教授．オペレーティング・システム， 各会員． 分散システム，仮想システム，並行システム，情報 セキュリティの研究に従事．博士 (工学)．日本ソフト ウェア科学会，情報処理学会，ACM，IEEE 各会員．