SoftEther VPN はセキュアな情報通信システムが必要とされる企業内ネットワークに必須の VPN ソフトウェアです。

『SoftEther VPN Bridge 2.0』をシリーズに追加

SoftEther VPN 2.0 シリーズに、『SoftEther VPN Bridge 2.0』を追加いたしました。

SoftEther VPN Bridge 2.0 は、SoftEther VPN Server 2.0 に搭載されている機能のうち、以下の機能のみを使用可能にしたバージョンで、たとえばメイン拠点に VPN Server 2.0 が設置されている環境で遠隔地の LAN をメイン拠点にブリッジ接続する場合などに、遠隔地 (サテライト) において VPN Server 2.0 ではなく VPN Bridge 2.0 をインストールするだけで、簡単に VPN Server 2.0 にカスケード接続することができるようになります。

• 内部に単一の仮想 HUB ("BRIDGE" という名前) のみを作成可能です。
• "BRIDGE" 仮想 HUB の設定で、外部にある任意のコンピュータ上の VPN Server 2.0 に常時カスケード接続することができます。
• "BRIDGE" 仮想 HUB と、コンピュータに装着されている既存の LAN カードとの間で Layer-2 ブリッジ接続を行うことができます。
• SoftEther VPN Server Manager 2.0 (リモート管理ツール) で VPN Bridge 2.0 を管理することができます。

従来、2 つ以上の拠点をブリッジ接続していた場合で、すべての拠点に VPN Server 2.0 を使用していた場合は、今後は 1 つの拠点のみ VPN Server 2.0 を使用し、他の拠点 (サテライト) については VPN Bridge 2.0 を使用することにより、管理の簡略化・簡潔化を行うことができます。

なお、VPN Server 2.0 と VPN Bridge 2.0 は管理用ポートとして同一のポート番号を使用するため、共存することは推奨されません。

クラスタリング環境で集中統合管理が可能に

従来のバージョンの SoftEther VPN Server 2.0 では、複数の VPN Server 2.0 をクラスタリング機能によって 1 つのクラスタとして動作させた場合において、複数の VPN Server にまたがった仮想 HUB を管理する場合、セッション管理のために複数の VPN Server へ同時に管理セッションを接続して管理する必要がある作業がいくつかありました。

Beta 3.2 以降の SoftEther VPN Server 2.0 では、複数の VPN Server で構成されたクラスタ内の仮想 HUB を管理する場合において、クラスタ メンバ数が多い場合でも、すべての管理作業をクラスタ コントローラである VPN Server に接続して集中統合的に管理することができるようになりました。

仮想 HUB 間のカスケード接続時にクライアント証明書認証が使用可能に

これまでのバージョンの SoftEther VPN Server 2.0 の仮想 HUB 間のカスケード接続セッションを接続するためのユーザー認証の方式は、ユーザー名とパスワードによるユーザー認証のみが使用可能でしたが、Beta 3.2 以降の SoftEther VPN Server 2.0 および SoftEther VPN Bridge 2.0 から別のコンピュータで動作している SoftEther VPN Server 2.0 の仮想 HUB にカスケード接続する際のユーザー認証の方法として、「クライアント証明書認証」を使用することができるようになりました。

これにより、VPN システム管理者が適切に設定を行うことにより、パスワードを使用しないより安全な X.509 + RSA 1024bit の証明書認証が利用可能になります。

[カスケード接続] の設定画面

社外開発の信頼できないプログラムコードの除去

SoftEther VPN 2.0 の Beta 3 およびそれ以前のプログラムファイルは、メモリ効率向上およびファイルの書き換え防止のため、自己展開型の圧縮パッケージ ユーティリティによって圧縮および暗号化された EXE ファイル (実行可能ファイル) として配布されていました。

しかしながら、自己展開型の圧縮パッケージ ユーティリティはソフトイーサ社内ではなく、社外の個人事業者に外注して開発させたユーティリティを使用しており、かつ諸問題によりその外注先の作成したユーティリティが完全・確実に信頼することができない状況となったため、SoftEther VPN 2.0 の一般的な使用用途や必要とされるセキュリティ レベルの高度性をかんがみ、この自己展開型の圧縮パッケージ ユーティリティの使用をとりやめました。これによって、Beta 3 以前のプログラムファイルに適用された社外開発の信頼できないプログラムコードを完全に除去いたしました。

