VPNを使う前に知っておくべきこと

VPN入門シリーズの最終回では、利用に際しての技術的な問題と法的な問題を取り上げます。こうした問題点に留意しつつ、安全な接続を心がけましょう。

vpn-part-3-featured

「VPN入門」シリーズの最後は、いつもの技術ネタから離れた話題を取り上げます。VPNを使う際に直接関係する技術的な問題と法的な問題を解説し、最後は実践的なアドバイスで締めたいと思います。

技術的な課題

本シリーズの熱心な読者であれば、ご記憶かもしれません。前回の記事では、どのVPNを導入するにしても、正しく実装、セットアップ、使用するべきことを強調しました。最も信頼性の高いバージョンのVPNプロトコルであっても、間違った使い方をすれば何の意味もありません。

前回もお伝えしましたが、各種VPNソリューションには共通点があります。それは、オープンソースで実装されており、脆弱性の有無を簡単に検証できることです。しかし、実際はコード内の脆弱性のほかにも、さまざまな問題や特性があります。

最も顕著な問題は、VPNが時々切断され、その結果、トラフィックが「突然」公共ネットワーク上を流れてしまうことです。たとえば、公共Wi-Fiネットワークなどの利用可能なモバイルネットワークに接続しているときに、この問題が起きるかもしれません。最悪なのは、切断されたことがユーザーに知らされず、VPN接続が自動的に復元されない場合です。

Windows 7以降、MicrosoftはVPN再接続機能を実装しました。別のOSを利用している場合は、個別にルーティング設定をカスタマイズするか、「キルスイッチ」と呼ばれる機能を使う必要があります。キルスイッチは、VPN接続の状態を監視しています。VPNが切断されると、トラフィックをブロックし、実行中のアプリケーションをすべて停止し、VPN接続の復旧を試みます。市販のVPNクライアントの一部でも、同じような機能が提供されています。

2つめのVPNの問題は、あまり知られておらず、頻度も低いのですが、IPv6に関連しています。IPv6はいまだに実環境でほとんど使われていませんが、主要なOSはこのプロトコルを既定で有効にしています。IPv4を使用しているVPNが多いのですが。

そこで何が起きるかというと、公共ネットワークでIPv6がサポートされている場合、クライアントは同じバージョンのプロトコルを使うリソースに接続した方がよいため、既定のIPv6で公開ネットワークにトラフィックを流してしまいます。一番簡単な対策は、システムレベルでIPv6のサポートを無効に設定することです。

もちろん、すべてのトラフィックをVPN経由で流すように設定することもできますが、それにはサーバー側での対応とクライアント側での特殊な設定が必要です。2015年に実施された調査の結果（英語資料）、VPNプロバイダーはやんわりと説得された格好となり、クライアント向けの適切な対策を模索し始めています。

この調査では、3つめの問題点であるDNS漏洩についても指摘されています。最善のシナリオでは、ユーザーがVPNに接続すると、すべてのDNSリクエストはVPNネットワーク外に出ず、対応するDNSサーバーで処理されなければなりません。さもなければ、Google Public DNSやOpenDNSなどの信頼できる既知のサーバーをネットワーク環境内に設定する必要があります。もしくは、DNSCryptのようなサービス付きのVPNを使うこともできます。この場合、DNSリクエスト／レスポンスの暗号化と信頼性の検証が実行されますし、その他の点でもかなり有効な対策です。

実際は、こうした推奨事項に従っていることはほとんどなく、ユーザーは公共ネットワークで提供されているDNSサーバーを利用しています。当然、こうしたサーバーから取得したレスポンスは正規のものでないどころか、偽物の可能性が高く、ファーミング詐欺師にとって格好のチャンスとなります。DNS漏洩の二次被害は、プライバシーの侵害です。部外者にDNSサーバーのアドレスがばれてしまうと、ISP名と、おおむね正確なユーザーの居場所が突き止められてしまいます（英語）。

想像以上に深刻な状況にあるのが、Windowsユーザーです（英語記事）。Windows 7は既知のすべてのDNSサーバーに1つずつリクエストを送り、レスポンスを待ちます。Windows 8/8.1に至っては、処理を早めるために、既知の全接続に関わる既知のDNSサーバーすべてに同時にリクエストを送信します。期待するサーバーが1分以内にレスポンスを返さなかった場合は、別のサーバーのレスポンスが採用されます。ところがVPNの場合、DNSレスポンスを取得するまでに、もっと長くかかることがあります。この機能の良いところは、手動でオフに設定できること。悪いところは、システムの設定に関して、煩雑な作業が発生することです。

