Windows 7 と Windows Server 2008 R2

BranchCache と DirectAccess: ブランチ オフィスのエクスペリエンスを向上する

Gary Olsen

製品のリリースにより、一般ユーザーにも、ようやく Windows Server 2008 R2 と Windows 7 がお目見えしましたが、2009 年 5 月からリリース候補 (RC) 版を使用したり、8 月から製品 (RTM) 版を使用していたユーザーもいます。どちらのユーザーも、溢れんばかりの売り込み広告を見たことがあるでしょう。たとえば、私と同じように、リリース前の Windows 7 お披露目会を兼ねたホーム パーティーに招待された方もいるでしょう (私の娘婿は Windows 7 コンピューターを持っていましたが、自ら購入したわけではなく、マイクロソフトから無料で手に入れたという理由で持っていました)。あの大々的な売り込み宣伝を目にしなかった方でも、多くのメディアがこぞって取り上げた、新しいコード ツリーを使用して、新しい OS を構成する、これらの新製品の新機能を賞賛または疑問視する声を耳にしたことがないという方はいないでしょう。

BranchCache と DirectAccess が、これらのリリースの目玉となる新機能であることは間違いなく、これらの機能は注目に値します。マイクロソフトは、BranchCache により、ブランチ オフィスの従業員が、本社オフィスの従業員と同じようにファイルを操作できるようになることを目標としています。また、DirectAccess では、リモート ユーザーが仮想プライベート ネットワーク (VPN) 経由で社内ネットワークに接続できるようにすることを目標としています。

マイクロソフトによくあることですが、新機能の恩恵を受けられるのは新しい製品を使用した場合に限られます。この場合、BranchCache と DirectAccess は、Windows 7 クライアントと Windows Server 2008 R2 サーバーにのみ実装できます。今月の記事では、この 2 つの新機能について詳しく見てみましょう。

BranchCache

BranchCache では、ユーザーが頻繁に使用するファイルを、一元管理されたネットワーク共有から取得するのではなく、ブランチ オフィスの Windows Server 2008 R2 サーバーまたはユーザーのワークステーションのローカルにキャッシュすることで、ブランチ オフィスのエクスペリエンスを向上します。BranchCache は、優れた機能ですが、注意しなければならないことがあります。

IT 部門で BranchCache を展開する際には、分散キャッシュ モードまたはホスト型キャッシュ モードを使用します (図 1 参照)。IT 部門では、グループ ポリシーを使用してキャッシュ モードを構成するので、ホスト型キャッシュ モードと分散キャッシュ モードを使用するオフィスが混在している場合は、2 つのポリシーを実装して、適切な組織単位 (OU) の構造を計画する必要があります。マイクロソフトは、クライアント数が 50 台以下のサイトでは分散キャッシュ モードを使用して BranchCache を展開することを推奨していますが、適切なキャッシュ モードは、WAN リンクの速度や帯域幅など、さまざまな要因に左右されます。分散キャッシュ モードでは、ホスト型キャッシュ モードよりも大容量のハード ディスクが必要となり、場合によっては、より多くのメモリや他のリソースが必要になることがあります。そのため、特にサイトに Windows Server 2008 R2 サーバーが配置されている場合は、ホスト型キャッシュ モードを使用するのが適切です。また、分散キャッシュ モードは、ローカル サブネットでしか機能しないことも考慮する必要があります。サイト内に複数のサブネットがある場合、各サブネットのクライアントは、同じサブネットの他のクライアントがファイルをダウンロードできるようにするため、ファイルをキャッシュする必要があります。ただし、ホスト型キャッシュ モードでは、サイト内の複数のサブネットに対してファイルのキャッシュを提供できるので、これもホスト型キャッシュ モードを推奨する理由の 1 つとなります。

図 1 ブランチ オフィスでは、BranchCache を分散キャッシュ モードかホスト型キャッシュ モードのいずれかで使用できる

分散キャッシュ モードでは、ブランチ オフィスにファイル サーバーを配置する必要はありません。ポリシーの設定によって、すべてのユーザー コンピューターが BranchCache クライアントとなります。つまり、すべてのユーザー コンピューターでは、ドキュメントをローカルにキャッシュして、(そのドキュメントが最新の状態である場合は) サイト内の他のクライアントがキャッシュされたドキュメントをダウンロードできます。

