IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離

この章では、Microsoft Information Technology (IT) チームの経験と処理手法に基づき、サーバー/ドメイン分離シナリオを始めとするインターネット プロトコル セキュリティ (IPsec) のトラブルシューティングを行う方法について説明します。 該当する箇所では、マイクロソフトの既存のトラブルシューティング手順や関連情報を紹介します。

マイクロソフトの IT サポートは、多層構成のサポート モデルをベースとしています。ヘルプ デスクは第 1 層のサポートになります。 専門家のサポートが必要なインシデントの場合、ヘルプ デスクは、エスカレーション手順によって上位層にインシデントをエスカレートできます。

この章では、第 1 層、第 2 層、第 3 層という 3 つのレベルに分けて手順を説明します。 できるだけ実用的かつ簡潔なガイダンスになるように、説明内容は第 2 層のサポートを中心にしています。 最初の第 1 層のガイダンスでは、問題が IPsec に関連しているかどうかをできるだけ短時間で判断し、IPsec に関連している場合は、必要な情報を生成して第 2 層のサポート エンジニアが問題をスムーズに解決できるようにします。

第 3 層のトラブルシューティングで必要になる詳細かつ複雑な情報については、この章では扱いません。 この章に記載されている情報で IPsec に関する問題を解決できない場合は、マイクロソフト製品サポート サービスにお問い合わせになることをお勧めします。ここでさらに高度なサポートを受けることができます。

この章では、マイクロソフトが使用しているサポート手順、ツール、スクリプトの多くを参考に紹介しています。 これらの推奨事項やツールは、それぞれの組織の特定のニーズに応じて使用してください。

IPsec を使用してネットワーク上の Transmission Control Protocol (TCP) および User Datagram Protocol (UDP) トラフィックをセキュリティ保護している場合は、TCP/IP ネットワークに関する一般的なトラブルシューティング手順やツールは無効になります。 したがって、通信に IPsec を使用している (または使用しようとしている) コンピュータの間で問題が発生した場合に適用できる IPsec 固有のトラブルシューティング テクニックを計画し、作成しておくことが重要です。

トピック

	サポート層とエスカレーション
	第 1 層のトラブルシューティング
	第 2 層のトラブルシューティングの準備
	IPsec のトラブルシューティング プロセス
	第 3 層のトラブルシューティング
	要約

サポート層とエスカレーション

マイクロソフトでは、サーバー/ドメイン分離を標準サービスとしてサポートしており、標準サービス レベル契約 (SLA) に定義が記載されています。 分離へのサポートは、次の 3 つの層により提供されます。

以降のセクションでは、第 1 層のサポート組織に属するヘルプ デスクのスタッフが使用するトラブルシューティング テクニックについて、概要を説明します。

ページのトップへ

第 1 層のトラブルシューティング

ここでは、第 1 層のサポートを提供するヘルプ デスクのスタッフが使用する、IPsec 関連の問題のトラブルシューティング処理の全体について説明します。 一般的に、第 1 層のサポート担当者とは、電話で問い合わせを受けて離れた場所から問題の診断を試みるヘルプ デスクのスタッフ メンバのことを指します。

IPsec が問題の原因かどうかを特定する

ヘルプ デスクへの問い合わせとして考えられるのは、「IPsec を有効にするまではサーバー x に接続できたのですが」とか「昨日まではすべて正常に動作していたのに今日はどこにも接続できません」などといった質問です。マイクロソフトの IT 部門によれば、IPsec の公開以降、アプリケーションやネットワークの動作にユーザーが敏感になったため、あらゆる種類のネットワーク接続問題および "アクセス拒否" インシデントに関する問い合わせが増加しました。 問題が IPsec に関連している可能性があれば、ユーザーはヘルプ デスクに連絡してきました。 サーバー/ドメイン分離の実装計画では、問い合わせの分類システムを用意して、ヘルプ デスクの担当者が IPsec に関連する問題の件数と性質を明確に報告できるようにする必要があります。

ヘルプ デスクのスタッフは、連絡してきた相手から適切な管理情報を入手し、事前に定義されたトラブルシューティング プロセスに従って行動します。 IPsec ポリシーの設計は通信にさまざまな影響を与えます。また、公開プロセスには数日ないし数週間かかることがあります。そのため、フローチャートを定義して、分離の変更が実装されるたびにフローチャートを更新する必要があります。 ヘルプ デスクの管理担当者は、この計画プロセスに関与する必要があります。

ヘルプ デスクの業務目的は、問題を分類して既知の解決方法を適用できるようにすることです。 既知の解決方法で問題を解決できない場合、ヘルプ デスクの担当者は必要な情報を収集して、問題を第 2 層のサポートにエスカレートします。 ヘルプ デスクでは、次のような方法でさまざまな種類の問題を特定します。

組織によっては、ヘルプ デスクがリモート アシスタンスまたはリモート デスクトップを使用して連絡者のコンピュータに接続する場合があります。 この章で説明するガイドラインではリモート アクセスは必須の機能ではありませんが、リモート アクセスを利用すると、[IP セキュリティ モニタ] Microsoft 管理コンソール (MMC) スナップインまたはイベント ログ ビューアを介して連絡者を支援できるため、ヘルプ デスクの担当者にとっては便利なツールです。

ドメインを分離せずにサーバー分離を使用するシナリオでは、ヘルプ デスクの担当者は、分離グループのメンバであるサーバーを把握しておく必要があります。

範囲と深刻度の割り当て

第 1 層のサポートでまず対処しなければならないのは、問題によって誰が影響を受けるのかを明らかにすることです。 サポート担当者は、問題が別のユーザーにも発生しているかどうかを確認し、発生している場合はそのユーザーの数と問題の発生場所を把握する必要があります。 次に、サポート スタッフは問題の程度を特定する必要があります。 たとえば、単一のサーバーへの接続にだけ影響する問題なのか、さらに広範囲にわたる問題なのか (ネットワークの大部分でログオンまたは認証が失敗するなど) を確認します。

接続に関する問題の場合、ネットワーク通信で使用されている多くの層やテクノロジが関係する可能性があります。 サポート エンジニアは、解決方法に関連する特定の部分に限らず、Windows TCP/IP ネットワーク通信の一般的な動作の仕組みについても把握しておく必要があります。 ここでは、第 1 層のサポートが処理する必要のあるさまざまな問題の種類と、それぞれに含まれる一般的な問題点について説明します。

