まず、DirectAccessクライアントとサーバがマシン証明書によって相互を認証する。サーバはイントラネットのActive Directoryを参照してクライアントPCのグループメンバーシップ（および、NAPでPCの安全性チェックが義務付けられている場合はイントラネットのHealth Registration Authority：正常性登録機関）を確認する。すべて順調にいけばIPsec ESP（Encapsulating Security Payload：パケット暗号化ペイロード）トンネルが確立され、クライアントがサーバに接続している間は常時維持される。

　この時点で、クライアントはセキュアなトンネルを使ってイントラネットのDNSサーバとWindowsドメインコントローラーに接続できる。Name Resolution Policy Table（名前解決ポリシーテーブル）では、リモートアプリケーションによるホストネーム参照をイントラネットで解決するか、インターネットのDNSサーバで解決するかを決める。インターネットサーバに振り向けられたリモートのトラフィックはすべて、直接素通りで送られる。

　リモートのアプリケーションがイントラネットサーバにトラフィックを送ろうとする場合、DirectAccessクライアントが自動的に第2のIPsec ESPセッションを確立する。ポリシー設定によっては、これにエンド・ツー・エッジのトンネルモードIPsec、またはエンド・ツー・エンドのトランスポートモードIPsecが介在することもある。いずれの場合も、マシンの証明書およびユーザー証明（例えばドメインパスワード、スマートカードなど）に基づき認証が行われる。すべて順調にいけば、ユーザーはローカルで接続しているのと同じように、許可されたイントラネットリソースとの通信が可能になる。

　特筆すべきは、DirectAccessはIPv6を利用しているということだ。DirectAccessクライアントは常にネイティブのIPv6を通じてIPsecトンネルを確立しようとする。これに失敗した場合（家庭や公衆ネットワークでは大半がうまくいかないだろう）、クライアントは6to4やTeredoなどの技術を使ってIPv4内部でIPv6のカプセル化を試みる。それでもうまくいかなければ（ファイアウォールやプロキシを使っている場合など）、DirectAccessクライアントはMicrosoftのIP-HTTPSトンネリングプロトコルを使ってHTTPSパケット内部にIPv6を格納する手段を取る。ほとんどのネットワークやファイアウォール、プロキシでは下りのHTTP over SSLを許可しているため、これで大抵はうまくいく。ただしいずれのケースとも、全イントラネットリソース用のIPv6 DNSネームスペースとIPアドレスプレフィックス、およびDirectAccessクライアントに割り当てられた公開ルーティング可能なIPv6アドレスを含め、イントラネットがIPv6をサポートしている必要がある。

DirectAccessとVPNとの違い

　DirectAccessはIPsec ESPとMOBIKE（IKEv2 Mobility and Multihoming Protocol）を含むVPNプロトコルを利用している。エンド・ツー・エッジの保護に使った場合、DirectAccessは標準的なIPsec VPNで提供されるのと同様のセキュアなトンネルを提供する。

　DirectAccessが標準的なIPsec VPNと異なる点は、トンネル管理の自動化の程度と、ほかのMicrosoftインフラとの統合の程度だ。他社のVPNの多くは完全に自動化されたトンネルの確立を提供している（一時的な接続の中断を隠すためのアプリケーションの持続性さえも）。しかし、MicrosoftのVPNゲートウェイであるWindows Server 2008のRouting and Remote Access（RRAS）は異なる。RRASユーザーは通常、自分でVPN接続を確立して（L2TP、IPsecまたはPPTP経由で）ログインする。この基盤となる無線あるいは有線接続が途切れれば、VPNトンネルを再度確立しなければならない。DirectAccessは、エンドユーザーによるこの操作と不便さを回避している。