たとえば、Caroline が、本社サイトの BranchCache が有効になっているファイル サーバーにある Reports.docx 文書を要求した場合を考えてみましょう。BranchCache では、ファイルのコンテンツを記述したメタデータを送信し、メタデータのハッシュ値を使用して、ローカル サブネットでコンテンツを検索します。コンテンツが見つからない場合は、Caroline のコンピューターのローカル ドライブに本社サイトのサーバーにあるファイルのコピーがキャッシュされます。同じ日の午後に、Tyler が Reports.docx を変更するために、本社サイトのファイル サーバーの共有にアクセスして、ファイルのコピーを取得しようとすると、ファイル サーバーからはメタデータが返され、クライアントでは、ローカル サブネットでコンテンツを検索します。この場合、Caroline のコンピューターにあるコピーが検出され、このコピーがダウンロードされます。この処理は、メタデータのハッシュ値から派生した暗号化キーを使用して、セキュリティで保護された状態で行われます。その翌日に Abigail が、同じ文書を変更しようとすると、プロセスは Tyler のときと同じですが、Abigail は Tyler のコンピューターにキャッシュされているコピーを取得することになります。この場合もバージョン情報はサーバーに格納されます。クライアントはサーバーにアクセスして、ローカル サイトに最新版のコピーがあるかどうかを確認します。

これは、ユーザーがさまざまなドキュメントを操作する場合に発生する 3 つの BranchCache シナリオの 1 つです。残りの 2 つのシナリオは次のとおりです。

• ブランチ オフィスのユーザーが、ローカル コンピューターにキャッシュされていないドキュメントについて、本社オフィスのファイル サーバーに問い合わせます。ユーザーはファイルのコピーを受け取り、ファイルはローカルにキャッシュされます。
• ブランチ オフィスのユーザーは、ローカル サイトにキャッシュされているドキュメントについて本社オフィスのファイル サーバーに問い合わせますが、ファイルがキャッシュされているコンピューターの電源がオフになっています。クライアントは、ファイル サーバーから新しいコピーを取得して、ローカルにキャッシュします。これ以降の要求では、この一番最後にキャッシュされたコピーが取得されます。

どちらの場合も、ドキュメントは、本社オフィスのファイル サーバーにも保存されます。このメカニズムにより、Caroline が再度文書にアクセスする必要がある場合に、現時点で最新版がキャッシュされている Abigail のコンピューターの電源がオフになっていても、本社オフィスのファイル サーバーから最新版を取得することができます。

ホスト型キャッシュ モードを使用する場合、IT 部門で必要な作業は、ブランチ オフィスにある Windows Server 2008 R2 ファイル サーバーに BranchCache の機能をインストールしてサーバーを構成して、ホスト型キャッシュ モードを使用するようクライアントに指示するグループ ポリシーを構成することです。ホスト型キャッシュ モードを使用した場合のプロセスは、分散キャッシュ モードを使用した場合と同じですが、ファイルがユーザーのコンピューターではなく、ローカルで構成された BranchCache サーバーにキャッシュされる点が異なります。

注: 本社サイトのファイル サーバーで管理されているコンテンツのメタデータは、BranchCache が有効になっているサーバーにあるファイルが要求されるたびにクライアントに送信されます。このデータは、ローカル サイトのクライアントまたはサーバー (使用するキャッシュ モードによって異なります) に最新版のコピーがあるかどうかを判断するのに使用します。

BrachCache が有効になっているブランチ サイトのサーバーは、Web サーバーや Windows Server Update Services (WSUS) サーバーなど、他の目的にも使用できます。ただし、このような場合は、特別な配慮が必要になります。詳細については、「Windows Server 2008 R2 と Windows 7 向けの BranchCache 展開ガイド」(英語) と「BranchCache 早期導入ガイド」を参照してください。

BranchCache の構成

BranchCache を構成するには、グループ ポリシー オブジェクト (GPO) のしくみと、各サイトのコンピューターに作用するように OU 構造で GPO を構成する方法を理解する必要があります。BranchCache シナリオでは、すべての関連サーバーで Windows Server 2008 R2 が実行され、すべてのクライアントで Windows 7 が実行されている必要があることに注意してください。BranchCache の構成手順は次のとおりです。

手順 1 サーバー マネージャーを使用して BranchCache の機能をインストールします。

 