企業での一般的な IPsec 展開時に利用されるサーバー/ドメイン分離ソリューションには、他に 2 つの特徴があります。内部ネットワークで使用するアドレス範囲の定義にサブネット フィルタを使用する点、および、コンピュータが内部ネットワークに配置されているかどうかにかかわらず、IPsec ポリシーはドメイン メンバシップとグループ メンバシップに基づいて適用される点です。 結果的に、サブネット フィルタの設計に問題がある場合や、コンピュータが他のコンピュータに接続するためのネットワーク パスに問題がある場合は、特定の IP アドレスを使用した際には (LAN アドレスではなくワイヤレス アドレスを使用する場合など) ネットワークの一部にのみ、または特定のコンピュータにのみ、接続に関する問題が発生する可能性があります。

トラブルシューティングのフローチャート

ここで紹介する問い合わせ処理用フローチャートはマイクロソフトの IT 部門が開発したものであり、第 1 層の IPsec サポート問題を分類する際の参照として使用できます。 このうち 2 つのフローチャートでは、標準のツール以外に IPsec ポリシー更新スクリプトを使用しています。このスクリプトについては、この章で後述する「サポート スクリプトの例」で説明します。

図 7.1 は、初期診断を行い次のどの問題が発生しているのかを特定する場合に使用します。

•	ネットワークの接続に関する問題。 この場合は、ネットワークの基本的なトラブルシューティングを試してください。 問題を解決できない場合は、第 2 層のサポートにエスカレートします。
•	名前解決に関する問題。 この場合は、名前解決の基本的なトラブルシューティングを試してください。 問題を解決できない場合は、第 2 層のサポートにエスカレートします。
•	アプリケーションに関する問題。 この場合は、第 2 層のサポートにエスカレートします。
•	連絡者のコンピュータで発生している IPsec に関する問題。 この場合は、図 7.2 に進みます。
•	連絡者が接続しようとしている対象コンピュータで発生している IPsec に関する問題。 この場合は、図 7.3 に進みます。   図 7.1: 対象コンピュータとの通信に失敗した場合のトラブルシューティング プロセス 拡大表示する

注 : このフローチャートは、連絡者のコンピュータが IPsec を実行しており、ping –a コマンドが正常に機能するように DNS 逆引き参照ゾーンが構成されていることを前提としています。

図 7.2 は、連絡者自身のコンピュータに関する問題を特定する場合に使用します。 このフローチャートでは、診断以外にも、問題を特定せずに解決する IPsec ポリシー更新スクリプト (この章で後述する「サポート スクリプトの例」を参照) を使用することが想定されています。 図 7.2 の手順に従うと、連絡者のコンピュータで次のどの問題が発生しているのかを確認できます。

•	RRAS に関する問題。 この場合は、RRAS サービスを停止するか (RRAS を必要としない場合)、問題を第 2 層のサポートにエスカレートします。
•	ポリシーに関する問題。 この場合は、グループ ポリシーと IPsec ポリシーを更新を試みます。
•	ドメイン アカウントに関する問題。 この場合は、連絡者のコンピュータ用のドメイン アカウントを作成します。
•	上記のいずれにも当てはまらない。 Psec ポリシーの更新やドメイン アカウントの作成によって問題が解決されない場合は、問題を第 2 層のサポートにエスカレートします。 図 7.2: 連絡者のコンピュータの IPsec 関連の問題のトラブルシューティング 拡大表示する

図 7.3 は、特定の対象コンピュータの問題を特定する場合に使用します。 このフローチャートでは、問題を特定せずに解決する IPsec ポリシー更新スクリプトの使用も想定されています。 図 7.3 を参照すると、対象コンピュータ (または対象コンピュータへのパス) で次のどの問題が発生しているのかを特定できます。

•	RRAS に関する問題。 この場合は、第 2 層のサポートにエスカレートします。
•	IPsec ポリシーに関する問題。 この場合は、グループ ポリシーと IPsec ポリシーを更新を試みます。 次に、ネットワークの接続を確認します。
•	ネットワークの接続に関する問題。 この場合は、第 2 層のサポートにエスカレートします。
•	ログオン権限に関する問題。 この場合は、第 2 層のサポートにエスカレートします。 図 7.3: 対象コンピュータの IPsec 関連の問題のトラブルシューティング 拡大表示する

第 1 層のサポート スタッフがフローチャートどおりの作業を完了したとき、問題のステータスは次のいずれかになります。

ソーシャル エンジニアリング攻撃に対する防御

分離ソリューションでは、ヘルプ デスクの担当者が IPsec で保護されていない特定の領域 (適用除外リストのメンバであるコンピュータなど) が IT 環境内に存在することに気付く場合があります。 他のセキュリティ ソリューションでは、このような重要な情報は通常高レベルのサポート チームしか利用できないため、ヘルプ デスクの担当者は機密情報を保護する業務には不慣れな可能性があります。 したがって、ヘルプ デスクの担当者は、ソーシャル エンジニアリング攻撃を発見して対抗する手段を身に付けておく必要があります。

ソーシャル エンジニアリング攻撃では、多くの場合他人を信頼するという人間の性質を利用することで、信頼されていない人物がセキュリティの実装内容やセキュリティの脆弱な箇所に関する情報を取得しようとします。 ヘルプ デスクの担当者は、次の情報を注意して管理する必要があります。

また、ヘルプ デスクの担当者は、連絡者が自分のコンピュータの IP アドレスに接続して障害箇所をチェックするように依頼してきた場合にも注意する必要があります。たとえば、攻撃者がヘルプ デスクの担当者に対して、ファイル共有、リモート デスクトップ、Telnet やその他のネットワーク プロトコルを使用して自分のコンピュータに接続するように仕向ける場合があります。 ヘルプ デスクの担当者が IPsec を使用せずに接続を確立すると、攻撃者は自分のコンピュータでパスワードに関する情報を取得したり、場合によっては Telnet などでパスワードを盗むことができます。 このような状況が発生するのは、クライアント ネットワーク プロトコルの中に、まず認証を行って宛先コンピュータと強力な信頼を確立することをしないものや、強力なパスワード保護を通さずにユーザー ID やパスワード関連の情報を公開するものがあるためです。

サポート スクリプトの例