Windows 10の場合、事態はさらに悪化します。このOSでもDNSリクエストをあらゆるDNSサーバーへ発信し、一番先に返されたレスポンスを利用します。ただ、この仕組みに良いところは1つもありません。この超便利機能は、システムレベルで無効化できないのです。

さらに、WebRTCには深刻な脆弱性があります。この技術はブラウザーで有効になっており、そもそも2つのネットワークノード間を直接接続するために設計されたものですが、現在は主に音声通話やビデオ通話に使われています。WebRTCによる情報流出は、大いにあり得る話です。というのも、WebRTCは利用可能なすべてのネットワーク接続に対してリクエストを同時に送信し、最初にレスポンスを返したところを利用するためです。

設定で制御できないという問題は、すべてのソフトウェアとは言わないまでも、JavaやAdobe Flashなどのプラグインにも存在します。このような問題は利用者のプライバシーにとって深刻な脅威となっており、公共ネットワークで利用者を守る方法が見直されています。

法的な課題

VPNの問題として真っ先に挙げられるのは、国によって法規制が異なる点です。ある国のVPNクライアントが、別の国（友好国の可能性が高いのですが）に設置されたVPNサーバーに接続する可能性があります。あるいは、トラフィックが第三国を経由して転送される可能性もあります。ユーザーが法律に違反していなくても、転送時にデータを記録、分析されることも考えられます。

一般的に、暗号化されたトラフィックを復号できるかどうかは、たとえ数年後であってもわかりません。そもそも、VPNを利用すること自体、法執行機関から無用な関心を向けられるかもしれません（誰かがVPN経由で何かを隠していたら、どうなるでしょうか）。

VPNを利用することはまったく問題ありませんが、利用する上で技術的な限界もあります。詳しくは、以前の記事で紹介した例や、PRISMで公開されている情報を参照してください。

もっとも、法的な課題は、VPNそのものより、強力な暗号化を利用することに端を発していることが往々にしてあります。どの国も当然ながら自国の情報を守り、他人のデータを取得したいと考えています。だからこそ、暗号化が厳しく規制されるわけです。

世界のITリーダーたる米国がかなり微妙な状況にあるのは、間違いありません。暗号化の新しい規格は最初にNIST（国立標準技術研究所）が承認することになっています。しかし、これらの規格は強度がさまざまで、米国内版では強靭性の高い暗号化が採用されているのに対し、輸出版の暗号化は強度が下げられています。厄介なことに、政府機関からの受注を目指すハードウェアやソフトウェアの企業は、こうした規制に準拠しなければなりません。

広く普及しているOSや暗号化コンポーネント（VPNモジュール含む）がどの国で作られているのか、言うまでもないでしょう。この問題は、バックドアの可能性よりもずっとたちが悪いのです。業界標準となるべきネットワーキング技術は、初めから脆弱性を抱えている恐れがあります。

事実、2013年に新しい暗号化規格の基盤として脆弱なバージョンの疑似乱数生成器をNSAが使用できるようにしたとして、NISTは糾弾されています（英語記事）。こうした環境であれば、理論的には「保護された」情報の復号作業は楽になります。

この疑惑は、新しい規格が公開されてから数か月後に浮上しました（英語記事）。当時、公開された規格と勧告に関する記述が意図的に複雑な内容になっているとして、策定者は非難されています（英語記事）。ドラフトの内容はとても曖昧で、暗号の専門家ですら問題をすぐに見抜くことができませんでした。ここで強調したいのは、暗黙の強靭性やセキュリティの問題だけでなく、実際の実装も同等に重要視するべきということです。

まとめ

この記事のまとめとして、役立に立つ情報をご紹介したいと思います。一般に普及しているVPNプロバイダーの一覧表です（英語）。緑色のセルが多いほど、そのプロバイダーの信頼性が高いことを示しています。VPNを使いたいけれど、技術的な課題や法的な課題をいろいろ調べたくない方には、この一覧表が参考になるかと思います。何よりも重要なことは、VPNプロバイダーの指示にきちんと従うこと、そして「転ばぬ先の杖」という教訓を心に留めておくことです。

ヒント
新着記事をメールでお知らせします