手順 2 ファイル サーバーで BranchCache の機能を使用する場合は、ファイル サービスの役割だけでなく、ネットワーク ファイル用 BranchCache の役割もインストールする必要があります (図 2 参照)。

図 2 BranchCache をインストールするには、ファイル サービスとネットワーク ファイル用 BranchCache の役割を有効にする必要がある

手順 3 BranchCache の GPO を構成します。[コンピューターの構成]、[ポリシー]、[管理用テンプレート]、[ネットワーク]、[BranchCache] を順に展開します。このポリシー設定では、次の 5 つの設定を構成できます。

• BranchCache を有効にする: BranchCache の機能を使用するには、この設定を有効にする必要があります (図 3 参照)。分散キャッシュ モードまたはホスト型キャッシュ モードのポリシー設定を有効にしないで BranchCache を有効にすると、Windows 7 クライアントでは、ファイルがローカルにキャッシュされます。この設定は、1 台のコンピューターを複数のユーザーで共有している場合に便利です。

   

  

図 3 グループ ポリシー管理コンソールで、ブランチ オフィスでキャッシュ機能を利用できるように BranchCache を有効にする

• BranchCache を分散キャッシュ モードに設定する: この設定は、GPO で指定されているすべてのクライアントに適用されます。
• BranchCache をホスト型キャッシュ モードに設定する: キャッシュをホストするサーバーを指定します。キャッシュ モードは単独で使用する必要があり、同時に 2 つのモードは使用できません。1 つのサイトで構成できるモードは 1 つだけです。
• ネットワーク ファイルの BranchCache を構成する この設定が構成されていないか、無効になっている場合は、待ち時間のしきい値は 80 ミリ秒に設定されます。要求に 80 ミリ秒以上かかるファイルは、キャッシュされます。この設定を有効にして、必要に応じて待ち時間の値を変更します。
• クライアント コンピューター キャッシュに使用するディスク領域の割合を設定する: 既定では、ユーザーのディスクの 5% に設定されています。この設定の値は、キャッシュを利用できるメリットとユーザーが使用できるディスク領域のバランス見ながら、適宜調整する必要があります。各コンピューターのディスク サイズが大きく異なる場合は、コンピューターによってキャッシュに使用できるディスク領域が大きく異なるため、問題になる可能性があります。

 

手順 4 BranchCache のポリシーで、GPO 設定の "LAN Manager サーバー" を構成します。手順 3 と同じ領域で [LAN Manager サーバー] の設定に移動し、[BranchCache のハッシュの発行] のプロパティを確認します。ここでは次の 3 つのオプションがあります。

• ハッシュの発行をすべての共有フォルダーで許可しない
• ハッシュの発行をすべての共有フォルダーで許可する
• ハッシュの発行を BranchCache が有効になっている共有フォルダーにのみ許可する

ファイル サービスの役割をインストールした Windows Server 2008 R2 サーバーは、BranchCache のコンテンツ サーバーとして使用するのに適していますが、ネットワーク ファイル用 BranchCache の役割をインストールして、ハッシュの発行を有効にする必要があります。BranchCache は、各ファイル共有で個別に有効することもできます。また、ハッシュの発行も、各サーバーで個別に有効にしたり (たとえば、ドメインに参加していないサーバーの場合)、グループ ポリシーを使用して複数のサーバーで有効にしたりすることができます。このように、BranchCache は、すべての共有フォルダーや一部の共有フォルダーで有効にしたり、全面的に無効にしたりすることができます。

 

手順 5 Windows ファイアウォールで、TCP ポート 80 への着信を許可します (クライアント コンピューター側の設定です)。

手順 6 必要な設定をすべて構成し、ファイル共有にユーザーのファイルがある場合は、サーバー マネージャーで [ファイル サービス] を展開し、[共有と記憶域の管理] を展開します。中央ペインには共有の一覧が表示されます。共有を右クリックし、[プロパティ] をクリックして、[詳細設定] をクリックします。[キャッシュ] タブで [BranchCahce を有効にする] チェック ボックスをオンにします (図 4 参照)。注: このチェック ボックスが利用できない場合は、既に説明したとおり、BranchCache の機能が正常にインストールされていないか、ポリシーで BranchCache が無効に設定されています。

図 4 共有と記憶域の管理で、BranchCache の機能を共有で有効にする