ほとんどのトラブルシューティング シナリオでは、権限に関する情報を特定すると、解決方法を短時間で確定することができます。 この情報を検出するには、フローチャートで示したようなさまざまな Windows ツールを使用できます。 Woodgrove Bank のソリューションでは、第 1 層のサポート スタッフがツールの操作や構文について詳しく知らなくても重要な情報を特定できるように、多数のスクリプトが用意されています。 これらのスクリプトは、このガイドのダウンロード パッケージにある Tools and Templates フォルダに収録されています。

第 1 層のサポートで利用できるスクリプト

ユーザーがコンピュータのローカル管理者である場合、ヘルプ デスクの担当者は、このソリューションに同梱されている 3 つのスクリプトのいずれかをそのユーザーの環境で実行させることができます。 それらのスクリプトは、このガイドで詳しく説明している Woodgrove Bank 環境用にカスタマイズされたスクリプトのサンプルです。 トラブルシューティング プロセスをサポートするためスクリプトをどのように使用するかについては、この章で説明しています。

注 : これらのスクリプトはテスト済みですが、マイクロソフトによるサポートの対象ではありません。 組織独自のカスタム ソリューションを作成するためのベースとして使用してください。

IPsec_Debug.vbs

このスクリプトを使用すると、デバッグ情報が検出されるだけでなく、一部の問題を修正することもできます。 IPsec サービスを停止して再起動し (現在のすべての IKE および IPsec セキュリティ アソシエーションを削除)、強制的にグループ ポリシーの更新を実行して Active Directory® ディレクトリ サービスからドメインに割り当てられている現在の IPsec ポリシーを再度読み込み、ポリシー キャッシュを更新します。 リモート デスクトップ セッションの接続が失われるのを防ぐため、スクリプトは連絡者のコンピュータにダウンロードして、管理者権限を持つアカウントによりローカルで実行するように指示します。 スクリプトを実行するには、コマンド プロンプトで次の構文を使用します。

    cscript IPsec_Debug.vbs

スクリプトにより、次の機能が実行されます。

このスクリプトを使用すると、第 2 層のトラブルシューティングで使用される IPsec 関連のログもすべて有効になります。

Detect_IPsec_Policy.vbs

このスクリプトを使用すると、現在のローカル レジストリ キャッシュでドメイン IPsec ポリシーのポリシー バージョン情報がチェックされ、コンピュータが正しい IPsec ポリシーを実行しているかどうかを確認できます。 スクリプトを実行するには、コマンド プロンプトで次の構文を使用します。

    cscript Detect_IPsec_Policy.vbs

注 : このスクリプトは、IPsec_Debug.vbs でも呼び出すことができるため、IPsec_Debug.vbs とこのスクリプトを重複して実行する必要はありません。

Refresh_IPsec_Policy.vbs

このスクリプトは、トラブルシューティング フローチャートで紹介されている IPsec ポリシー更新スクリプトです。 コンピュータの Kerberos 認証プロトコル チケットとグループ ポリシーを更新し、IPsec ポリシーの割り当てが間違っていた場合やグループ ポリシーのダウンロードに失敗した場合に発生する問題を修正することができます。 スクリプトを実行するには、コマンド プロンプトで次の構文を使用します。

    cscript Refresh_IPsec_Policy.vbs

エスカレーション

ヘルプ デスクの担当者が IPsec 関連と思われる問題をエスカレートする場合は、第 1 層で次の情報を収集し、サービス要求とともに提供する必要があります。

サーバー分離シナリオでは、多くの場合、ネットワーク アクセス グループのメンバシップを検証するために独自のサポート チームが用意されています。  

ページのトップへ

第 2 層のトラブルシューティングの準備

第 2 層のサポートには、主に 2 つの役割があります。 1 つ目は、第 1 層からのすべてのエスカレーションを受け取る窓口としての役割です。サポート スタッフは問題の検証と第 1 層が実施した手順の見直しを行い、トラブルシューティング手順に手落ちがないことを確認します。 つまり、エスカレートされた問題が診断の誤りではなく、本当に IPsec が原因で発生しているのかを確認する必要があります。 2 つ目は、熟練したネットワーク サポート エンジニアとしての役割です。第 2 層のサポート スタッフは、コンピュータの管理制御を取得せずに、スキルと経験 (次のセクションのリストを参照) を駆使してログの分析から問題を解決します。 ただし、ログでは情報を取得できるだけなので、実際に解決のための作業を行う場合は管理的なアクセスが必要になります。 第 2 層のサポート担当者はドメイン管理者である必要はありません。また、ドメインべースの IPsec ポリシーやコンピュータ グループのメンバシップを変更する権限も必要ありません。

第 2 層のサポート スキル

第 2 層の IPsec サポートを提供するサポート スタッフには、次の分野に関するスキルと経験が求められます。

IPsec の使用による固有の問題

前のセクションで説明したように、サーバー/ドメイン分離ソリューションの第 2 層のサポート担当者は、IPsec で保護された通信のことを詳しく理解している必要がありますが、他のテクノロジ コンポーネントに関連する問題を分離する能力も必要です。

通常、2 台のコンピュータの間で IPsec 通信を正常に行うには、双方に互換性のある IPsec ポリシーを割り当てる必要があります。 たとえば、リモート コンピュータに適切な IPsec ポリシーが割り当てられていない場合、IPsec ポリシーによって通信がブロックされることがあります。 これは、ポリシー変更を公開中の場合は意図的または適切な動作であることもありますが、1 台以上のコンピュータでネットワーク接続がブロックされ、アプリケーション警告またはエラーが表示されているかどうかを直ちに確認することはできません。 最悪の場合は、管理者が IPsec ポリシーを誤ってすべてのドメイン メンバに割り当てた結果、すべてのトラフィックがブロックされている可能性もあります。 誤りにすぐに気付かない限り、元の割り当てに正しい割り当てを複製しても、誤りを含むポリシーの複製を停止することは容易ではありません。 このような誤りがあると、クライアントとドメイン コントローラの間の通信で IPsec を使用する必要性が出てきます。 このソリューションで使用されている認証は Kerberos プロトコルに依存しているため、このポリシーが初めから割り当てられているクライアントは、通信のセキュリティ保護に必要な Kerberos チケットを取得できません。そのため、ログオン プロセスを完了できなくなります。 ポリシーを変更する場合、管理者は慎重に計画を立てて、このようなリスクを軽減する手続き的な予防対策を講じる必要があります。

