VPN Azure で通信を中継

上記の「NAT トラバーサル」と「ダイナミック DNS」を組み合わせれば、ほとんどのファイアウォール・NAT を「外から内に」通過することができます。ソフトイーサで調査した結果としては、日本にある約 95.7% のファイアウォール・NAT で PacketiX VPN 4.0 の NAT トラバーサルを通過します。いっぽう、4.3% のファイアウォール・NAT では NAT トラバーサルがうまく機能しないようです。


この残された 4.3% のファイアウォール・NAT を利用しているユーザーは、本来であれば NAT トラバーサル機能を利用するためにはファイアウォール・NAT をリプレースする必要があります。しかし、ファイアウォール・NAT を交換することはとても手間です。そこで、そのようなうまく通信ができないファイアウォールでも何とか「外から内に」VPN を確立することができるようにするため、ソフトイーサでは「VPN Azure クラウドサービス」を 2012/11/26 に開始しました。



上図で一目瞭然ですが、「VPN Azure クラウドサービス」は、VPN 通信の内容に関与せずに単に VPN セッションを折り返すだけのサーバーです。VPN 専用のプロキシサーバーのようなものであると考えていただければ良いと思います。
「NAT トラバーサル」が通らない全体の 4.3% のファイアウォールであっても、「社内」から「社外」への HTTPS (Port 443) は通る場合がほとんどです。そこで、VPN Azure を利用するように VPN Server で設定すると、VPN Server は VPN Azure との間でコネクションを確立します。コネクションはそれ以降半永久的に確立され続けます。SkypeWindows Live Messenger を起動すると、ファイアウォールの内側から外側に対してずっとコネクションが確立され続けますが、それと同様です。
そして、VPN Azure に対して VPN クライアントが接続要求を出したときに、その接続要求はファイアウォールの内側にある VPN Server に転送されます。VPN Server は接続要求に対して再度ファイアウォールの「内側から外側に向かって」応答し、VPN セッションが確立されます。


VPN Azure を経由して VPN Client が VPN Server に接続する際のコントロール通信は、VPN Azure を物理的に経由します。一方、一端 VPN セッションの確立が成功した後は、データ通信 (VPN 通信の対象となるパケットのことです) は VPN Azure を経由せず、Client と Server 間で直接通信が行われます。この際には UDP が使用されます。しかし何らかの理由で UDP が使用できない場合は、VPN Azure を経由した通信が自動的に行われます。


VPN Azure はまた、Microsoft SSTP VPN サーバーの受け側としての機能も持っています。Windows Vista / 7 / 8 / RT に搭載されている Microsoft SSTP クライアントを用いて、VPN Azure を経由して社内の VPN サーバーに VPN 接続することができます。この場合はすべての通信が VPN Azure 経由となるのでスループットが落ちますが、メリットとして、クライアントパソコン側には PacketiX VPN Client をインストールする必要がないという点があります。つまり Windows に標準付属の VPN を利用できますので、インストールがとても簡単です。


詳しくは「VPN Azure クラウドサービス」の Web サイトをご覧ください。


VPN Azure クラウド」はまだ研究開発途中のバージョンであり、学術実験プロジェクトとして筑波大学の内部に設置されています。研究が完了し、安定して動作するようになったときは、世界中のデータセンタに分散して配置される予定です。こうすれば、VPN サーバーやクライアントに最も近いデータセンターが中継ポイントとして自動的に選択されるという仕組みを実現できます。