BranchCache のクライアント構成

既定では、すべての Windows 7 クライアントで BranchCache の機能が有効になっているので、クライアント側では BranchCache の機能を有効にするために特別な構成を行う必要はありません。ただし、クライアント側では、次の 2 つの手順を実行する必要があります。

• ファイアウォールの設定を構成します。ファイアウォールの設定については既に説明しましたが、ホスト型キャッシュ モードを使用する場合には、他にいくつかの要件があります。詳細については、この記事の最後で紹介するマイクロソフトが提供している BranchCache に関するドキュメントを参照してください。
• クライアントは、BranchCache を有効にし、使用するキャッシュ モードを定義しているポリシーを含む OU に参加している必要があります。詳細については、この記事の最後で紹介するドキュメントを参照してください。

BranchCache の長所

BranchCache を使用するメリットは次のとおりです。

• BranchCache では、アプリケーションが終了している場合でも、ユーザーがログインしていれば、バックグラウンド インテリジェント トランスファー システム (BITS) を使用して、バックグラウンドでファイルを転送できます。この機能は、低速なリンクで接続されているブランチ オフィスで有益です。システムの再起動が必要な場合でも、再起動が完了した時点で、ファイルの転送が再開されます。この機能を使用するには、アプリケーションの設計が BITS に対応している必要があります。
• BranchCahce は、Netsh コマンド ライン ユーティリティを使用して構成することが可能です。詳細については、「Windows Server 2008 R2 の BranchCache」を参照してください。
• BranchCache のパフォーマンスは、クライアント、ファイル サーバー、およびキャッシュ ホストでパフォーマンス カウンターを使用して監視できます。パフォーマンス カウンターは、パフォーマンスの診断に役立つだけでなく、私の知る限りでは、クライアントで実際にキャッシュされたコピーが取得されているかどうかを確認する唯一の手段となります。
• BranchCache の環境は、グループ ポリシーで制御できます。

BranchCache の短所

BranchCache が有益な機能であるのは間違いありませんが、次のような欠点があることに注意してください。

• 分散キャッシュ モードでは、実質的に、すべてのワークステーションがファイル サーバーとなるので、頻繁にアクセスがあるファイルをホストしているクライアント コンピューターではパフォーマンス ヒットが発生する可能性があります。実際の影響度合いを判断するにはテストを実施する必要があります。
• 十分なキャッシュ サイズを確保するために、クライアントでは追加のディスク領域が必要になることがあります。
• データをキャッシュするクライアントでは、他のクライアントとネットワーク リソースを奪い合うことになります。
• 最初のキャッシュ処理やキャッシュにあるファイルが利用できない場合には、遅延が発生する可能性があります。BranchCache の機能を使用できるのは Windows 7 クライアントと Windows Server 2008 R2 サーバーに限られるので、この機能を社内全体で展開するには時間がかかる可能性があります。

ファイル サーバーをブランチ オフィスに配置できる場合は、分散ファイル システム (DFS) を使用することをお勧めします。キャッシュ ファイルが散在している状態ではなく、分散ファイル システム レプリケーション (DFS-R) を使用して、ファイルを複製し、DFS を使用して名前空間を維持できます。場合によっては、ネットワーク ファイルをキャッシュすることで得られるメリットがあり、DFS 共有でも BranchCache は機能するでしょう。また、パフォーマンス上の問題から、DFS-R よりもキャッシュの方が適している場合があり、本格的な DFS の構成よりも、BranchCache の方がサーバーに与える影響が少なく済みます。重要なのは、ニーズを調査して、BranchCache で使用できるオプションを分析することです。もちろん、環境はオフィスによって異なるので、あるブランチ オフィスで問題となることが、別のブランチ オフィスでは問題にならないこともあります。すべての状況に適した完全無欠の答えはありません。

DirectAccess

マイクロソフトは、DirectAccess により、Windows 2000 以降で利用できるようになった VPN の低レベルなエクスペリエンスに対処し、初期実装に多くの機能強化を施しました。DirectAccess を構成したクライアントでは、手動で VPN 接続を確立しなくても、リモートの場所からイントラネット サイトにアクセスできます。また、非常に喜ばしいことに、IT 部門のスタッフは、VPN 接続ではなく、インターネット接続経由でリモート コンピューターを管理できるようになります。自宅で会社のイントラネットに接続して作業をしているときにインターネット接続が切断されても、インターネット接続が利用できるようになると、VPN によって接続が再確立されます。DirectAccess を使用していない場合には、会社のイントラネットに再接続して、資格情報を再入力することが求められますが、その必要はありません。