TCP/IP のトラブルシューティングに関する背景情報については、この章の最後の「関連情報」で紹介しているトラブルシューティング ガイドを参照してください。 ただし、これらのガイドに記載されている手順の多くは、IPsec で正常に接続を実行できている場合にのみ機能します。 IKE または IPsec で障害が発生すると、ほとんどの手順とツールが無効になる可能性があります。 サーバー/ドメイン分離シナリオでは、IPsec で正常に接続を実行できている場合でも、背景ガイドに記載されている手順の一部がまったく機能しない可能性があります。 サポート組織は、トラブルシューティング ツールと手順の更新およびカスタマイズを実施して、サーバー/ドメイン分離環境内で常に有効に利用できるようにしておく必要があります。 IPsec ポリシーを展開してトラフィックの制御とセキュリティ保護を実施する場合、多数のさまざまな方法があるため、既存の手順や汎用ツールキット以外に頼るものがないということは考えられません。

サポート担当者は、サーバー/ドメイン分離やその他の IPsec 展開が正常に機能するラボ環境から取得したネットワーク トラブルシューティング ツールの出力例を、文書化しておく必要があります。 多くの場合、ネットワーク診断ツールでは、クリアテキストへのフォールバックにかかる 3 秒の遅延、または、IPsec セキュリティ アソシエーション (SA) の最初の IKE ネゴシエーションに必要な若干の遅延は想定されていません。 したがって、ツールの初回実行時の結果と数秒後に実行したときの結果は異なる場合があります。 さらに、IPsec でネットワーク アクセスを意図的に拒否した場合、ツールはこれを障害として報告します。 障害のタイプは、ツールや IPsec 環境によって異なります。

注 : 第 1 層のセクションでは、サポート スタッフが行う一般的な問題のトラブルシューティングを分かりやすく説明するために、"連絡者" と "対象" という用語を使用しました。 第 2 層のセクションでは、より高度なトラブルシューティング プロセスを分かりやすく説明するために、IPsec 用語の "開始側" と "応答側" という言葉を使用します。 この章のこれ以降のセクションでは、この IPsec 用語を使用します。

グループ ポリシーとグループ メンバシップ

ドメインべースの IPsec ポリシーは、グループ ポリシーと GPO のダウンロードに依存します。 クライアントのグループ ポリシー システムで GPO の変更の検出時またはダウンロード時にエラーが発生した場合、IPsec 接続に影響することがあります。 グループ ポリシーの割り当てが組織単位 (OU) のメンバシップによって制御されている場合、コンピュータ アカウントをうっかり別の OU に移動するとか、削除するとか、間違った OU で再作成すると、不適切な IPsec ポリシーが割り当てられる可能性があります。

このソリューションでは、ポリシー割り当てとネットワーク アクセスの制御にドメイン セキュリティ グループを使用しています。 グループ メンバシップは、有効期間が非常に長い Kerberos バージョン 5 認証プロトコル チケット (TGT およびサービス チケットの両方) に格納されています。 このため管理者は、コンピュータが新しい Kerberos TGT とグループ メンバシップの更新を含むサービス チケット資格情報を取得するまでに要する時間を計画する必要があります。 Kerberos プロトコルを使用すると、コンピュータ用の Kerberos チケットに正しいグループ メンバシップが格納されているかどうかが非常に判断しにくくなります。 これは、グループ メンバシップに関するすべての情報がチケット内に暗号化された形で保存されることで、"意図的" に判断しにくくなるように設計されたものです。 グループ メンバシップは、チケット自体の情報ではなく、ディレクトリ サービス内の情報を使用して判断する必要があります。

Kerberos 認証

サーバー/ドメイン分離の設計では、IKE 認証に Kerberos バージョン 5 プロトコルが使用されています。 Kerberos プロトコルは正常なネットワーク接続と DNS およびドメイン コントローラによるサービスを必要とするため、接続が失われた場合、Kerberos 認証と IKE は失敗します (IKE は Kerberos 自体に障害が発生した場合も失敗します)。したがって、コンピュータ A とコンピュータ B の間の接続は、Kerberos プロトコルをドメイン コントローラで認証できないためにコンピュータ A とコンピュータ C の間のネットワーク接続がブロックされた場合、問題が発生する可能性があります。 このような状況では、通常は Windows 監査の 547 イベントとセキュリティ ログの情報を参照すると、問題の原因を探るための貴重なガイダンスになります。

IPsec で保護された受信トラフィックの必要性

このサーバー/ドメイン分離ソリューションでは、受信アクセスに IPsec で保護された通信を使用するように指定されています。 この要件により、信頼されていないコンピュータ上で動作するリモート監視ツールや専用のネットワーク監視デバイスは、リモート コンピュータと通信できない状態になります。 これらのコンピュータやデバイスは、"信頼された" 環境に参加できなければ、設計に特定の適用除外項目をいくつか追加しない限り、監視の役割を実行できません。 IPsec では信頼されたホストと接続を確立する必要があるため、トラブルシューティングは複雑になります。つまり、管理者は信頼されたホストに接続して、接続を切断しないままで IPsec サービスを停止することができません。 管理者の IPsec ポリシーによってクリアテキストへのフォールバックが許可されている場合は、リモート コンピュータ上のサービスを停止してから 3 秒か 4 秒の遅延がリモート接続で発生する可能性があります。 ただし、リモート コンピュータ上で IPsec サービスを停止すると、現在接続されている他のすべてのコンピュータが使用している IPsec SA が削除されます。 他のコンピュータがクリアテキストへのフォールバックを実行できない場合、通信が停止し、TCP 接続は最終的にタイムアウトになります。 TCP 通信が突然切断されるとアプリケーションでデータが破損する可能性があるため、IPsec サービスを停止するという手段は、トラブルシューティング プロセスで最後に選択する手段としてのみ使用してください。 IPsec サービスを停止する前に、コンピュータをシャットダウンする準備をして、接続しているすべてのユーザーとアプリケーションが正常に通信を終了できるようにする必要があります。

通信の方向に関する問題