なお、この問題につきましては、SoftEther VPN 2.0 開発チーム内で技術的な調査をした結果、自己展開型の圧縮パッケージ ユーティリティのコード自体にセキュリティ上の欠陥は見つからず安全である可能性が高いという結果が公表されましたが、論理的には極めて低い確率で不具合または欠陥のあるコードが含まれている可能性も存在し得る為、今後の SoftEther VPN 2.0 ビルドにおいては、フリー版・製品版を含めて、原則として社外に開発を外注したプログラムを採用することは避ける方針で開発し、セキュリティ上の安全性を高いレベルで保証できる体制を整備する予定です。

ATOK16 との組み合わせによるメモリリークの解消

Beta 3 以前では、SoftEther VPN Client 2.0 を ATOK16 を動作させている Windows コンピュータ上で長時間動作させていると、「VPN サーバーへの接続に失敗しました」というエラー メッセージの画面が表示される度に、最大数百キロバイトのメモリリークが発生していました。ソフトイーサ株式会社ではこの問題は ATOK16 側のマルチスレッドに関する不具合が原因であり、SoftEther VPN Client 2.0 側のプログラムが原因ではないと認識しておりますが、Beta 3.2 では VPN Client 2.0 のバックグラウンドプロセス起動時に IME をプロセス内のみで無効にするように修正したため、ATOK16 の不具合によるメモリリークは発生しなくなりました。

複数 TCP コネクション接続時の安定性の向上

VPN セッションのクライアントとサーバーとの間で張られる論理的な 1 セッションを構成する最大 32 本の TCP/IP コネクションの管理アルゴリズムを改良し、安定性および性能を向上させました。

config ファイルの瞬時の動的なインポート / エクスポートに対応

SoftEther VPN Server 2.0 または SoftEther VPN Bridge 2.0 が起動中の状態でも、管理ツールを使用してリモートから設定ファイルの内容を読み出したり、書き込んだりすることが可能になりました。これにより、サーバー コンピュータ上で config ファイルを手動で書き換えたい場合に、サービス プロセスを停止してから config ファイルを編集し、その後でサービスを再開するという必要が無くなりました。

config ファイルのリモートからの読み書きと適用が可能に

仮想 HUB の管理オプションの設定が可能に

SoftEther VPN Server 2.0 では、仮想 HUB ごとの管理者パスワードを設定することにより、仮想 HUB ごとの管理を他人に委任することが可能でしたが、従来のバージョンでは仮想 HUB の管理者が、VPN Server 全体の管理者の意図しない機能を有効にしたり、大量のユーザーを定義してサーバーのリソースを消費したりすることが可能でした。

そこで、Beta 3.2 では VPN Server の管理者が仮想 HUB ごとに「管理オプション」と呼ばれる管理上の制限値を設定することができるように拡張されました。VPN Server の管理者が各仮想 HUB ごとに管理オプションを設定することによって、たとえばその仮想 HUB に登録可能なユーザー数の上限や、すべてのユーザーのそれぞれの VPN 通信ビットレートの制限値などを強制的に設定できます。また、カスケード接続や SecureNAT 機能の設定・開始・停止などの制限も強制的に適用することができるようになりました。

これにより、VPN Server 2.0 全体を管理するシステム管理者は、各仮想 HUB ごとの管理者が不必要な機能を使ったり、著しく大量のリソースを消費したりする設定を勝手に行うことを防止することができます。

VPN Server の不具合の修正

SoftEther VPN Server 2.0 Beta 3 に含まれていた下記の不具合を修正いたしました。

• SoftEther VPN Client 2.0 の接続マネージャから VPN Server 2.0 に登録されているユーザーのパスワードを変更しようとすると、エラーが発生して VPN Server 2.0 のプロセスが再起動することがある問題。
  　
• クラスタリング環境で動作中の SoftEther VPN Server 2.0 で、複数のクラスタ メンバにまたがっている仮想 HUB でスタティック モードで運用中、ローカル ブリッジ セッションが複数サーバー上で同一の名前になってしまい重複が発生してしまう問題。