実際、ユーザーには、DirectAccess は見えません。DirectAccess が有効になっているクライアント コンピューターで、ユーザーがイントラネットのリンクをクリックすると、DirectAccess によって接続と切断が処理されます。ユーザーが、接続マネージャーを開いて、資格情報を入力したり、接続が確立するまで待機したりする必要はありません。

リモート接続が確立されている間、ユーザーは、既定で "分割トンネリング" の構成を使用することになります (図 5 参照)。この構成により、イントラネット、ローカル ネットワーク (プリンターなどのデバイスを使用するため)、およびインターネットへの同時アクセスが可能になります。分割トンネリングを使用しない一般的な VPN シナリオで、インターネットに接続するときには、まずイントラネットにアクセスして、社内ネットワークのゲートウェイ経由でインターネットへの接続を確立します。また、回避策はありますが、既定の設定では、ローカル ネットワークにはアクセスできません。DirectAccess は、リモート ユーザーに、従来の VPN よりも、オフィスにいるときと同じようなエクスペリエンスを提供することを目標に設計されています。

 

図 5 DirectAccess を使用すると、社内ネットワークとインターネットに同時接続できる分割トンネリング構成が可能になる

IT 部門にとっては、(DirectAccess はインストールされていると有効になるので) コンピューターでインターネットへの接続が確立されると、修正プログラム、ポリシーなどの更新を簡単かつ IPsec 接続経由で安全に適用できるというメリットがあります。

DirectAccess のシステム要件

DirectAccess の基本構成では、DirectAccess サーバーは、ネットワークの境界に配置され、リモート ユーザーに社内リソース (アプリケーション サーバー、証明機関 (CA)、DNS、ドメイン コントローラー (DC) など) へのアクセスを提供します。CA とアプリケーション サーバーは、IPv6 トラフィックを受け付けるように構成されている必要があります。DirectAccess の構成に必要なコンポーネントは、次のとおりです。

• Active Directory ドメインの DirectAccess クライアントは、Windows Server 2008 または Windows Server 2008 R2 を実行している DC にしかアクセスできません。
• グループ ポリシーの定義では、DirectAccess の設定で次のことを強制する必要があります。
  • DirectAccess クライアントを特定する
  • 名前解決ポリシー テーブル (NRPT) を構成する
  • DNS のグローバル制限一覧から Intra-Site Automatic Tunneling Address Protocol (ISATAP) を削除する

• DirectAccess サーバーの要件は次のとおりです。
  • Active Directory ドメインのメンバーである
  • Windows Server 2008 R2 が実行されている
  • イントラネット接続とインターネット接続用に 2 枚のネットワーク カードが構成されている
  • 外部で解決できる 2 つの連続した静的な IPv4 アドレスを持っている

• サーバー マネージャーで、DirectAccess の管理機能を使用してインストールし、セットアップ ウィザードを実行して構成する必要があります。

 

• IIS/Web サーバーを使用すると、イントラネット リソースにアクセスできるかどうかを判断する機能が利用できます。アプリケーション サーバーは、DirectAccess が構成されているクライアントによるアクセスを許可するように構成されている必要があります。
• CA を使用するには、Active Directory 証明書サービスをインストールして、認証に使用する証明書を発行する必要があります。
• ネイティブの IPv6 ネットワークと移行テクノロジのどちらかがイントラネット全体で利用できる必要があります。
• セキュリティで保護された認証と DirectAccess 接続の暗号化に IPsec ポリシーを使用すると、ユーザーがログオンする前にクライアントを認証できます。
• 設定が必要なファイアウォールの例外の詳細については、「DirectAccess 早期導入者ガイド」を参照してください。