ある方向の通信は正常なのに逆方向の通信は失敗するというのが、よくあるトラブルシューティングのシナリオです。 IKE 認証では通常、コンピュータ間の相互認証が必要です。 リモート コンピュータの IKE メイン モードを開始したときに一方のコンピュータが Kerberos チケットを取得できない場合、IKE は失敗します。 この問題は、開始側コンピュータの Kerberos クライアントが宛先コンピュータのドメイン内にあるドメイン コントローラにアクセスできない場合に発生します。 コンピュータが相互に信頼 (双方向に信頼) されていないドメインのメンバである場合、IKE メイン モード ネゴシエーションは、一方のコンピュータが開始したときは成功し、もう一方のコンピュータが開始したときは失敗します。 同様に、受信ネットワーク ログオン権限は、2 台のコンピュータで異なる場合があります。 そのため、一方向で行われる IKE メイン モードおよびクイック モードのネゴシエーションは失敗する可能性があります。また、双方の IPsec ポリシー設計に互換性がない場合も失敗する可能性があります。

IPsec 層の上位層のトラフィックを遮断するホストベースのファイアウォールでは、接続方向を強制的に適用できます。 ホストベースのファイアウォールの中には、IPsec 層の下位層のトラフィックを遮断するものもあります。 IPsec 通信が正常に確立されると、IPsec で保護されたトラフィックは、一定期間、両方向で通信を許可されると考えられます。

ネットワーク ルーターまたはファイアウォールが行うステートフル フィルタリングを使用しても、ICMP などの他の診断プロトコルに影響を与えずに、IKE キー更新操作または IPsec トラフィック フローをブロックすることができます。 TCP および UDP ポートは、一方のコンピュータではアクセスできません。これは、サービスが稼動していないか、または IPsec 層の上位層で機能するデバイス (Windows ファイアウォールやネットワーク ルーターなど) がアクセスをブロックしているためです。

ネットワーク トレースと高度なネットワーク パスのトラブルシューティング

IKE ネゴシエーションで障害が発生すると、多くの場合、障害が発生したコンピュータは IKE ネゴシエーションに応答しなくなります。または場合によっては、再試行の上限回数に達するまで直前の "正常な" メッセージを再送信します。 IKE では、Kerberos チケットを含む断片化された UDP データグラムを送信できる必要があります。これは、このようなパケットが宛先 IP アドレスで指定されているパスの最大転送単位 (PMTU) を超えることが多いためです。 断片化が適切にサポートされていない場合、断片が特定のパス上にあるネットワーク デバイスでドロップされることがあります。 さらに、IPsec プロトコル パケットまたは IPsec パケットの断片がネットワークによって正しく渡されないことがあります。 IPsec を TCP と統合すると、IPsec ヘッダーのオーバーヘッドに対応するように TCP でパケット サイズを縮小することができます。 ただし、TCP ハンドシェイク時の最大断片サイズ (MSS) の TCP ネゴシエーションでは、IPsec オーバーヘッドは考慮されません。 結果的に、IPsec で保護された TCP 通信を正常に行うためのネットワーク内の ICMP PMTU 検索の要件が高くなります。 したがって、接続に関する問題のトラブルシューティングでは、通信の両端でログを取るだけでなく、通信の一方または両端のネットワーク トレースを行う必要があります。

テクニカル サポート エンジニアは、ネットワーク トレースの読み取り方法と IKE ネゴシエーションについて理解しておく必要があります。 サーバーには、Windows Network Monitor ソフトウェアをインストールします。 Windows 2000 Network Monitor を使用すると、IPsec AH および IKE の解析を実行できます。 Windows Server 2003 では、さらに IPsec ESP-null の解析、暗号化がオフロードされたときの ESP の解析、NAT トラバーサルで使用される UDP-ESP カプセル化の解析がサポートされています。

トラブルシューティング ツールキット

トラブルシューティングを開始する前に、トラブルシューティング プロセスに役立つ情報を抽出するユーティリティを確認しておくことをお勧めします。 このセクションには、Windows 2000、Windows XP、または Windows Server 2003 のヘルプと重複する情報は記載されていません。また、Microsoft Windows Server™ 2003 Web サイトの「Troubleshooting tools」(英語) と重複する情報も記載されていません。

ここには、「Troubleshooting tools」ページにまだ記載されていない詳細なツール情報、または要約しておくとオペレーティング システムの全バージョンで役に立つ情報のみが記載されています。

[IP セキュリティ ポリシーの管理] MMC スナップイン

[IP セキュリティ ポリシーの管理] MMC スナップインを使用すると、ローカル IPsec ポリシーまたは Active Directory に格納する IPsec ポリシーを作成および管理できます。 また、リモート コンピュータで IPsec ポリシーを変更することもできます。 [IP セキュリティ ポリシーの管理] MMC スナップインは、Windows Server 2003、Windows XP、Windows 2000 Server、および Windows 2000 Professional オペレーティング システムに搭載されています。このスナップインを使用すると、IPsec ポリシーの詳細、フィルタ、フィルタ一覧、フィルタ操作を表示および編集することができます。また、IPsec ポリシーの割り当ておよび割り当て解除を行うこともできます。

[IP セキュリティ モニタ] MMC スナップイン

[IP セキュリティ モニタ] MMC スナップインを使用すると、IPsec の統計情報とアクティブな SA を表示できます。 また、次の IPsec コンポーネントに関する情報を表示することもできます。

このスナップインは Windows XP および Windows Server 2003 オペレーティング システムの一部ですが、Windows XP バージョンと Windows Server 2003 バージョンでは機能とインターフェイスが異なります。 また、Windows Server 2003 バージョンには、次の機能が追加されています。

このスナップインに対応した Windows XP 用の更新プログラムは、マイクロソフト サポート技術情報 818043「Windows XP および Windows 2000 用 L2TP/IPSec NAT-T 更新プログラム」 で紹介されている更新プログラムの一部として入手できます。 この更新プログラムを適用すると、Windows XP コンピュータで Windows Server 2003 コンピュータを表示できるようになります。 更新された [IP セキュリティ モニタ] MMC スナップインでは、Windows Server 2003 で作成された高度な機能 (Diffie-Hellman 2048 グループ情報、証明書マッピング、動的フィルタなど) を読み取ることはできますが、編集することはできません。 詳細については、上記の記事を参照してください。

Netsh