　もう1つの大きな違いはルーティングにある。他社のVPNソリューションの多くは、特にSSL VPNは行き先がイントラネットかインターネットかを区別してリモートクライアントのトラフィックを振り分けている。しかし、レイヤー2トンネリングプロトコル（L2TPやPPTPなど）では単純に、出て行くトラフィックをすべて（分割せずに）トンネルを介してVPNゲートウェイにルーティングし、ゲートウェイからそのトラフィックをインターネットまたはイントラネットに転送しなければならない。DirectAccessはデフォルトでIPv6のネームスペースを利用して効率性を高め、煩雑なIPsec選択やSSL URLマップの必要性をなくした。それでも、DirectAccessクライアントではWindowsファイアウォールのグループポリシーに基づき、非イントラネットのトラフィックをトンネリングすることも可能だ。

　また、DirectAccessはエンド・ツー・エッジの保護にも対応しているが、Microsoftは可能な場合（つまり行き先がIPv6 Windows Server 2008である場合）はエンド・ツー・エンドの保護を奨励している。ネットワークがIPv6に移行すれば、ローカルとリモートの境界が薄れる中で必要とされるセキュリティアーキテクチャをDirectAccessでサポートできるからだ。

DirectAccessの使い方と利用シーン

　DirectAccessは一見、大企業向けに見えるかもしれない。しかし、購入したハードウェアとソフトウェアを最大限に活用しようとしている多くの中堅企業は、Windows RRASをVPNプラットフォームとして利用している。こうした企業ではDirectAccessをRRASのアップグレードと見なすことも十分できそうだ。

　さらに、中堅企業はVPNコンセントレータは購入しても、さらに高度なSSLやモバイルVPNにはなかなか投資しない。こうしたサードパーティーVPN（例えば常時接続トンネル、ファイアウォール／プロキシトラバーサルなど）が提供しているメリットの幾つかを、DirectAccessではハードウェアを購入したりクライアントをインストールしたりすることなく実現できるとしている。

　ただし、DirectAccessは万能ではない。まず、DirectAccessクライアントはWindows 7 Enterprise／UltimateとWindows Server 2008 R2に組み込まれているが、現時点でほかの種類のリモート端末への接続提供には利用できない（RRASなどほかのVPNソリューションは並行して利用できる）。

　次に、DirectAccessサーバはWindows Server 2008 R2 PCに少なくとも2枚のネットワークインタフェースカード（NIC）をインストールしなければならない。インターネットに接続するアダプターは、2つのIPv4アドレス（例えばDMZ上など）経由で公開ルーティングできる必要がある。可用性や拡張性が心配な企業は、複数のDirectAccessサーバを導入することもできる。

　さらに、企業のイントラネットが（少なくともある程度は）IPv6に対応している必要がある。これにはWindows Server 2008（SP2またはR2）を搭載し、IPv6に接続されたドメインコントローラーとDNSサーバが含まれる。Windows Server 2008のどのバージョンを実行しているものであれ、IPv6に接続されるアプリケーションサーバには、エンド・ツー・エンドまたはエンド・ツー・エッジモデルで接続できる。ほかのイントラネットアプリケーションサーバはすべて、NAT-PT（IPv4－IPv6間のプロトコル変換）経由で接続しているIPv4サーバも含め、エンド・ツー・エッジ接続限定となる。

　最後に、DirectAccessがWindowsプラットフォーム中心のイントラネットを想定しているのは明らかだ。例えば、DirectAccessはActive Directoryに参加しておらずマシンの証明書が発行されていないリモート端末の接続には利用できない。Windows認証インフラを採用してきた企業なら、DirectAccessでアクセスがさらに容易になったと感じるだろう。実際、DirectAccessはリモートユーザーがNAP、Windows 7 Federated Search、Windows 7 Folder Redirectionといった新しいWindowsネットワーク機能を活用する手助けをしてくれる。

本稿筆者のリサ・ファイファー氏はCore Competenceの副社長。25年以上にわたってネットワーク、セキュリティ、管理製品の設計、導入、評価に携わり、大小の企業を対象に、セキュリティの必要性、製品評価、新興技術の利用、ベストプラクティスについて助言してきた。