ご覧のとおり、DirectAccess は気弱な人には向いていません。IPv6 の要件だけをとっても、不安要素があると思いますが (また、多くの組織では、移行テクノロジを実装する必要がありますが)、Windows Server 2008 R2 には、これに対応するためのコンポーネントが用意されています。また、公開キー基盤 (PKI) を使用してセキュリティを有効にしたり、認証サービスを提供したり、アプリケーション サーバーで IPv6 でアプリケーション サーバーを識別できるように設定したりする必要があります。DirectAccess のセットアップ ウィザードを実行する前に、セキュリティ グループを構成し、ファイアウォールのポリシーを設定し、DNS を設定するなど、多数の事前要件を満たすための作業を行う必要があります。

DirectAccess サーバー

DirectAccess サーバーでは、サーバー マネージャーの DirectAccess セットアップ ウィザード (図 6 参照) で定義された、多数の機能を実行します。

図 6 サーバー マネージャーから DirectAccess のセットアップを実行する

DirectAccess のセットアップ ウィザードでは、4 つの主なタスクを実行します。ウィザードで実行するタスクは、次のとおりです。

1. DirectAccess を有効にするクライアントを特定します。信頼関係が確立されている場合は、他のドメインやフォレストのセキュリティ グループを指定できます。ウィザードを実行する前に適切なセキュリティ グループを定義する必要があります。
2. DirectAccess サーバーの接続とセキュリティ (証明書) を定義します。インターネットとイントラネットのそれぞれに接続するネットワーク インターフェイスを識別します。DirectAccess のセットアップ ウィザードを実行する前に CA をインストールして、証明書を作成します。また、スマートカードのポリシーも定義します。
3. DirectAccess 環境で使用する DNS と DC を特定します (必要に応じて、管理インフラストラクチャ サーバーなども特定します)。また、ネットワーク ロケーション サーバーとして使用する、可用性の高いサーバーも特定する必要があります。この役割は、DirectAccess サーバーで兼任できます。
4. DirectAccses クライアントからの接続を受け付けるように構成されたアプリケーション サーバーを特定します。既定ではエンド ツー エンドの承認は行いませんが、IPsec ポリシー ベースのセキュリティ オプションを選択して、承認を行うこともできます。

DNS と NRPT

既に説明したように、DirectAccess クライアントは、イントラネットに直接アクセスできます。DirectAccess クライアントがイントラネットに直接アクセスできるようにするには、ネットワーク インターフェイスではなく DNS 名前空間ごとに DNS を定義した NRPT を実装する必要があります。個人的に、これは Windows Server 2003 サーバーや Windows Server 2008 サーバーで条件付きフォワードが動作するしくみと同じだと考えています。条件付きフォワードでは、サーバーに接続するときに使用する適切な IP アドレスを使用して DNS 名前空間を定義します。NRPT を使用すると、クライアントでは、通常の DNS 参照を回避して、DirectAccses サーバーに直接アクセスするようになります。

NRPT のしくみは、次のとおりです (図 7 参照)。

1. 名前のクエリ要求は、DirectAccess サーバーをポイントしている社内イントラネット用に構成された名前空間と照合されます。
2. NRPT は、IP アドレスと DirectAccess サーバーの完全修飾ドメイン名 (FQDN) を含んでいます。IP アドレスを使用すると、DNS サーバーへの接続が暗号化され、セキュリティで保護された接続が提供されます。
3. FQDN を使用する際には、インターネット経由で名前を解決して、社内の DNS サーバーを検出する必要があります。
4. クライアントから NRPT で定義されていない名前空間 (たとえば、www.microsoft.com) の名前解決要求が送信されると、その要求は、インターネットによる通常の名前解決プロセスを踏みます。

図 7 NRPT を使用すると、インターフェイスではなく DNS 名前空間ごとに DNS サーバーを定義できる

 

NRPT は、DirectAccess セットアップ ウィザードの [インフラストラクチャ サーバーのセットアップ] ページで構成します。DNS サーバーの IPｖ6 アドレスは自動で指定されます。Windows Server 2008 R2 の新しいグループ ポリシーの設定 "名前解決ポリシー" では、IPsec、DNS サーバー、名前空間がクエリしたネットワークに存在しない場合の名前解決フォールバックの方法など、具体的なポリシーの設定を定義します。このポリシーには、[コンピューターの構成]、[Windows の設定]、[名前解決ポリシー] を順に展開してアクセスできます (名前空間は、.emea.corp.net のように、先頭にドットを追加した状態で入力する必要があることに注意してください)。

NRPT の内容は、Netsh name show policy という Netsh コマンドを使用して確認できます。