Netsh は、ネットワーク構成を表示または変更できるようになるコマンドライン スクリプト実行ユーティリティです。 Netsh は、ローカルまたはリモートのいずれかで使用できます。 Windows 2000、Windows XP、および Windows Server 2003 で利用できますが、 Windows Server 2003 バージョンでは、IPsec の診断および管理を実行できるように機能が強化されています。 IPsec 用の Netsh コマンドは、Windows Server 2003 でしか使用できません。Windows XP では Ipseccmd が、Windows 2000 では Netdiag がこれに対応します。

Ipseccmd

Ipseccmd は、[IP セキュリティ ポリシーの管理] MMC スナップインの代替となるコマンドライン ツールです。 このツールは Windows XP でしか使用できません。また、Windows XP Service Pack 2 では、このツールにさらに機能が追加されています。

Ipseccmd は、Windows XP CD の Support Tools フォルダからインストールしてください。 Windows XP SP2 では内容が一部更新されているため、Windows XP SP2 CD の Support Tools フォルダからインストールします。 SP2 以前のバージョンは、更新されたコンピュータでは動作しません。また、更新されたバージョンは SP2 以前のコンピュータでは動作しません。

更新された Ipseccmd ユーティリティには次のような機能があります。

更新された Ipseccmd ユーティリティの詳細については、前述のマイクロソフト サポート技術情報 818043 を参照してください。

診断に使用するために、すべての IPsec ポリシー設定と統計情報を表示するには、次の構文を使用します。

ipseccmd show all

現在割り当てられているアクティブな IPsec ポリシー (ローカルまたは Active Directory) を表示するには、次の構文を使用します。

ipseccmd show gpo

注 : このコマンドは SP2 バージョンでのみ機能します。

Windows XP SP2 でデバッグのログ記録を有効にするには、次の構文を使用します。

    ipseccmd set logike  (IPsec サービスを再起動する必要はありません)

デバッグのログ記録を無効にするには、次の構文を使用します。

    ipseccmd set dontlogike  (この場合も IPsec サービスを再起動する必要はありません)

注 : Ipseccmd は、Windows XP SP2 の Oakley ログ記録を有効にする場合のみ使用できます。上記のコマンドは SP2 以前のコンピュータでは機能しません。

Netdiag

Netdiag は、IPsec 情報を含むネットワーク接続と構成をテストするために使用するコマンドライン診断ツールです。 Netdiag は、Windows 2000、Windows XP、および Windows Server 2003 で使用できますが、利用できる機能はオペレーティング システムのバージョンによって異なります。 Windows Server 2003 では、Netdiag に IPsec 用の機能は含まれていません。代わりに一連の netsh ipsec コマンドを使用できます。また、Netsh で基本的なネットワーク テストを行うこともできます。 どのオペレーティング システムのバージョンの場合も、最新バージョンを使用することが重要です。これについては、Microsoft ダウンロード センターで確認してください。 Netdiag は、どの Windows オペレーティング システムの場合も、CD 内の Support Tools フォルダからインストールします。

注 : Netdiag は、Windows XP SP2 をインストールしても更新されません。

IPsec のトラブルシューティングに Netdiag を使用することが適切かどうかは、オペレーティング システムのバージョンによります。 次の表は、機能上の相違点をまとめたものです。

表 7.1: オペレーティング システム別の Netdiag の IPsec 用機能

* ネットワーク診断を実行できますが、IPsec ポリシー名しか表示されません。 その他の IPsec 情報を表示するには、Ipseccmd を使用します。

** ネットワーク診断を実行できますが、IPsec 情報は表示されません。 情報を表示するには、代わりに「netsh ipsec dynamic show all」という構文を使用します。

IPsec をサポートするその他の便利なツール

次の表は、上述の IPsec 固有のツール以外の、トラブルシューティングに使用でき第 2 層のトラブルシューティング ツールキットに含める必要のあるその他のツールをまとめたものです。

表 7.2: IPsec のトラブルシューティングに役立つその他のツール

IPsec で ICMP ベースのツールを使用する

Windows XP および Windows Server 2003 の Ping、Pathping、および Tracert は IPsec を認識しますが、ソフト SA が確立されるまでは正常に機能しない場合があります (クリアテキストへのフォールバックが有効な場合)。 これらのユーティリティで使用される ICMP トラフィックをカプセル化するように IPsec SA がネゴシエートされ、それが正常に完了した場合、クライアントと接続対象との間にある中間ホップ (ルーター) は検出されなくなります。 Ping で算出されるパケット損失は、IKE による IPsec SA ペアのネゴシエーションが対象コンピュータとの間で行われた場合に、それが正常に完了するまでに要する時間内で失われるパケット数を表します。 ICMP トラフィックが IPsec によりカプセル化される場合、中間ホップごとのパケット損失は算出できません。

これらの ICMP ユーティリティは、IPsec ドライバが送信 ICMP エコー要求パケットに対して IPsec フィルタを適用したか、つまり IKE によるセキュリティのネゴシエーションを要求したかどうかを検出できるように設計されています。 このネゴシエートが行われると、ユーティリティによって「IP セキュリティをネゴシエートしています。」というメッセージが表示されます。 Windows 2000 の既知のバグにより、Ping ユーティリティは十分な待ち時間を入れずに次のエコー要求を再試行します。そのため、ソフト SA が確立されるまでの 3 秒の待ち時間はなく、コマンドは直ちに完了します。 Windows XP および Windows Server 2003 の Ping ユーティリティでは、次のエコー要求が送信されるまで適切な秒数の待ち時間があります。

「IP セキュリティをネゴシエートしています。」というメッセージは、次の状況では表示されません。

ページのトップへ

IPsec のトラブルシューティング プロセス

第 1 層のサポートで問題が明確に特定されていると、第 2 層のサポートは、以降のセクションで説明するトラブルシューティング手順の中から該当するものを迅速に特定することができます。 ここで紹介するモデルでは、第 1 層のサポートは主にクライアント関連のアクセス問題を扱っています。 サーバーの管理所有者は、基本的なネットワーク接続診断を実行する能力があり、場合によっては第 1 層のサポートをスキップできると想定されています。 ただし、組織はそれぞれのサポート環境に合わせてモデルを調整してください。 第 2 層のサポートでは、通信障害が発生している箇所を特定し、次にシステムのアーキテクチャ内で関連する可能性を調査します。

組織がトラブルシューティング プロセスの一部として提供されているスクリプトを使用している場合は、問題の診断に役立つ多くのテキスト ログ ファイルにアクセスすることができます。 スクリプトが生成するファイルの内容については、次の表にまとめています。

表 7.3: IPsec_Debug.vbs スクリプトで作成されるファイル

障害が発生すると考えられる箇所は多数存在します。したがって、ここでは各アーキテクチャ コンポーネントの対応方法について順番に説明します。まず最初に、ネットワーク接続について取り上げます。 ここで紹介する手順は、次のタスクを実行する場合に役立ちます。

たとえば、クライアントからサーバーに対して ping を実行できるにもかかわらず、クライアントからサーバーのファイル共有に接続できないものとします。 このサーバーは、クライアントが接続できない唯一のサーバーです。 サーバーの IP アドレスが記録されているイベント 547 (IKE ネゴシエーションの失敗) のセキュリティ ログを参照すると、クライアントに適用されている IPsec ポリシーがあることと、IKE が開始されていることが分かります。 クライアント イベント 547 にクライアント IKE ネゴシエーションのタイムアウトが記録されている場合、サーバー IKE はネゴシエーションに失敗している可能性があります。 次に、第 2 層のサポートは、指定したサーバーから収集した 547 イベントの MOM イベント データベース (現在のクライアントの IP アドレスが記録されています) を参照します。

警告 - IPsec サービスの開始と停止

Windows Server 2003 TCP/IP トラブルシューティング ドキュメントおよびその他のリファレンスには、IPsec サービスを停止することで、IPsec が接続に関する問題の原因であるどうかを判断する手順が記載されています。 この手順を使用するとコンピュータの IPsec フィルタリングが停止しますが、同時に IPsec が提供する保護機能が無効になり、信頼されていないネットワークからのアクセスにコンピュータをさらすことにつながり、パケット保護も無効になります。 また、ドメイン分離環境では、IPsec で保護されていない TCP および UDP トラフィックは、別の分離ドメイン メンバによってドロップされます。 IPsec を 1 台のコンピュータ上で無効にすると、現在 IPsec セキュリティ アソシエーションが確立しているリモート コンピュータとの接続が切断されます。 IPsec サービスを停止すると、IKE により、すべての IPsec SA および IKE SA の削除通知が、現在接続中のすべてのコンピュータに対して送信されます。 クリアテキストへのフォールバックを許可する IPsec ポリシーが割り当てられているリモート コンピュータでは、3 秒後に接続が再確立されます。 クリアテキストへのフォールバックを許可しない IPsec ポリシーが割り当てられているリモート コンピュータでは、通信できない状態になります。

したがって、次のセクションで説明するテクニックを用いて、IPsec サービスを停止せずに分離シナリオの問題を解決することが重要です。 IPsec サービスの無効化は、次のような状況で発生した IPsec 関連の問題を公開する最後の手段としてのみ使用してください。

Windows 2000 では、IPsec サービスを停止すると IPsec ドライバが TCP/IP とのバインドから解除され、IPsec ドライバがメモリからアンロードされます。

Windows XP および Windows Server 2003 では、IPsec サービスを停止すると IPsec ドライバからすべてのフィルタが削除され、ドライバ モードが PERMIT (許可) に設定されます。 IPsec ドライバはメモリからアンロードされません。 IPsec ドライバが読み込まれないようにするには、IPsec サービスを無効にしてコンピュータを再起動する必要があります。

Windows 2000 および Windows XP SP1 では、IKE のログを Oakley.log ファイルに記録するには、IPsec サービスを再起動する必要があります。 Windows XP SP2 および Windows Server 2003 では、IKE のログを Oakley.log ファイルに記録する機能を有効/無効にする場合に、サービスを停止する必要はありません。 Windows XP SP2 の Ipseccmd を最新版に更新すると、構文
ipseccmd set logike および ipseccmd set dontlogike を使用して、IKE のログを Oakley.log ファイルに記録する機能を動的に有効または無効にすることができます。 Windows Server 2003 では、IKE のログ記録は、Netsh コマンドを使用して動的に有効にすることができます。コマンドの詳細については、オンライン ヘルプを参照してください。

ネットワーク接続を確認する

第 1 層のサポートがネットワーク接続の問題である可能性があることを特定した場合は、まず最初に、基本的なネットワーク接続が存在することを確認します。 つまり、適切な IP 構成が使用されているか、開始側コンピュータと応答側コンピュータの間に有効なネットワーク パスが存在するか、名前解決サービスが機能しているか、という点を確認します。

ネットワーク IP アドレスの構成に関する問題

動的な IP 構成がうまくいかない場合、またはコンピュータの再起動後 (または通常の操作中) に通信がブロックされる場合は、IPsec が原因である可能性があります。 Windows Server 2003 の場合は、IPsec のフェイルセーフ動作が原因で問題が発生している可能性があります (コンピュータがセーフ モードまたは Active Directory 障害回復モードで起動する場合など)。

注 : Windows Server 2003 のフェイルセーフ動作の詳細については、「Windows Server 2003 Deployment Kit」の「Deploying IPsec」にある「Understanding IPSec Protection During Computer Startup」(英語) を参照してください。

Windows Server 2003 では、IPsec サービスが正常に開始されない場合や割り当てられているポリシーを適用できない場合に、フェイルセーフ動作が使用されます。 フェイルセーフは、IPsec ポリシーがコンピュータに適用されていて、IPsec サービスが無効にされていない場合にのみ適用されます。 結果的に、IPsec ドライバによってドメインベースの IPsec ポリシーが強制的に適用されないため、通常の操作中はコンピュータとの接続に失敗します。 bootmode と永続的な構成によって許可されるトラフィックとブロックされるトラフィックが特定されれば、通信障害の解明は簡単になります。 代替情報や追加情報を取得するには、次の構文を使用してコマンド ラインから現在の状態のクエリを行います。

    netsh ipsec dynamic show config

Windows Server 2003 の場合、IPsec ドライバはコンピュータの起動時に TCP/IP ドライバと一緒に読み込まれます。 そのため、IPsec ドライバのフェイルセーフ動作を削除するには、IPsec サービスを無効にしてコンピュータを再起動する必要があります。 IPsec の展開について説明した章に、受信リモート デスクトップ プロトコル接続を除外する起動時適用除外の推奨構成が紹介されています。この構成を使用すると、他のトラフィックがブロックされているときにサーバーにリモート アクセスすることができます。