このコマンドを実行すると、定義されている名前空間を確認できます。

ファイアウォールの除外

ファイアウォールの除外は、IPv6 ネットワークの実装方法と移行テクノロジを使用しているかどうかによって異なります。また、リモート クライアントが接続する必要のあるファイル サーバーやアプリケーション サーバーでは、Windows ファイアウォールを適切に構成する必要があります。図 8 と図 9 に、DirectAccess サーバーのインターネット接続とイントラネット接続用ファイアウォールのファイアウォールの除外の設定をそれぞれ示します。もちろん、除外を設定する必要があるのは、使用しているテクノロジについてのみです (図 9 には IPv4+NAT-PT が含まれていますが、Windows Server 2008 R2 には実装されていないことに注意してください)。

 

図 8 インターネット接続用ファイアウォールのファイアウォールの設定

移行テクノロジ	許可するプロトコル
Teredo	UDP 3544
6to4	IP プロトコル 41
IP-HTTPS	TCP 443
ネイティブ IPv6	ICMPv6、IP プロトコル 50

 

 

図 9 イントラネット接続用ファイアウォールのファイアウォールの設定

 

プロトコル	IPv6 テクノロジ
	ISATAP	ネイティブ IPv6	IPv4 + NAT-PT
IP プロトコル 41	X
TCP		X	X
UDP		X	X
ICMPV6		X
すべての IPv6 接続		X
UDP 500 IKE/AuthIP		X	X

 

接続性 - IPv6

IPv6 プロトコルでは、DirectAccess クライアントが社内ネットワークにあるリソースへの常時接続を確立することが許可されるので、クライアントでは、このプロトコルを実行している必要があります。完全な IPv6 ネットワークを実装している場合も、リモート接続を提供するには、DirectAccess クライアントが IPv4 パケット内に IPv6 をカプセル化することによって IPv4 リソースに接続できるようにするための移行テクノロジが必要になることがあります。このようなテクノロジには、6to4、IP-HTTPS、Teredo などがあります。ISATAP もカプセル化テクノロジですが、これは社内ネットワークでしか使用できません。この記事では詳しく説明しませんが、図 10 に基本的な接続のオプションを示します。

 

図 10 DirectAccess クライアントで使用する推奨の接続オプション

 

クライアントで使用しているアドレス	推奨する接続方法
グローバルにルーティング可能な IPv6 アドレス	グローバルにルーティング可能な IPv6 アドレス
パブリックな IPv4 アドレス	6to4
プライベートな (NAT) IPv4 アドレス	Teredo
上記のいずれを使用しても接続できない場合	IP-HTTPS

情報源: マイクロソフト

ネイティブな IPv6 アドレスを使用していないイントラネットでは、DirectAccess は ISATAP の使用を許可します。ISATAP では、IPv4 アドレスから IPv6 アドレスを生成し、独自の近隣探索機能を実装しています。ISATAP により、DirectAccess クライアントは IPv4 ネットワークにあるリソースにアクセスできるようになります。たとえば、ISATAP クライアントでは、起動時に ISATAP ルーターを検出する必要があります。これは、ISATAP.<ドメイン名> という形式の DNS クエリを発行することで行います。Corp.net の場合は、ISATAP.corp.net を検索します。Windows Server 2008 の DNS では、GlobalQueryBlockList を実装しています (GlobalQueryBlockList は、既定で ISATAP を含む追加のセキュリティ機能です)。この機能により、ISATAP.<ドメイン名> という形式の要求が無視されるようになります。そのため、一覧から ISATAP を削除する必要があります。この処理は、DNSCMD コマンドを使用するか、レジストリ エントリを作成して行います。

コマンド プロンプトで「dnscmd /config /globalqueryblocklist wpad」と入力し、Enter キーを押します。このコマンドを実行すると、WPAD のみを含む (ISATAP は削除された) GlobalQueryBlockList が定義されます。これは、HKLM:\System\Current Control Set\Services\DNS\Parameters レジストリ キーにアクセスして、GlobalQueryBlockList を編集して、ISATAP を削除することでも行えます。

また、ネットワーク全体またはホストで個別に 6to4 を実装して、IPv4 ネットワーク経由で IPv6 パケットを転送することもできます。興味深いことに、ネットワーク全体に 6to4 を実装すると、1 つの IPv4 アドレスだけが必要になります。IPv4 と IPv6 のどちらかにしか対応していないホスト間のトラフィックはサポートされません。