サーバー/ドメイン分離ソリューションではブロードキャスト トラフィックと DHCP サーバー宛てのトラフィックが適用除外されており、そのため動的な IP 構成が正常に動作します。 ただし、適用除外リストは手動でメンテナンスする必要があります。リストの有効期限切れに注意してください。 コンピュータが適切な DHCP 構成を取得できない場合 (169.254.x.x の自動構成 IP アドレスを使用している場合など) やリースの更新に問題がある場合は、IPsec ポリシーの適用除外リストが適切に設定されているかどうかを確認する必要があります。 IPsec サービスが稼動中の場合は、Ipconfig を次のように使用してアドレスの取得に問題がないことを確認します。

Windows XP SP2 および Windows Server 2003 の場合、アドレス構成に関する問題がコンピュータの起動時にしか発生しないときは、適用除外リストの構成 (既定の除外と起動時の除外) を調査する必要があります。

名前解決に関する問題

サーバー/ドメイン分離シナリオで使用する IPsec ポリシーを設計する場合は、名前解決が機能しているかどうかを確認する一般的な手順を妨げないように作成する必要があります。 たとえば、Woodgrove Bank シナリオの IPsec ポリシー設計では、DNS サーバーおよび WINS サーバーに送信されるすべてのトラフィックが除外されています。 ただし、DNS サーバーおよび WINS サーバーが Ping 要求に応答しないように構成することは可能です。 IPsec サービスの実行中に名前解決が正常に機能していることを確認するには、次の確認事項をチェックしてください。

名前解決に関する問題の原因としては、アクティブな HOSTS ファイルの構成ミス、IP プロパティ内の DNS サーバー エントリの構成ミス、DNS 記録登録の誤り、ゾーン ファイルの更新に関する問題、Active Directory の複製に関する問題、DNS サーバーでのクリアテキストへのフォールバックの実行、DHCP の自動更新に関する問題などが考えられます。

NetBIOS 名前解決に関する問題の原因としては、アクティブな LMHOSTS ファイルの構成ミス、IP プロパティ内の WINS サーバー エントリの構成ミス、WINS サーバーが使用できない、WINS 記録の誤り、WINS の複製に関する問題、WINS プロキシ障害、WINS サーバーに到達するまでのネットワーク タイムアウトなどが考えられます。

Active Directory が統合されている DNS のトラブルシューティング手順については、マイクロソフト Web サイトの「Troubleshooting Active Directory - Related DNS Problems」(英語) を参照してください。

高いセキュリティが求められる一部の環境では、DNS サーバーと WINS サーバーを IPsec で保護しなければならない場合があります。そのような場合、名前解決で問題が発生します。 たとえば、DNS が Active Directory 内に統合され、IPsec ポリシーに同じ IP アドレスの複製フィルタが存在する場合、一方のフィルタでは DNS サーバーに対してセキュリティのネゴシエーションが行われ、もう一方のフィルタではドメイン コントローラが適用除外されるということも考えられます。 詳細については、この章で後述する「IPsec ポリシーのトラブルシューティングを行う」を参照してください。

名前解決に関する問題が解消されない場合は、開始側コンピュータからフィルタ一覧を取得して複製フィルタかどうかを確認します。 この作業を行うためにフィルタ一覧を表示するには、次のコマンド ライン オプションを使用します。

Ipseccmd show filters
Netsh ipsec static show all 

それでも名前解決に関する問題が解消されない場合は、可能であれば IPsec サービスを一時的に停止して、名前解決のテストを繰り返します。 IPsec サービスの実行中にのみ名前解決のテストが失敗する場合は、このセクションで後述する手順に従って検証を続け、割り当てられている IPsec ポリシーを確認します。

ドメイン コントローラでの接続と認証を確認する

IPsec ポリシーの配布や IKE 認証、およびほとんどの上位層のプロトコルはドメイン コントローラへのアクセスに依存しているため、IPsec 固有のトラブルシューティング手順 (次のセクションを参照) を実行する前に、ネットワーク接続をテストして認証サービスが正常に運用されることを確認する必要があります。 Woodgrove Bank などのシナリオでは、すべてのドメイン コントローラに送信されるすべてのトラフィックが IPsec ポリシーの設計で適用除外されています。このため、ドメイン コントローラに対するネットワーク接続のテストは、IPsec による影響を受けません。 ただし、適用除外リストに含まれるドメイン コントローラの IP アドレス リストは、手動でメンテナンスする必要があります。 ドメイン コントローラ IP アドレスに対して IKE ネゴシエーションが行われる場合、IPsec ポリシーは誤って割り当てられるか、更新されない可能性があります。

Active Directory のネットワーク サービスへのアクセスのトラブルシューティングを行うには

Windows サポート ツールの klist.exe を使用すると、正常な Kerberos ログインと認証が行われたかどうかを確認できます。 コンピュータの Kerberos チケットを表示するには、ローカル システム環境で Klist を実行する必要があります。

ログインしたドメイン ユーザーの Kerberos サービス チケットを表示するには

klist tickets

ドメイン コンピュータ チケットを表示するには

at 4:38pm /interactive cmd /k klist tickets

Kerberos チケットにはユーザーまたはコンピュータのグループ情報が格納されていますが、この情報は暗号化されているため、グループは表示されません。 したがって、グループ メンバシップを確認するには、Active Directory のグループ メンバシップを手動で調査する必要があります。 Kerberos チケットを更新して最新のグループ メンバシップ情報をコンピュータに反映させるには、klist を使用して現在の Kerberos チケットを削除します。 IKE ネゴシエーションを再度試行すると、新しい Kerberos チケットが自動的に取得されます。

コンピュータの Kerberos チケットを削除するには

(手順 1 ～ 4 はローカル システム環境で実行する必要があります)

at 4:38pm /interactive cmd

Kerberos のトラブルシューティングを行う場合のその他の手順の詳細は、次のホワイト ペーパーに記載されています。

Active Directory の IPsec ポリシーの許可と整合性を確認する

Active Directory の IPsec ポリシー コンテナに関する情報の確認が必要になる場合があります。 次の手順では、サポート ツールの ldp.exe を使用します。

IPsec ポリシー コンテナに関する情報を確認するには

ldp.exe を使用して IP セキュリティ コンテナの内容と IPsec �