Teredo でも、IPv6 パケットが IPv4 ネットワークにルーティングされますが、Teredo は、クライアントが IPv6 に対応するように構成されていないネットワーク アドレス変換 (NAT) サーバーの内側に存在する場合にのみ使用します。Teredo では、NAT から転送できる IPv4 データグラムに IPv6 パケットを格納します。

Windows 7 と Windows Server 2008 R2 では、IPv4 ベースの HTTPS セッションで IPv6 パケットをトンネリングする IP-HTTPS という名前のプロトコルが実装されました。IP-HTTPS のパフォーマンスは他のプロトコルに劣りますが、IP-HTTPS サーバーを追加すると、パフォーマンスが多少向上します。IP-HTTPS は、IPv6-over-IPv4 ネットワークの接続を実現するプロトコルとしては簡単に使用できるものです。

DirectAccess クライアントの構成を設計するときには、DNS か NRPT のどちらかを使用して、インターネット トラフィックとイントラネット トラフィックを分離できます。また、トンネルの強制と呼ばれるものを使用して、すべてのトラフィックをトンネリングするように強制することもできます。トンネルの強制では、IP-HTTPS プロトコルを使用する必要があります。これは、"内部ネットワーク経由ですべてのトラフィックをルーティングする" グループ ポリシーの設定で有効にできます。このグループ ポリシーの設定には、[コンピューターの構成]、[ポリシー]、[管理用テンプレート]、[ネットワーク]、[ネットワーク接続] を順に展開してアクセスできます。このポリシーは、DirectAccess クライアントに適用する必要があります。既に説明したように、DirectAccess クライアントは、イントラネットに接続しているときにもローカル リソースにアクセスできます。これは IP-HTTPS クライアントにも当てはまります。ただし、たとえば、ユーザーがインターネット サイトに接続しようとすると、イントラネット経由でルーティングされます。

IPv6 の要件と複雑な構成は DirectAccess の短所ですが、DirectAccess を使用すると、ユーザー エクスペリエンスが向上し、IT 部門によるリモート クライアントの管理が簡単になるという、この短所に勝る長所があります。

前途有望

リモート ユーザーの数は増えています。ブランチ オフィスで作業をするユーザーもいれば、自宅や外出先で作業をするユーザーもいます。BranchCache と DirectAccess は、ブランチ オフィスをはじめとするリモート ユーザーにとって、前途有望な機能なので、IT 部門のマネージャーや IT 管理者は、これらの機能に投資することをお勧めします。どちらのもすぐに使えるものではありませんが、多数のオプションと機能が用意されています。また、これらの機能が Windows 7 クライアントと Windows Server 2008 R2 サーバーでしか使えないという特性は、実装のタイムラインには間違いなく影響を及ぼすでしょう。IT 部門のマネージャと IT 管理者は、マイクロソフトが提供しているドキュメントを調査し、テスト ラボで機能を構成して、運用環境への展開を正常に行えるようにすることをお勧めします。

関連コンテンツ

• Windows Server 2008 R2 と Windows 7 向けの BranchCache 展開ガイド (英語)
• Windows Server 2008 R2 の BranchCache
• BranchCache 早期導入ガイド
• DirectAccess をテスト ラボで使用するためのステップ バイ ステップ ガイド
• DirectAccess の設計と展開のガイド (英語)
• Windows 7 と Windows Server 2008 R2 のエンタープライズ向けネットワーク機能の強化
• DirectAccess 導入事例: Sporton International (英語)、Convergent Computing (英語)
• www.microsoft.com/japan/downloads にアクセスし、[検索] ボックスの一覧の [すべてダウンロード] をクリックして、「DirectAccess」または「BranchCache」と入力して検索すると、検索結果から有益な TechNet ブログ、他のドキュメントや Web キャストにアクセスできます。

 

Gary Olsen は、ジョージア州アトランタにある Hewlett-Packard の Worldwide Technical Expert Center (WTEC) でシステム ソフトウェア エンジニアとして働いています。1981 年から IT 業界で働いています。ディレクトリ サービスの Microsoft MVP であるだけでなく、Atlanta Active Directory Users Group の創設者で委員長を務めています。また、Redmond Magazine にも定期的に寄稿しています。