英語で読む

次の方法で共有


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

第 7 章 : IPsec のトラブルシューティング

最終更新日: 2005年5月30日

この章では、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 層 : ヘルプデスク : ヘルプ デスクは、ドメイン参加クライアントとドメイン非参加クライアントに関する問題を最初にサポートするところです。 ここではまた、中央の IT 組織が管理しているサーバーのサポートも行います (サーバーによっては、業務アプリケーション チームまたは製品グループが管理している場合もあります)。 ヘルプ デスクのスタッフ メンバは、分類学と複数のフローチャートを使用してサーバー/ドメイン分離に関する問題を分類できるように、研修を受ける必要があります。

    マイクロソフトの分離ソリューションのパイロット フェーズでは、クライアントに関する問題は企業 IT セキュリティ部門にエスカレートされていましたが、 ソリューションの運用展開後は、クライアントに関する問題は第 2 層のサポート チームが処理するようになりました。

  • 第 2 層 : データ センター運用、グローバル ネットワーク運用センター、業務アプリケーション サポート、メッセージング/コラボレーション サポート : このグループは、IT サービスおよび関連資産の監視と管理を日常業務とするチームです。 サーバー/ドメイン分離のパイロットでは、これらのチームが、サーバー関連の問題とトラブルシューティングを担当するヘルプ デスクおよび企業 IT セキュリティ部門の最初のエスカレーション先でした。 各グループには、サーバー/ドメイン分離に関する特定の専門知識を持った担当者と、トラブルシューティングに関する詳細な手順を用意する必要があります。

  • 第 3 層 : Windows ネットワーク サービスおよびインフラストラクチャ サービス : サーバー/ドメイン分離のパイロット フェーズでは、IPsec、TCP/IP パケット処理、コンピュータ アカウント、ネットワーク ログオン権限など、ソリューション関連のアーキテクチャ コンポーネントやテクノロジに関する問題を専門に解決するチームを特定する役割を、このグループが果たしました。 マイクロソフトの内部では、さらにエスカレーションが必要になった場合、第 3 層が Windows 開発チームと共同で直接作業を進めて問題を解決します。 マイクロソフトの外部では、第 3 層は必要に応じて、マイクロソフト製品サポート サービスと共同で作業を進めます。

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

ページのトップへ

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

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

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

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

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

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

  • ネットワーク接続 : Internet Control Message Protocol (ICMP) メッセージの pingtracert を使用して、ネットワーク パスをテストします。

  • 名前解決 : ping<宛先名> と nslookup を使用します。

  • アプリケーション : 接続先が同じでも、一部のアプリケーション (net view など) は動作し、他のアプリケーションは動作しない場合があります。

  • サービス : たとえば、L2TP に対して矛盾する自動 IPsec ポリシーを作成する Routing and Remote Access (RRAS) サービスをサーバーが実行しているかどうかを確認します。

  • 連絡者のコンピュータ : 連絡者のコンピュータが、ヘルプ デスクのテストおよび診断用の任意のホスト コンピュータまたは特定の信頼済みホスト コンピュータにアクセスできるかどうかを確認します。

  • 対象コンピュータ : 連絡者のコンピュータが、ヘルプ デスクのすべてのテスト用コンピュータにアクセスでき、特定のコンピュータにだけアクセスできない状態であるかどうかを確認します。

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

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

範囲と深刻度の割り当て

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

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

  • コンピュータ特有の問題 : IPsec で保護されている通信では、インターネット キー交換 (IKE) コンピュータ相互認証が必要になります。 通信を開始するコンピュータと通信に応答するコンピュータは、有効なドメイン アカウントを持ち、そのドメインのドメイン コントローラにアクセスできる必要があります。 また、IPsec ポリシーの割り当てとネットワーク アクセス制御は、正しいドメイン グループに属するコンピュータ アカウントよって決まります。 IPsec の動作に影響を与える可能性があるコンピュータ特有の問題として、他に次のようなものがあります。

    • オペレーティング システムに適切なサービス パック、更新プログラム、またはレジストリ キー構成が適用されていない。

    • コンピュータに特定のソフトウェアがインストールされているか、特定のサービスが稼動している。

    • ネットワーク接続に特定の IP アドレスが使用されているか、通信に特定のネットワーク パスが使用されている。

    上に挙げたような問題点があると、一部のコンピュータでは接続に問題が発生し、他のコンピュータでは問題なく接続できるという状況が発生することがあります。

    注 : この章に登場する IPsec トラブルシューティング ツールはすべて、ローカルの管理者グループ権限を必要とします。

  • ネットワーク ロケーションとパス特有の問題 : サーバー/ドメイン分離ソリューションまたはその他の IPsec の広域展開では、すべての TCP および UDP トラフィックがカプセル化されます。 したがって、パス上のネットワーク デバイスには、IKE、IPsec、および ICMP プロトコルしか表示されません。 発信元と宛先の間でこの 3 つのプロトコルの転送にネットワーク上の問題が発生した場合、2 台のコンピュータの間の通信がブロックされる可能性があります。

  • ユーザー特有の問題 : サーバー/ドメイン分離シナリオなどで IPsec を展開すると、ドメイン ユーザーのネットワーク ログオン権限に影響を与える可能性があります。 たとえば、ネットワーク アクセスが承認されているグループに属していないユーザーだけに問題が発生するとか、承認されたユーザーが適切なグループ メンバシップを含む Kerberos 認証資格情報を取得できない場合があります。 ドメイン、ローカル ユーザー、サービス アカウントの間で動作が異なる場合もあります。

企業での一般的な 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 ポリシーの更新によって問題は解決しましたが、間違ったポリシーが適用された理由、あるいはポリシーが全然適用されなかった理由を特定できない状態などです。

  • 未修正 : 問題は未解決のままですが、問題を第 2 層のサポートにエスカレートすれば問題を特定できる可能性がある状態を示します。  

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

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

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

  • 適用除外リストのメンバ : 適用除外リスト フィルタの IP アドレスのリストは、信頼されているホストのローカル管理者であれば、[IP セキュリティ モニタ] MMC スナップインを使用するかローカル レジストリのドメイン IPsec ポリシー キャッシュを閲覧して入手できる可能性があります。 さらに、組織で使用されているセキュリティ設定によっては、管理者以外のユーザーがキャッシュの読み取りアクセスを許可されている場合があります。 ドメイン分離が完全に実装されると、攻撃者はネットワークをスキャンして、TCP および UDP 接続要求に応答できる適用除外対象のコンピュータを検出する必要があります。 DNS サーバー、DHCP サーバー、および WINS サーバーは、DHCP 構成から簡単に特定でき、ドメイン コントローラも、DNS クエリや UDP Light Directory Access Protocol (LDAP) クエリを利用すれば簡単に場所を特定できるため、注意が必要です。

  • 分離ソリューションに参加していない組織内のコンピュータ : たとえば、特定のドメインやサーバー タイプがソリューションから漏れている場合があります。

  • サーバー分離を使用しているコンピュータまたはマシンベースのアクセス制御を必要とするコンピュータ : 最高の機密情報を格納しているサーバーには、通常、最もセキュリティの高い保護対策を適用します。

  • 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

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

  • オペレーティング システムのバージョンの検出

  • Detect_IPsec_Policy.vbs の呼び出し

  • グループ ポリシー ログ記録の増加

  • Kerberos バージョン 5 認証プロトコル ログ記録の増加

  • 現在の Kerberos プロトコル チケットの削除

  • グループ ポリシーの更新

  • IPsec ログ記録の有効化

  • PING および SMB (Net View) テストの実行

  • IPsec ファイル バージョンの検出

  • ポリシーおよびネットワーク診断テストの実行

  • IPsec 547 イベントのテキスト ファイルへのコピー

  • IPsec ログ記録の無効化

  • Kerberos プロトコル ログ記録の復元

  • グループ ポリシー ログ記録の復元

このスクリプトを使用すると、第 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 層で次の情報を収集し、サービス要求とともに提供する必要があります。

  • IPsec_Debug.vbs スクリプトで生成されたログ ファイル。

  • 連絡者のコンピュータ名。スクリプトで生成されたログ ファイルを次のサポート層が特定するために必要になります。

  • アクセスを拒否した宛先コンピュータ。エスカレーションを適切なサポート グループに割り当てるために必要になります。

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

ページのトップへ

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

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

第 2 層のサポート スキル

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

  • グループ ポリシー : 割り当てる必要のあるポリシーとその割り当て方法についての知識があり、次のタスクを実行できる。

    • グループ ポリシー オブジェクト (GPO) のアクセス制御リスト (ACL) のチェック。

    • GPO の設定のチェック。

    • コンピュータとユーザーのグループ メンバシップのチェック。

  • 組織で使用されているサードパーティ ソフトウェアに関する経験

  • 認証の失敗を特定する

    • netdiag および nltest ユーティリティを使用して、ドメイン コンピュータ アカウントが正常であることを確認できる。
  • IPsec 構成 : 次のタスクを実行できる。

    • IPsec フィルタ構成の検証。

    • IPsec ドメイン ポリシーの再読み込み。

    • テスト用のローカル ポリシーを使用するための、完全な IPsec の無効化またはドメイン ポリシーのみの無効化。

    • IPsec IKE ネゴシエーション プロセスとセキュリティ プロトコルのトラブルシューティング。

  • ネットワーキング : 次のタスクを実行できる。

    • ホスト マシンのネットワーク プロトコル スタックのトラブルシューティング。

    • ネットワーク トレースで収集された情報の把握とトラブルシューティング。

    • TCP パス MTU 検索や仮想プライベート ネットワーク (VPN) リモート アクセス ソリューションなど、ネットワーク パスに関する問題のトラブルシューティング。

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 コンポーネントに関する情報を表示することもできます。

  • IKE メイン モードおよびクイック モード

  • ローカルまたはドメイン IPsec ポリシー

  • コンピュータに適用する IPsec フィルタ  

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

  • アクティブな IPsec ポリシーの詳細情報 (ポリシー名、説明、最終変更日、保存場所、パス、OU、グループ ポリシー オブジェクト名など) を表示できます。 Windows XP で同じ情報を取得するには、IPseccmd コマンドライン ツールを使用する必要があります (これについては、このセクションで後述します)。

  • メイン モードとクイック モードの統計情報を別々に表示できます。1 画面に表示されるのではなく、各モードに対応するフォルダ内で表示されます。

    注 : Windows 2000 では、IP セキュリティ モニタは独自のグラフィカル ユーザー インターフェイス (GUI) を備えたスタンドアロンの実行プログラム (IPsecmon.exe) です。 このツールの内容と使用方法については、マイクロソフト サポート技術情報 257225「Windows 2000 での IPSec の基本的なトラブルシューティング」を参照してください。

このスナップインに対応した 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 ユーティリティには次のような機能があります。

  • IKE ログ記録のオン/オフを動的に切り替えることができます。

  • 現在割り当てられているポリシーに関する情報を表示できます。

  • 継続 IPsec ポリシーを作成できます。

  • 現在割り当てられているアクティブな IPsec ポリシーを表示できます。

更新された 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 用機能

コマンド 説明 Windows 2000 Windows XP Windows 2003
netdiag
/test:ipsec
割り当てられている IPsec ポリシーを表示します 利用可 利用可 利用不可**
netdiag
/test:ipsec
/debug
アクティブな IPsec ポリシー、フィルタ、クイック モードの統計情報を表示します 利用可 利用可* 利用不可**
netdiag
/test:ipsec
/v
アクティブな IPsec ポリシー、フィルタ、メイン モードの統計情報を表示します 利用可 利用可* 利用不可**
* ネットワーク診断を実行できますが、IPsec ポリシー名しか表示されません。 その他の IPsec 情報を表示するには、Ipseccmd を使用します。 ** ネットワーク診断を実行できますが、IPsec 情報は表示されません。 情報を表示するには、代わりに「netsh ipsec dynamic show all」という構文を使用します。 ##### IPsec をサポートするその他の便利なツール 次の表は、上述の IPsec 固有のツール以外の、トラブルシューティングに使用でき第 2 層のトラブルシューティング ツールキットに含める必要のあるその他のツールをまとめたものです。 **表 7.2: IPsec のトラブルシューティングに役立つその他のツール**

ツール サポートしているオペレーティング システム 取得方法 役割 詳細情報
Ipsecpol.exe Windows 2000 のみ Windows 2000 Resource Kit ディレクトリまたはレジストリで IPsec ポリシーを構成します Windows 2000 リソース キット ツールのヘルプ
Gpresult Windows 2000、Windows Server
2003、Windows XP
Windows 2000 の場合は Resource Kit。Windows XP および Windows Server
2003 の場合は、オペレーティング システムに搭載済み。
グループ ポリシーが最後に適用された日時をチェックします Windows 2000 リソース キット ツールのヘルプ、Windows XP および Windows Server
2003 のヘルプ
[ポリシーの結果セット (RSoP)] MMC
スナップイン
Windows Server
2003、Windows XP
オペレーティング システムの一部として搭載済み コンピュータまたはグループ ポリシー コンテナのメンバの IPsec ポリシーを表示します Windows Server
2003 のヘルプ
Srvinfo Windows 2000、Windows Server
2003、Windows XP
Windows 2000 および Windows Server
2003 リソース キット
サービス、デバイス ドライバ、およびプロトコルに関する情報 Windows Server
2003 リソース キット ツールのヘルプ
PortQry Windows 2000、Windows Server
2003、Windows XP
Windows Server
2003 リソース キット
ネットワーク ポートのステータスに関するレポートを作成します https://support.

microsoft.com/

kb/310099
NLTest Windows 2000、Windows Server
2003、Windows XP
サポート ツール 信頼関係と Netlogon セキュア チャンネルをテストします Windows Server
2003 サポート ツールのヘルプ
Klist Windows 2000、Windows Server
2003、Windows XP
Windows 2000 および Windows Server
2003 リソース キット
Kerberos チケットに関するレポートを作成します Windows Server
2003 リソース キット ツールのヘルプ
Pathping Windows 2000、Windows Server
2003、Windows XP
オペレーティング システムの一部として搭載済み ネットワークの接続とパスをテストします Windows のヘルプ
LDP Windows 2000、Windows Server
2003、Windows XP
サポート ツール Active Directory の LDAP クライアントをテストします Windows Server
2003 サポート ツールのヘルプ
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 ドライバが、ブロック フィルタにより送信 ICMP パケットをドロップする場合。

  • IPsec ドライバが、許可フィルタまたはソフト SA によりセキュリティ保護されないままの状態の ICMP パケットの通過を許可する場合。

  • IPsec ドライバが、送信パケットを検出しない場合 (IPsec ドライバの上位層で既にドロップされた場合など)。

    注 : ICMP を使用する一部のツールは、IPsec がセキュリティをネゴシエートしていることを検出できないため、矛盾した結果や誤った結果を生成する場合があります。

ページのトップへ

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

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

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

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

ファイル名 説明
<コンピュータ名>_FileVer.txt さまざまな IPsec 関連の DLL ファイルのバージョンを一覧表示したもの。
<コンピュータ名>_gpresult.txt gpresult コマンドの出力。
<コンピュータ名>_ipsec_547_events.txt セキュリティ イベント ログの任意の IPSEC 547 エラーの出力。
<コンピュータ名>_ipsec_policy_version.txt Detect_IPsec_Policy.vbs スクリプトの出力。 コンピュータ上の現在のポリシー バージョンと、それが Active Directory のポリシーと一致しているかどうかを表示します。
<コンピュータ名>_ipseccmd_show_all.txt Windows XP でのみ使用可能。 ipseccmd コマンドの出力をキャプチャしたファイルです。
<コンピュータ名>_kerberos_events.txt システム イベント ログの任意の Kerberos イベントの出力。
<コンピュータ名>_klist_purge_mt.txt マシン チケットの削除中に KList から出力されるファイル。
<コンピュータ名>_lsass.log lsass.log ファイルのコピー (存在する場合)。
<コンピュータ名>_netdiag.txt netdiag を実行すると出力されるファイル。
<コンピュータ名>_netsh_show_all.txt サーバー プラットフォームでのみ使用可能。 netsh の show all コマンドからの出力。
<コンピュータ名>_netsh_show_gpo.txt サーバー プラットフォームでのみ使用可能。 netsh の show gpo コマンドからの出力。
<コンピュータ名>_oakley.log Oakley.log ファイルのコピー (存在する場合)。
<コンピュータ名>_OSInfo.txt 現在のオペレーティング システム情報の出力。
<コンピュータ名>_RegDefault.txt 変更前の元のレジストリ キー値の出力。 スクリプトが何らかの理由で失敗した場合に、レジストリを以前の値に手動で復元できます。
<コンピュータ名>_userenv.log userenv.log ファイルのコピー (存在する場合)。
<コンピュータ名>_<サーバー名>_netview.txt <サーバー名> に対する net view コマンドの出力。
<コンピュータ名>_<サーバー名>_ping.txt <サーバー名> に対する ping コマンドの出力。
<コンピュータ名>_winlogon.log winlogon.log ファイルのコピー (存在する場合)。
障害が発生すると考えられる箇所は多数存在します。したがって、ここでは各アーキテクチャ コンポーネントの対応方法について順番に説明します。まず最初に、ネットワーク接続について取り上げます。 ここで紹介する手順は、次のタスクを実行する場合に役立ちます。 - IP ネットワーク構成、ドメイン コントローラを使用したネットワーク接続およびサービス、および IPsec 関連のプロトコルに対応したクライアント/サーバー パス接続を確認する。 - クライアントとサーバーの両方で、グループ ポリシーと IPsec ポリシーが正しく適用されていることを確認する。 - IKE ネゴシエーションと IPsec で保護された通信に関する問題を調査する。 - 必要に応じて、第 3 層にエスカレートする問題の原因を特定する。   たとえば、クライアントからサーバーに対して 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 関連の問題を公開する最後の手段としてのみ使用してください。 - ブロードキャストおよびマルチキャスト トラフィック環境 - 送信アクセスで 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](https://technet2.microsoft.com/windowsserver/en/library/10091c6e-fca2-478d-bdae-ddd11d0739c71033.mspx)」(英語) を参照してください。 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 を次のように使用してアドレスの取得に問題がないことを確認します。

  • DHCP クライアントの場合は、コマンド ウィンドウを開いて ipconfig /release を実行し、続けて ipconfig /renew を実行します。

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

名前解決に関する問題

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

  • クライアントから IP 構成に登録されている DNS サーバーの IP アドレスに対して ping を実行できるか。

  • nslookup で DNS サーバーを検出できるか。

  • クライアントから対象コンピュータの完全修飾 DNS 名に対して ping を実行できるか。

  • クライアントから対象コンピュータの省略 DNS 名または NetBIOS 名に対して ping を実行できるか。

名前解決に関する問題の原因としては、アクティブな 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 のネットワーク サービスへのアクセスのトラブルシューティングを行うには

  • クライアントから各ドメイン コントローラの IP アドレスに対して ping を実行できることを確認します。 実行できない場合は、上記のネットワーク接続の手順を参照してください。

  • ドメイン メンバのドメイン コントローラで使用されている IP アドレスを特定します。 nslookup <ドメイン名> を使用して、IP アドレスの完全なリストを取得します。 サーバー/ドメイン分離シナリオでは、この各アドレスに対応する、permit (許可) のネゴシエーション ポリシー (フィルタ操作) を含むクイック モード専用のフィルタを用意します

  • portqry.exe ツールまたは PortQueryUI ツールのバージョン 2.0 以降を使用して、ドメイン コントローラの UDP、LDAP、および RPC ポートに対するアクセスをテストします。 portqry で使用される UDP プロトコル メッセージは、通常、上位層のプロトコル認証を必要としません。そのため、認証を利用できない場合でもサービスの可用性を確認できます。 この手順については、「[HOWTO] Portqry を使用して Active Directory の接続の問題をトラブルシューティングする方法」を参照してください。

  • 内部ネットワークとの接続が完了したら、netdiag /v >outputfile.txt を使用して、多数ある DNS 関連およびドメイン コントローラ関連の接続テストを実行します。 Netdiag では、テストを実行するために複数のネットワーク接続とプロトコルを使用します。これらの接続のいずれかによって IKE ネゴシエーションが起動し、IKE が Kerberos 認証用のドメイン コントローラを検出できないために認証に失敗した場合は、イベント 547 障害エラーがセキュリティ ログに記録されます。

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

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

  • コマンド プロンプトを開き、次のように入力します。

    klist tickets

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

  1. タスク スケジューラ サービスが実行されており、ログオンしたユーザーが Local Administrators グループのメンバであることを確認します。

  2. コマンドライン プロンプトで、現在のシステム時間の 1 分前に当たる時間を選択し (4:38 pm など)、次のように入力します。

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

    コマンド ウィンドウのタイトル バーに C:\Windows\System32\svchost.exe と表示されていることを確認します。

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

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

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

  1. タスク スケジューラ サービスが実行されており、ログオンしたユーザーが Local Administrators グループのメンバであることを確認します。

  2. コマンドライン プロンプトで、現在のシステム時間の 1 分後に当たる時間を選択し (4:38 pm など)、次のように入力します。

    at 4:38pm /interactive cmd

  3. 「klist purge」と入力し、チケットごとに Y キーを押してすべての Kerberos チケットを削除します。

  4. 「klist tickets」と入力し、チケットが存在しないことを確認します。

  5. この手順を IKE ネゴシエーションで発生した障害のトラブルシューティングの一部として使用する場合は、IKE ネゴシエーションがタイムアウトになるまで 1 分待ち、アプリケーションで対象サーバーに再度アクセスを試みます。 新しい IKE メイン モード ネゴシエーションにより、宛先コンピュータ用の新しい Kerberos TGT およびサービス チケットが要求されます。この結果、最新のグループ情報がそのコンピュータに適用されます。 アプリケーションは、ローカル システム環境で実行しているコマンド ウィンドウからは実行しないでください。  

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

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

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

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

  1. [スタート][ファイル名を指定して実行] の順にクリックし、「ldp.exe」と入力して ENTER キーを押します。

  2. [Connection][Connect] の順に選択します。 対象ドメインの名前を指定します。

  3. [Connection][Bind] の順に選択します。 対象ドメインのログオン資格情報を指定します。

  4. [View][Tree] の順に選択します。 ベースの DN を指定せずにナビゲートして IPsec ポリシー コンテナを選択するか、ベース ロケーションとして IPsec ポリシー コンテナの LDAP DN を指定します。

  5. ツリー ビューのコンテナ ノードの横にある + (プラス記号) をクリックします。 コンテナに読み取り許可が設定されている場合は、コンテナ内のすべての IPsec ポリシー オブジェクトが表示されます。

    : 一部のドメイン ユーザーは、許可の構成方法によって、コンテナに対する読み取りアクセスの許可が与えられていない場合があります。 詳細については、マイクロソフト サポート技術情報 329194「Windows 2000 および Windows Server 2003 の IPSec ポリシー アクセス許可」を参照してください。

ldp.exe を使用して IP セキュリティ コンテナの内容と IPsec ポリシー オブジェクト間の関係を手動で検証すると、ポリシーの復旧と破損に関する問題の詳細なトラブルシューティングを実行できます。 Windows 2000、Windows XP、および Windows Server 2003 では、IPsec ポリシーに対して同じ基本的なディレクトリ スキーマが使用されています。このスキーマについては、「Windows Server 2003 Technical Reference」の「How IPsec Works」(英語) に表示されている IPsec ポリシー構造の図を参照してください。

次の表は、Active Directory オブジェクト名と IPsec ポリシーのコンポーネント名 ([IP セキュリティ ポリシーの管理] MMC スナップインで構成) の関係をまとめたものです。

表 7.4: IPsec ポリシー コンポーネント/Active Directory オブジェクト名対応表

IPsec ポリシー コンポーネント名 Active Directory オブジェクト名
IPsec ポリシー ipsecPolicy{GUID}
IKE キー交換セキュリティ メソッド ipsecISAKMPPolicy{GUID}
IPsec 規則 ipsecNFA{GUID}
IPsec フィルタ一覧 ipsecFilter{GUID}
IPsec フィルタ操作 ipsecNegotiationPolicy{GUID}
**Ldp.exe** を使用すると、IPsec ポリシー オブジェクトの最終変更時間を特定できます。この情報は、オブジェクトのバージョンと複製に関する問題を解決する際に役立ちます。 このユーティリティは、IPsec サービスの読み取りアクセス許可に関する問題を解決するために、ローカル システム環境のコマンド ウィンドウから起動することができます。 **注意** : IP セキュリティ コンテナのオブジェクトには、すべてに同じ許可を割り当てることを強くお勧めします。 IPsec ポリシー オブジェクトごとに個別に許可を設定することはお勧できません。 IPsec ポリシーの読み取りアクセス許可および変更アクセス許可を制御するには、IP セキュリティ コンテナ自体でアクセス許可を管理する必要があります。これについては、マイクロソフト サポート技術情報 329194「[Windows 2000 および Windows Server 2003 の IPSec ポリシー アクセス許可](https://support.microsoft.com/kb/329194/ja)」を参照してください。 IPsec ポリシーが破損していると、多くの場合、存在しないオブジェクトに対する DN 参照が IPsec オブジェクトに含まれています。 ただし、この破損は、制御文字がオブジェクト名の一部に使用されている場合、アクセス許可の問題によって個々のオブジェクトの読み取りができない場合、またはオブジェクトに同じ名前を指定したことで IPsec ポリシーの設計に矛盾が生じた場合 (同じフィルタ一覧の 2 つのバージョンが存在する場合など) にも発生します。 IPsec ポリシーの破損を修正する方法については、後述の「IPsec サービスのトラブルシューティングを行う」を参照してください。 **注** : これらのオブジェクトの詳細な設計については、内部のプライベート データ構造と考えられるため、マイクロソフトでは公開していません。 これらのオブジェクトの形式は、Windows のリリースごとに異なります。マイクロソフトでは、これらの形式を任意のタイミングで変更する場合があります。 したがって、これらのオブジェクトは、各プラットフォームが提供する \[IP セキュリティ ポリシーの管理\] MMC スナップインおよびコマンドライン ツールでしか管理できません。 オブジェクトは LDP でしか削除できません。ただし LDP は、破損のために \[IP セキュリティ ポリシーの管理\] MMC スナップインやコマンドライン ツールを使用できなくなった場合にのみ使用するようにしてください。 ##### ネットワーク パスの接続 サーバー/ドメイン分離ソリューションでは、ICMP プロトコルの適用を除外することをお勧めします。 理由としては、Ping、Pathping、Tracert などのユーティリティを使ったネットワーク パスのテストで ICMP を使用する必要があることなどが挙げられます。 したがって、これでこれらのユーティリティは正常に機能し、「IP セキュリティをネゴシエートしています。」というメッセージは表示されなくなります。 このメッセージが表示される場合は、誤った IPsec ポリシーが割り当てられている可能性があります。 **問題が基本的なネットワーク構成に関するものなのか、パスの接続に関するものなのかを判断するには** - クライアントからそのクライアント自体の IP アドレスまたはローカル ループバック アドレスの 127.0.0.1 に対して ping を実行できるかを確認します。 実行できない場合は、TCP/IP 構成に問題があるか、サードパーティ製のファイアウォールがインストールされているか、Ping ユーティリティが見つからないか、IP 構成が無効である可能性があります。 別の TCP/IP 構成に関するトラブルシューティング手順を用いて検証してください。 - クライアントからクライアント自体の IP 構成に示されている既定のゲートウェイに対して ping を実行できるかを確認します。 実行できない場合は、クライアントの IP 構成に問題があるか、ローカル インターフェイスに接続できないか、ローカル インターフェイスに対する接続が制限されているか、ローカル フィルタまたはネットワーク フィルタがトラフィックをブロックしているか、既定のゲートウェイへのネットワーク パスが中断されている可能性があります。 別の TCP/IP に関するトラブルシューティング手順を用いて検証してください。 - クライアントからクライアント自体の IP 構成に示されている DNS サーバーに対して ping を実行できるかを確認します。 実行できない場合は、DNS サーバーで ICMP エコー要求メッセージの受信が許可されていないか、IPsec ポリシーで適切な DNS サーバー IP アドレスが適用除外されていないか、または上に挙げたいずれかの問題が発生している可能性があります。 別の TCP/IP に関するトラブルシューティング手順を用いて検証してください。 - クライアントから適用除外リスト内の DC などの IP アドレスに対して ping を実行できるかを確認します。 実行できない場合は、問題の原因は IPsec ではありません。または、除外する IP アドレスに対応するフィルタが IPsec に設定されていません。 後者の場合、フィルタ構成を検証して確認できます。 この章の以降にある、IPsec ポリシーに関するセクションを参照してください。 - クライアントから対象の IP アドレスに対して ping を実行できるかを確認します。 実行できる場合は、クライアントと対象コンピュータの間に IPsec を使用していない基本的なネットワーク接続が存在します。 実行できない場合は、対象 IP アドレスと別の宛先 IP アドレスに対し tracert を実行して、ネットワーク パスがどの程度有効なのかを判断します。 TCP/IP およびコア ネットワークに関するその他のトラブルシューティング手順を用いて検証してください。 パス接続テストは、ICMP を使用した場合は正常に実施できますが、IKE または IPsec プロトコルを使用した場合は失敗します。 特に、Kerberos チケットを含む IKE メイン モード認証パケットの IPsec オーバーヘッドは、多くの場合、宛先 IP アドレスの PMTU より大きいため、断片化が必要になります。 このため、ホストベースのファイアウォール、ルーターのフィルタリング、ネットワーク ファイアウォール、および対象ホストのフィルタは、次のプロトコルとポートに対して開いている必要があります。また、断片化をサポートしている必要もあります。 - **IKE** : UDP 発信元ポート 500、宛先ポート 500、および断片化 - **IKE/IPsec NAT-T** : UDP 発信元ポート 4500、宛先ポート 4500 - **IPsec ESP** : IP プロトコル 50 および断片化 - **IPsec AH** : IP プロトコル 51 および断片化 ###### パスでのステートフル フィルタリングは推奨しません ステートフル フィルタリングを IKE、AH、および ESP で使用すると、接続上の問題が発生する場合があります。これは、その "ステート (状態)" が通常アクティビティのタイムアウトに基づくたためです。 各デバイスで IKE トラフィックを検証して IPsec SA が削除される時機を判断することはできません。そのようなメッセージは IKE によって暗号化されているためです。 当然ながら、IKE ではいずれかの方向のキー更新を実行できる必要があります。つまり、削除メッセージはいずれかの方向に送信されます。 一方の側で削除メッセージが受信されない場合、ピアが IPsec SA ペアを認識しなくなり、そのペアを使用するパケットが破棄されても、その側では IPsec SA ペアはまだ存在していることになります。 IKE がキー更新を行う方向は、バイト単位の有効期間が先に期限切れになる方のトラフィック フローの方向、時間単位の有効期間が期限切れになったときのキー更新オフセットの大きさ、およびアイドル状態の IPsec SA が削除された後にパケットが流れる方向に基づいています。 Windows ファイアウォール経由で接続を開始したクライアントの IKE トラフィック (および IKE ネゴシエーション) のホストベースのステートフル フィルタリングは、通常、問題を引き起こすことはありません。 Windows ファイアウォールは IPsec パケットのフィルタリングを行いません。これは、このファイアウォールがフィルタリング処理を行う層より低い層で、IPsec ドライバがパケットを処理するためです。 ただし、IKE ポートは、ファイアウォールで許可される上位層プロトコルの着信 IKE ネゴシエーション (TCP ポート 445 の SMB プロトコルを使用するファイル共有など) を受信するため、ホスト ファイアウォールで開いているように構成する必要があります。 ###### TCP で必要とされる ICMP PMTU のサポート Windows 2000 以降のリリースの既定の設定では、各 TCP パケットの IP ヘッダーには **Don't Fragment** (非断片化) ビット セットが格納されています。 この設定は、パケットのセキュリティ保護に AH または ESP のいずれかの IPsec トランスポート モードが使用された場合に維持されます。 したがって、サイズが大きすぎるパケットはルーターでドロップされ、最大許容サイズを示す **ICMP 送信先到達不能**メッセージがルーターから返されます。 この動作は、TCP パスの MTU 検出と呼ばれています。 クライアントおよび対象コンピュータの双方で、IPsec パケットが大きすぎる場合に返される ICMP PMTU メッセージを受信できる必要があります。 ハードウェア アクセラレーションでは通常、断片化されたパケットは処理されないため、IPsec で保護されたトラフィックが断片化されないようにすることは特に重要です。 断片化された IPsec パケットは、ソフトウェアの IPsec ドライバで処理する必要があります。 Windows 2000 および Windows XP では、NAT トラバーサル カプセル化 (UDP ポート 4500) を使用する IPsec トランスポート モード パケットの ICMP PMTU 検出処理はサポートされていません。 Windows Server 2003 では、この検出処理がサポートされています。 PMTU 検出なしで機能するオプションとツールについては、Windows Server 2003 オンライン ドキュメントの「[TCP/IP Troubleshooting](https://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/cnet/cnbd_trb_gdhe.asp)」セクションにある「Troubleshooting Translational Bridging」ページ (英語) を参照してください。 **注 :** 既知の問題として、NAT の外側のホストから NAT の内側のホストに対して IPsec UDP-ESP 接続を開始する NAT トラバーサル シナリオでは、トラフィックを IPsec でセキュリティ保護する場合には TCP PMTU 検出が必要になります。 このシナリオを使用する必要がある場合は、TCP PMTU 検出が有効になっていることを確認してください。それには、双方のホストで次のレジストリ キーが定義されていないか、または 1 に設定されていることを確認します。      **HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Services\\Tcpip\\**      **Parameters\\EnablePMTUDiscovery=1**     (このキーは複数行で表示される場合がありますが、1 行のレジストリと考えてください) Microsoft Windows Server 2003 Member Server Baseline Security Policy テンプレートやその他のサードパーティの構成により、TCP PMTU が無効になるようにこのレジストリ キーが設定されている場合があります。 ###### 断片化に必要なサポート ネットワークのパスとフィルタは、断片化された IKE、IPsec、AH、および ESP プロトコルの通過に対応できる必要があります。 IKE では UDP パケットが使用され、必要に応じて断片化できます。 IPsec NAT トラバーサルの実装では、IKE が証明書によって認証を行う場合にのみ IKE の断片化の回避をサポートする機能が追加されました (L2TP/IPsec VPN シナリオなど)。 Kerberos を使用する IKE 認証では、断片化の回避はサポートされていません。したがって、Kerberos チケットを含む断片化された UDP パケットの送受信に対応できる必要があります。 IPsec によるセキュリティ保護は、IP 層で送信パケットが断片化される前に元の IP パケット全体に適用されるため、AH および ESP についてはネットワーク パスは断片の通過に対応できる必要があります。 IPsec は TCP と統合されているため、TCP パケットに DF (Don't Fragment) フラグがセットされている場合 (既定の設定)、TCP は自らのパケット サイズを小さくして IPsec のカプセル化により追加される余分のバイトに対応できるようになっています。 IPsec は UDP とは統合されていません。UDP アプリケーションでは、IPsec によってトラフィックが保護されているかどうかを確認できません。 結果として、IPsec AH または ESP が適用されると、MTU の最大サイズを使用する UDP パケットは転送時にホストによって断片化されます。 同様に、IPsec ポリシー フィルタで ICMP が適用除外されていない場合、Ping ユーティリティを使用すると、ワイヤ上の断片化された IPsec AH または ESP パケットとして ICMP パケットが生成される可能性があります。 詳細については、マイクロソフト サポート技術情報 233256「[ファイアウォール経由での IPSec トラフィックを有効にする方法](https://support.microsoft.com/?kbid=233256)」を参照してください。 ###### ブロードキャスト トラフィックまたはマルチキャスト トラフィックで必要なサポート サーバー/ドメイン分離用の IPsec ポリシー設計では、Any <-> Subnet フィルタを使用します。 したがって、Subnet -> Any 送信フィルタは、内部サブネット IP アドレスを使用してホストから送信される送信ブロードキャスト/マルチキャスト トラフィックを照合します。 ただし、IPsec ではマルチキャスト/ブロードキャスト トラフィックをセキュリティ保護できないため、フィルタと一致するトラフィックは破棄されます。 受信マルチキャストと大部分の種類のブロードキャストは、対応する Any -> Subnet 受信フィルタと一致しません。 マルチキャスト/ブロードキャスト トラフィックを使用する必要がある場合は、レジストリ キーを **NoDefaultExempt=1** に設定します。このように設定すると、マルチキャスト/ブロードキャスト トラフィックは Windows XP および Windows Server 2003 の IPsec フィルタリングをバイパスできるようになります。 この構成にしておくと、マルチキャスト トラフィックを使用する Real Time Communications (RTC) クライアントおよび Windows Media Server の双方で発生する既知の問題を回避することができます。 **NoDefaultExempt** レジストリ キーの使用方法とセキュリティへの影響に関する詳細については、以下のサポート技術情報の記事を参照してください。 - 810207 - 「[IPSec default exemptions are removed in Windows Server 2003](https://support.microsoft.com/default.aspx?scid=kb;en-us;810207)」https://support.microsoft.com/?kbid=810207 (英語) - 811832 - 「[一部の状況で、IPSec のデフォルトの適用除外項目を使用して IPsec による保護を迂回することが可能になる](https://support.microsoft.com/kb/811832/ja)」https://support.microsoft.com/kb/811832/ja **注 :** Windows XP SP2 で使用されている既定の適用除外は、Windows Server 2003 のものと同じです。 レジストリ キーを設定すると、すべてのプラットフォームの既定の適用除外を必要に応じて制御できます。 IPsec フィルタリングでは、特定のブロードキャストまたはマルチキャスト アドレスに宛先アドレスを設定することはできません。 ###### ネットワーク デバイスの診断が機能しない場合 IPsec のカプセル化を使用すると、TCP/IP トラフィックをプレーンテキストとして扱うアプリケーションがネットワーク内のトラフィックを検証できなくなるという弊害があります。 TCP および UDP ポート ベースで検証またはレポート作成を実施するネットワーク診断ツールは、AH または ESP 暗号化が使用されていない場合でも、IPsec でカプセル化されたパケットを解釈できません。 ツールのベンダーから、IPsec AH または ESP-null パケットを検証するための更新プログラムを入手する必要があります。 ##### ネットワーク インターフェイス カードとドライバに関する問題 特殊な機能を実行するネットワーク インターフェイス カード (NIC) が原因で、IPsec パケットの損失が発生する場合があります。 クラスタリングまたは "チーミング" を実行するカードを使用する場合は、IPsec との互換性をテストする必要があります。 IPsec 以外の機能を加速させる NIC ドライバを使用した場合、IPsec で保護されたトラフィックで問題が発生する可能性があります。 TCP 機能を加速させる NIC では、大容量の TCP データ バッファを効率的に送信する機能 (大容量送信オフロード) 以外にも、TCP チェックサムの計算および検証を行う機能 (チェックサム オフロード) がサポートされている場合があります。 Windows 2000 以降のリリースでは、IPsec ドライバにフィルタを割り当てると、IPsec で許可とブロックの機能しか実行されていない場合でも、TCP/IP スタックの TCP オフロード機能が自動的に無効になります。 Windows Hardware Quality Lab (WHQL) で認定および署名されていないネットワーク カード ドライバを使用すると、IPsec を使用してトラフィックを保護した場合に問題が発生する可能性があります。 WHQL では、IPsec オフロードをサポートするように設計された NIC ドライバを認定する際に、膨大な量のテストを実施します。 Windows 2000、Windows XP、および Windows Server 2003 の TCP/IP スタックでは、容易にトラブルシューティングを実行できるように、あらゆる形式の TCP/IP オフロードを無効にするレジストリ キー オプションがサポートされています。 一部の NIC ドライバでは、ネットワーク接続の詳細プロパティを使用してオフロードを無効にすることもできます。 ドライバ レベルの構成変更を反映させるには、コンピュータの再起動が必要になる場合があります。 ##### IPsec プロトコルのパケット損失に関するトラブルシューティングを行う パケットの破棄や損失が発生すると、アプリケーションの接続に影響する場合があります。 ここでは、IPsec によってパケットが破棄される一般的なケースをいくつか紹介します。 既に説明したように、一部のネットワーク デバイスでは、IP プロトコルのタイプ 50 または 51、あるいは UDP ポート 500 または 4500 の通過がサポートされていない場合があります。 同様に、IPsec によってパケットがカプセル化されると、一部のパケットが断片化されてネットワークを通過できなくなる場合があります。 このような場合は、通信の両端でネットワーク モニタによるトレースを行い、送信中のパケットと受信中のパケットを特定して、相互に関連付ける必要があります。 再送信の有無も確認してください。再送信が行われると、同じサイズのパケットが繰り返し表示されます。 IPsec を使用しない一般的なプロトコルの動作を明らかにすることで、IPsec で保護されたトラフィックのプロトコル動作と比較できるようになります。 ###### イベント エラー 4285 **イベント タイトル : Hash Authentication Failure (ハッシュ認証の失敗)** IKE と IPsec を使用すると、ネットワーク転送中にパケットが変更されないように保護することができます。 整合性ハッシュで保護されているパケットの一部がデバイスによって変更された場合、受信側の IKE または IPsec ドライバによりこのパケットは破棄され、Hash Authentication Failure エラーが生成されます。このエラーは、イベント 4285 としてシステム ログに記録されます。 過去のデータによると、一部のデバイス、ネットワーク ドライバ、およびサードパーティ製パケット プロセッサで、特定のサイズのパケット、特定の数に断片化されたパケット、特定のプロトコル タイプのパケット、または特定の条件下 (デバイスの混雑時、トラフィックの監視時、再起動時など) にあるパケットが、時折破損しています。 このエラーが発生した場合、悪意のあるアプリケーションまたはパケットが保護されていることを認識しなかったアプリケーションにより、パケットへの攻撃が行われている可能性もあります。 また、サービス拒否攻撃が行われている可能性もあります。 破損したパケットの IPsec パケットの破棄を検出するには、次の方法を使用します。 ただし、破損の原因を特定するために、これらの観察結果をネットワーク モニタによるトレースと関連付けることも重要です。 - **認証できなかった IPsec パケット**の個数を確認します。 Windows Server 2003 の場合は、パフォーマンス モニタの IPsec カウンタを使用するか、 `netsh ipsec dynamic show stats`
コマンドを使用するか、または \[IP セキュリティ モニタ\] MMC スナップインの統計情報をチェックします。 Windows XP の場合は、  

`ipseccmd show stats`

コマンドを使用するか、または \[IP セキュリティ モニタ\] MMC スナップインの統計情報をチェックします。 Windows 2000 の場合は、**ipsecmon.exe** のグラフィカル表示を使用するか、  

`netdiag /test:ipsec /v`

コマンドを使用します。
  • IPsec ドライバのログ記録を有効にし、発信元の IPsec のシステム ログでイベント 4285 を探します。 IPsec ドライバのログ記録を有効にする方法については、この章の「トラブルシューティング ツールキット」を参照してください。 イベント テキストの内容は次のようなものです。

    "192.168.0.10 から受信した 5 個のパケットのハッシュを認証できませんでした。 このエラーは一時的なものである可能性がありますが、この状態が続く場合は、このコンピュータの IPSec ポリシー エージェント サービスを停止してから再起動してください。"  

このイベント テキストには IPsec サービスを再起動すると問題を解決できると記載されていますが、大部分のパケット損失問題の原因は IPsec システムではありません。 サービスを再起動しても問題は解決せず、新たな問題が発生する可能性があります。 IPsec サービスの停止は、IPsec 関連の問題かどうかを特定するための最後の手段として使用してください。

このエラーを解決するには、発信元 IP アドレス、1 日の発生回数、アダプタ、エラーが発生する条件などのパターンを特定する必要があります。 パケット数が少ない場合、調査の信憑性が低くなります。 まず、ローカル システムに破損の原因がある可能性を除外することから始めます。 IPsec オフロードを無効にし、詳細プロパティの設定を利用してドライバの高度な機能やパフォーマンス機能を無効にします。次に、ベンダーから入手した最新の NIC ドライバ (可能であれば、Windows Hardware Quality Lab の認定/署名済みのドライバ) を使用します。 次に、パケットを転送するネットワーク パスの特性を明らかにします。 TCP/IP のパケット破棄の統計データや、同じ構成が使用されている他のコンピュータも参照して、パケットの破損が他にも発生していないかどうかということも確認してください。 廃棄された受信 IP データグラムの数を示すカウンタは、IPsec がパケットを破棄するたびに加算されていきます。

注 : TCP/IP オフロード機能を無効にするには、Windows 2000、Windows XP、または Windows Server 2003 を実行しているコンピュータで次のレジストリ キーを使用します。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\
EnableOffload DWORD レジストリの値を 0 に設定
    (このキーは複数行で表示される場合がありますが、1 行のレジストリと考えてください)
その後、コンピュータを再起動します。

イベント エラー 4268

イベント タイトル : 不正なセキュリティ パラメータ インデックス (SPI) の付いたパケットの受信

Windows 2000 および Windows XP (SP1 を含む) の IKE 実装には、特定の条件下でパケット損失が発生するという既知の問題があります。 この問題は、Windows Server 2003 および Windows XP SP2 では解消されています。 他のさまざまな理由により、プロトコルで既に一定のパケット損失が想定されているため、上位層のプロトコル通信に対する影響は通常ごくわずかです。 この問題は、次のような点によって特定できます。

  • 不正な SPI カウンタの値が徐々に加算される。

  • システム ログのイベント 4268 メッセージ (有効な場合)。 Windows 2000 では、このメッセージは既定でイベント 4268 としてシステム ログに記録されます。 Windows XP では、このイベントのログは既定で記録されません。ドライバのログ記録を有効にする必要があります。 イベント テキストの内容は次のようなものです。

    "<IP アドレス> から不正なセキュリティ パラメータ インデックスの付いたパケットを <個数> 個受信しました。 このエラーは一時的なものである可能性がありますが、この状態が続く場合は、このコンピュータの IPSec ポリシー エージェント サービスを停止してから再起動してください。"  

このイベント テキストには IPsec サービスを再起動すると問題を解決できると記載されていますが、この種のパケット損失は IPsec システムの設計にその原因があります。 サービスを再起動しても問題は解決せず、新たな問題が発生する可能性があります。 既に説明したように、IPsec サービスの停止は、IPsec 関連の問題かどうかを特定するための最後の手段として使用してください。

IPsec セキュリティ パラメータ インデックス (SPI) は、パケットの処理に使用するセキュリティ アソシエーションを応答側に指示するためのパケット内のラベルです。 SPI が認識されない場合、これは "不正な SPI" と呼ばれます。このエラーは、IPsec でフォーマットされたパケットを受信した際、受信側のコンピュータにこれを処理する IPsec SA がなかったことを示します。 結果として、このパケットは破棄されます。

これらは実害のないエラー メッセージですが、パケットは実際に破棄されます。 生成される不正な SPI イベントの数は、その時点のコンピュータのビジー状態の程度と、キーの更新時に IPsec で保護されたデータが転送される速度によって異なります。 このイベントは、次のような条件があるとさらに多く生成されます。

  • 1 ギガビット以上の接続で IPsec トラフィックを大量に転送した場合。

  • サーバーの負荷が大きく (サーバーのパフォーマンスが遅く)、クライアントのパフォーマンスが高速な場合。

  • 低速のクライアントから高速サーバーに対して通信を行った場合。

  • サーバー 1 台に対してアクティブなクライアントが多数存在するため、IKE は常時、多数のクライアントに対して同時にキー更新を行う必要がある場合。  

IPsec で保護された TCP 接続は、失われたデータを再送信するときに数秒間速度が遅くなります。 複数のパケットが失われると、TCP はその接続を輻輳回避モードに移行します。 接続は数秒後に最高速度に戻ります。 ファイルのコピー、Telnet、ターミナル サーバーなどの TCP ベースのアプリケーションでは、このような少数の損失パケットに関する通知は行われません。 ただし、高速リンクの TCP で大量のパケットが失われるケースがあり、この場合は接続をリセットする必要があります。 接続をリセットすると、ソケットが閉じ、アプリケーションに接続が切断されたことが通知されます。この結果、ファイル転送が中断される可能性があります。

このエラーの最も一般的な原因は、Windows 2000 で報告されている、IKE の IPsec SA キーとの同期方法に関する既知の問題です。 IKE クイック モードの開始側の速度が応答側より速い場合、開始側は、IPsec SA のセキュリティ保護された新たなパケットを応答側の受信準備ができるより早く送信できます。 インターネット技術標準化委員会 (IETF) の IPsec に関する RFC (Requests for Comment) で指定されているように、IKE によって新しい IPsec セキュリティ アソシエーション ペアが確立された場合、開始側は新しい送信 IPsec SA を使用してデータを転送しなければならず、速度の遅い応答側は、まだ認識していない IPsec で保護されたトラフィックを受信します。 IKE のキー更新は、経過時間と IPsec SA の保護下で送信されたデータ量に依存しているため、不正な SPI イベントは定期的に発生する可能性があります (不定期に発生する可能性もあります)。

サードパーティ クライアントの相互運用シナリオでは、不正な SPI エラーが発生した場合、IPsec ピアが削除メッセージの受け付けと処理を行わなかったか、IKE クイック モード ネゴシエーションの最後の手順が完了する時点で何らかの問題が発生したことを示します。 または、攻撃者が偽装または挿入された IPsec パケットをコンピュータに大量に送信している可能性もあります。 IPsec ドライバでこのイベントはカウントされ、不正な SPI アクティビティの記録はログとして保存されます。

LogInterval レジストリ キーを使用すると、このイベントを調査して発生を最小限に抑えることができます。 トラブルシューティング時には、このレジストリ キーの値を最小に設定し (60 秒ごと)、イベントが迅速に登録されるようにします。 Windows 2000 では、IPsec ポリシー エージェント サービスを停止して再起動すると、IPsec ドライバの再読み込みを行うことができます。 Windows XP および Windows Server 2003 では、コンピュータを再起動して、TCP/IP および IPsec ドライバを再読み込みする必要があります。

Windows 2000 では、現在のレジストリ キー設定や更新プログラムでこのイベントを削除することはできません。 Windows XP および Windows Server 2003 では、既定の設定でこのイベントは報告されないようになっています。 このイベントの報告を有効にするには、netsh ipsec コマンドライン オプションを使用するか、レジストリ キーで直接 IPsecDiagnostics 構成を変更します。

次の方法を使用すると、このようなエラーを最小限に抑えることができます。

  • IPsec ポリシー設定を調整します。 セキュリティ要件で可能な場合は、クイック モードの有効期間を 21 時間ないし 24 時間に延長します (この設定を使用しないと、アイドル状態の IPsec SA は 5 分後に削除されます)。 同じキーで大量のデータを暗号化する場合に発生するセキュリティの脆弱性を回避するため、ESP 暗号化を使用するときは、有効期間を 100 MB を超える数値に設定しないようにしてください。

  • メイン モードまたはクイック モードの PFS (Perfect Forward Secrecy) を使用します。そうすると、ネゴシエート中の特定の IPsec SA ではこの問題は発生しなくなります。 ただし、いずれの設定の場合も、多数のクライアントにサービスを提供するコンピュータの負荷が大幅に上昇するため、他のネゴシエーションに対する応答で遅延が発生する可能性があります。

  • CPU またはその他のハードウェアを追加してパフォーマンスの向上を図るか、アプリケーションの負荷を軽減します。

  • IPsec ハードウェア アクセラレーション NIC を取り付けていない場合は、これを装着します。 このカードを取り付けると、高スループットのデータ転送を行う際に IPsec が占める CPU 利用率が大幅に下がります。

  • CPU 利用率が下がらない場合は、ハードウェア アクセラレーション製品の使用状況を確認して、Diffie-Hellman 演算速度を上げてください。 通常、このような製品には、Diffie-Hellman 演算を高速化する Diffie-Hellman 指数演算オフロード機能が搭載されています。 このアクセラレーションを使用すると、Secure Sockets Layer (SSL) プロトコルを使用する証明書の公開キーと秘密キーの処理においても効果が期待できます。 使用するカードが "Diffie-Hellman 演算用の CAPI の ModExpoOffload インターフェイス" を明確にサポートしているかどうかは、そのカードのベンダーにお問い合わせください。

  • 可能な場合は、IPsec 保護を必要としない特定の高速トラフィック (専用 LAN 上のサーバー バックアップ トラフィックなど) を許可するフィルタを作成します。

ここに挙げたオプションでは効果がなく、Windows XP SP2 または Windows Server 2003 にアップグレードすることもできない場合は、現在利用できる他のオプションについて、マイクロソフトの製品サポート サービスまでお問い合わせください。

イベント エラー 4284

イベント タイトル : セキュリティで保護されるべきクリア テキストのパケット

このイベントは、IPsec セキュリティ アソシエーションの内部に含まれるべきパケットをプレーンテキストで受信したその時点で、IPsec セキュリティ アソシエーションが確立されたことを示します。 このようなパケットは、IPsec で保護されている接続に対するパケット挿入攻撃を防ぐために破棄されます。 廃棄された受信 IP データグラムの数を示すカウンタは加算されますが、このような理由でドロップされたパケットを記録するカウンタ値は IPsec には用意されていません。 この問題は、システム ログのエラー イベント 4284 でしか確認できません。このイベントは次のように表示されます。

"<IP アドレス> からセキュリティで保護されるべき <個数> 個のパケットをクリア テキストで受信しました。

このエラーは一時的なものである可能性がありますが、この状態が続く場合は、このコンピュータの IPSec ポリシー エージェント サービスを停止してから再起動してください。"

既に説明したエラーと同じく、このイベントの指示には従わないでください。 IPsec サービスを再起動しても、エラーが解消する可能性はほとんどありません。

このエラーの原因はポリシー構成上の問題とする説が有力です。より具体的な送信許可フィルタが設定されているため、一方の側がトラフィックをクリア テキストで送信してしまうためと考えられます。 たとえば、クライアントにはサーバーとのすべてのトラフィックをセキュリティ保護するフィルタが割り当てられ、サーバーのポリシーにはプレーンテキストの HTTP 応答を許可する具体的なフィルタが割り当てられている場合、サーバーはクライアントに送信するすべてのトラフィックをセキュリティ保護しますが、送信 HTTP パケットのみ保護されません。 クライアントはこれらのパケットを受信しますが、サーバーとの間で送受信されるすべてのトラフィックが IPsec SA ペアの内部でセキュリティ保護されるものと想定しているため、セキュリティ上の理由からこれらを破棄します。

このイベントは、通常の操作中にも、サードパーティ製クライアントとの相互運用が行われているケースでも発生します。このケースでは、コンピュータ間のトラフィック送受信中、一方のピアにより IPsec セキュリティ アソシエーションまたは IPsec ドライバのフィルタが削除されます。 たとえば、一方の側が IPsec ポリシーの割り当てを解除したり、ポリシーを更新して IPsec SA やフィルタを削除する場合があります。 一方のピアで既にフィルタが削除されているにもかかわらずアクティブな上位層プロトコル通信が行われるため、IKE 削除メッセージは到着せず、プレーンテキスト パケットが到着する前に別のピアがこのメッセージを処理します。この結果、エラーが発生します。 また、削除メッセージの処理にかかる時間は、ピア コンピュータのその時点の負荷によって異なります。

すべてのフィルタ セットが IPsec ドライバに適用される前に IPsec セキュリティ アソシエーションが確立される場合があるため、エラー メッセージは、容量の大きいポリシーを読み込んでいるときにも発生します。 この問題が発生すると、ポリシーの読み込みが完了した後、適用除外するトラフィックのネゴシエーションが IPsec SA によって行われる場合があります。

このエラー メッセージは挿入攻撃が行われていることを示す場合もあります。その場合、アクティブな特定の受信セキュリティ アソシエーション用のトラフィック セレクタと (故意にまたは偶然に) 一致するプレーンテキスト トラフィックが送信されています。

この問題は、IPsec ポリシーの設計担当者にエスカレートする必要があります。

ワイヤレス ネットワーク接続時の IPsec NAT-T のタイムアウト

Windows Server 2003 または Windows XP ベースのクライアント コンピュータから IPsec NAT-T を使用するワイヤレス ネットワーク上のサーバーに接続しようとすると、接続がタイムアウトになるという問題が最近報告されています。 詳細については、マイクロソフト サポート技術情報 885267 を参照してください。

IPsec ポリシーが正しいことを確認する

ここでは、IPsec ポリシーの割り当てと解釈に関する問題を検出する手順について説明します。 IKE によるリモート IP アドレスとの IPsec SA のネゴシエーションを開始させてトラフィックのセキュリティを保護するには、また IPsec によってパケットの許可およびブロックを行うには、正しく解釈された IPsec ポリシーのフィルタが IPsec ドライバに割り当てられている必要があります。 また、IKE を応答側として導くためにも、適切なフィルタを配置する必要があります。 このソリューションでは、IPsec ポリシーはすべてのトラフィック (ICMP を除く) を IPsec でセキュリティ保護するように設計されています。 ポリシーには、適用除外リストの各 IP アドレスに対応するフィルタも含まれています。

注 : Windows 2000 では、IPsec サービスは IPsec ポリシー エージェントと呼ばれています。Windows XP および Windows Server 2003 では、このサービスは IPsec サービスと呼ばれています。

サポート エンジニアは、IPsec によるグループ ポリシーの使用、IPsec ポリシーの優先順位、IPsec ポリシーの解釈について熟知しておく必要があります。 このトピックの詳細に関する参考資料は、この章の最後にある「関連情報」セクションで紹介しています。  

IPsec のグループ ポリシーのトラブルシューティングを行う

グループ ポリシーでは、ドメインベースの IPsec ポリシーをドメイン メンバに割り当てる仕組みを利用できます。 割り当てられた GPO をドメイン メンバが取得することで、IPsec ポリシーの割り当てがホスト コンピュータに配布されることになります。 したがって、GPO の取得の際に問題が発生すると、コンピュータに正しい IPsec ポリシーが適用されなくなります。 IPsec ポリシーの管理に影響するグループ ポリシーの一般的な問題には、次のようなものがあります。

  • Active Directory 内のさまざまな構成コンポーネントの複製の遅延

  • グループ ポリシーのポーリングおよびダウンロード プロセスに関する問題

  • 割り当てる IPsec ポリシーのバージョンの混乱

  • IPsec サービスが実行されていない

  • Active Directory の IPsec ポリシーを取得できないため、キャッシュに保存されているコピーで代用される

  • 現在割り当てられている IPsec ポリシーを取得するためにポーリングが行われたことによる遅延

IPsec ポリシー、GPO、GPO IPsec ポリシーの割り当てと IPsec ポリシーの属性変更、セキュリティ グループ メンバシップ情報など、Active Directory にある IPsec 関連オブジェクトの数が原因で、複製が遅延する場合があります。 IPsec の構成を変更するとドメイン メンバに徐々に影響が表れるため、このような影響を十分に考慮して慎重に計画を立てる必要があります。

グループ ポリシーのトラブルシューティング手順については、次の資料を参照してください。

ドメインベースの IPsec ポリシーの割り当ては、次の 2 つのコンポーネントにより実装されます。

  • GPO の IPsec ポリシーを割り当てるための、[IP セキュリティ ポリシーの管理] MMC スナップイン ([セキュリティ ポリシー] MMC スナップインの拡張機能)。

  • GPO にある IPsec 関連情報を処理する、グループ ポリシーの IPsec 用クライアント サイド拡張機能 (CSE) (gptext.dll で実装されます)。  

[IP セキュリティ ポリシーの管理] MMC スナップインでは、ポリシーを GPO に割り当てる場合、選択された IPsec ポリシー情報を GPO の IPsec コンポーネントに保存します。この情報は、次の LDAP 識別名 (DN) として参照されます。

CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID},
CN=Policies,CN=System,DC=domain,DC=Woodgrove,DC=com

割り当てられる IPsec ポリシーの LDAP DN は、GPO 属性 ipsecOwnersReference に保存されます。

グループ ポリシーがコンピュータに適用する GPO のリストを取得すると、IPsec ポリシーの割り当てが格納されている GPO は、IPsec クライアント サイド拡張機能の GUID の下で、次の場所のレジストリに保存されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Group Policy
\History\{e437bc1c-aa7d-11d2-a382-00c04f991e27}

GPO に IPsec ポリシーの割り当てが格納されている場合、IPsec CSE はセキュリティ ポリシー CSE によって常にアクティブ化されます。 セキュリティ ポリシーの処理中に問題が発生した場合、IPsec ポリシーの処理中にも問題が発生する可能性があります。 各グループ ポリシー拡張機能の GUID は、次のレジストリで確認できます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\WinLogon\GPExtensions

IPsec の展開に関連するグループ ポリシー CSE の GUID は、次の場所で確認できます。

  • セキュリティ : {827D319E-6EAC-11D2-A4EA-00C04F79F83A}

  • IP セキュリティ : {E437BC1C-AA7D-11D2-A382-00C04F991E27}

  • スクリプト : {42B5FAAE-6536-11D2-AE5A-0000F87571E3}

IPsec CSE は、割り当てられる IPsec ポリシーの LDAP DN および関連情報を次のレジストリ キーにコピーします。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

IPsec ポリシーの割り当てが格納された GPO が複数ある場合は、各 GPO ごとに IPsec CSE が呼び出されます。 IPsec CSE が GPO を受け取って処理する順序には、GPO の優先規則が適用されます。 この順序も、GPO 自体の設定や、割り当てられた一部の GPO を取得できなくする読み取り ACL によって変わる場合があります。 IPsec CSE が呼び出されると、そのたびに GPO の IPsec 関連情報 (DN など) がこのレジストリ キーに上書きされます。 すべての GPO の処理が完了すると、CSE によって IPsec サービスに信号が送られ、これがドメインベースの IPsec ポリシーの割り当てを行う合図になります。 次に、IPsec サービスが GPTIPsecPolicy\DSIPSECPolicyPath の値を読み取り、適切な IPsec ポリシーを取得します。

IPsec サービスは、割り当てられた IPsec ポリシー ディレクトリ オブジェクトのいずれかの最終更新時刻に基づき、割り当てられた IPsec ポリシーの変更を継続的にポーリングします。 サービスは、キャッシュに保存された IPsec ポリシーを最新のドメイン ポリシーとしてメンテナンスします。

既知の問題として、割り当てられている IPsec ポリシーの名前と、実際に使用されている (およびキャッシュに保存されている) IPsec ポリシーの名前が一致しなくなるケースが報告されています。 IPsec サービスは、DSIPSECPolicyName などの GPTIPsecPolicy レジストリ キーの情報を更新しません。IPsec ポリシーの名前は、IPsec CSE が呼び出された場合にのみ変更されます。 ただし、GPO の IPsec ポリシー割り当ての DN 属性が変更されない限り、IPsec CSE は呼び出されません。 このレジストリ値を [IP セキュリティ モニタ] MMC スナップインおよびコマンドライン ツールで使用すると、現在割り当てられている IPsec ポリシーの名前が表示されます。 したがって、IPsec ツールを使用した場合、現在使用されている IPsec ポリシーではなく、CSE が最後に処理した IPsec ポリシーの名前が表示される可能性があります。 このバグに対処する方法はいくつかあります。詳細については、このガイドの「第 5 章 : 分離グループの IPsec ポリシーを作成する」の「ポリシーのバージョン管理」を参照してください。

注 : マイクロソフトでは、名前の中にバージョン番号を組み込むという規則を、IPsec ポリシーの命名規則に含めることをお勧めしています。そうしておくと、現在適用されているポリシーのバージョンを簡単に確認できます。 そのようにしていない場合、ポリシーの名前に同じものが残っていると、バージョンの変更を容易に確認できなくなります。

グループ ポリシーを強制的に更新しても適切な IPsec ポリシーが割り当てられない場合は、Userenv または SceCli のアプリケーション ログ エラーを参照して、グループ ポリシーの処理において問題が発生していないかどうかを確認します。 この問題を詳しく調査するには、グループ ポリシーのログ記録を有効にする必要があります。 グループ ポリシーのログには、さまざまな種類とログ記録レベルがあります。 セキュリティ CSE のログは、IPsec CSE が報告するエラー以外に、セキュリティ ポリシーの処理中に発生したエラーを確認するために必要です。 IPsec CSE 専用のログはありません。 グループ ポリシーの更新時のトラフィックを取得して各オブジェクトの取得に使用されているドメイン コントローラ IP アドレスを確認するため、ネットワーク モニタによるトレースが必要になる場合があります。 問題には、次のようなものがあります。

  • オブジェクトの未検出につながる複製に関する問題または遅延。

  • ドメイン コントローラ ロケータの負荷分散ロジックが原因で、GPO はある特定のドメイン コントローラから取得されているのに、割り当てられる IPsec ポリシーの LDAP クエリは同じサイトの別のドメイン コントローラから取得されている。

セキュリティ CSE の詳細なログ ファイルを作成するには、次のレジストリ キーを使用します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\CurrentVersion\Winlogon
\GpExtensions\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\

ExtensionDebugLevel エントリの REG_DWORD の値を 0x2 に設定します。

ログ ファイルは、%windir%\Security\Logs\Winlogon.log として作成されます。

注 : 無効な DNS エントリがあると、コンピュータとユーザーは正常にログオンできても、Active Directory からグループ ポリシーがダウンロードされません。 DNS の問題の詳細については、前述の「名前解決に関する問題」を参照してください。

IPsec サービスのトラブルシューティングを行う

[IP セキュリティ ポリシーの管理] MMC スナップインを使用する場合、IPsec サービスが実行されている必要はありません。 ただし、その場合に管理者がローカル ポリシーを割り当てると、[ポリシーの割り当て] 列にエラーが表示されます。

次のような一般的な問題が原因で、起動時に IPsec サービスが失敗する場合があります。

  • セーフ モードまたは Active Directory 障害回復モードでコンピュータを起動した。 このような場合に IPsec ポリシーが割り当てられていると、IPsec ドライバは既定でステートフル送信を行います。 このときに bootexemption が設定されていない場合、受信接続がブロックされます。

  • IKE が UDP ポート 500 およびポート 4500 の排他的制御を取得できない。 netstat –bov コマンドを使用して、各ポートのプロセスとコード モジュールを表示します。 portqry –local –v コマンドを使用すると、さらに詳しい情報が表示されます。 IPsec と競合する一部の LSP (Winsock Layered Service Provider) がインストールされている場合があります。 LSP と IPsec の詳細については、この章で後述する「アプリケーションに関連する問題のトラブルシューティングを行う」を参照してください。

  • IPsec ポリシーが破損している。 割り当てられた IPsec ポリシーをまったく読み取れないかまったく適用できない場合、IPsec サービスにより多数のエラーが報告されます。 このエラーでサービス自体に支障が出ることはありませんが、グループ ポリシーがブロックされたり IPsec サービスが修正されたポリシーを取得できなくなるなどの理由から、多くの点で通信障害の原因となる可能性があります。 Windows XP および Windows Server 2003 では、ドメインベース ポリシーの適用時に発生するエラーに備えて、継続ポリシーやローカル ポリシーを "安全な" ポリシーとして設計しておく必要があります。 継続ポリシーとコンピュータ スタートアップ ポリシー (bootmode 適用除外リスト) は、トラブルシューティングの調査時には必ず確認する必要があります。 これらのポリシーは、他の障害によってこれらのポリシーが適用されている唯一のポリシーになった場合、別の方法でコンピュータにリモート アクセスすることを許可します。

Windows 2000 の IPsec の実装では、IPsec ポリシー ストア (polstore.dll) と呼ばれるモジュールが使用され、IPsec ポリシー エージェントと [IP セキュリティ ポリシーの管理] MMC スナップインで 1 つのモジュールを使用して、サポートされている 3 つのポリシー保管場所 (ローカル、リモート コンピュータ、Active Directory) にアクセスできるようになっています。 Windows XP および Windows Server 2003 ではこの設計に改良が加えられ、新しい種類の IPsec ポリシー (スタートアップ ポリシーと継続ポリシー) とセキュリティ ポリシー データベース (SPD) コンポーネントが追加されています。このコンポーネントでは IPsec ポリシーのランタイム状態が保持され、IPsec モニタのクエリと IKE のクエリに対応できます。 アーキテクチャがこのように変更されたため、Windows XP および Windows Server 2003 では、Windows 2000 でログに記録されていた IPsec イベントのテキストも変更されています。 同様に、リモート管理に使用する RPC インターフェイスも大幅に変更されています。 Windows Server 2003 では、RPC インターフェイスも一新されています。 その結果、[IP セキュリティ ポリシーの管理] MMC スナップインは、別のバージョンのオペレーティング システムがインストールされているリモート コンピュータに接続できなくなりました。 また、Windows XP SP2 および Windows Server 2003 SP1 ではセキュリティ モデルが根本的に見直された結果、リモート RPC 接続が制限され、Windows ファイアウォールが既定で有効になっています。 詳細については、「"Windows XP Service Pack 2 セキュリティ強化機能搭載" での機能の変更点 - 第 2 部 : ネットワーク保護技術」を参照してください。

このような変更により、IPsec サービス用のリモート RPC インターフェイスは、安全上の理由から無効とされました。 このため、[IP セキュリティ モニタ] MMC スナップインと [IP セキュリティ ポリシーの管理] MMC スナップインでは、これらのコンピュータ上でリモート監視を実行できません。 IPsec のリモート管理を実行するには、IPsec の MMC スナップインをローカル プロセスとして実行するリモート デスクトップ (ターミナル サーバー) 接続を使用します。

Windows 2000 では、IPsec ドライバは、ポリシー エージェント サービスの起動プロセスの完了時に既定で読み込まれます。 ポリシー エージェントがアクティブなポリシーの IPsec ドライバ情報を最初に送信するまで、IPsec ドライバは IP パケット処理の一部として組み込まれません。 アクティブな IPsec ポリシーが存在しない場合、IPsec ドライバは、受信/送信 IP トラフィックの処理に組み込まれません。 Windows XP および Windows Server 2003 では、このような設計が改善されています。IPsec ドライバは、起動プロセス中に TCP/IP ドライバによって読み込まれます。 IPsec サービスによってフィルタが読み込まれるまで、ドライバはパケットを処理しません。

Windows 2000 では、サービス起動時に問題が発生した場合、IPsec ポリシー エージェントによってエラーがログに記録される場合があります。 エラーには次のようなものがあります。

  • IP セキュリティ ポリシー エージェントを開始できませんでした。 IP セキュリティ ポリシーは施行されません。: このエラーは、IPsec ポリシー エージェントを RPC サブシステムに登録する際に何らかの問題があった場合に発生します。 または、サードパーティ製の Winsock LSP があるため IKE の初期化に失敗した場合にも発生することがあります。

  • ポリシー エージェント RPC サーバーは、...

    • プロトコル シーケンスを登録できませんでした。

    • インターフェイスを登録できませんでした。

    • インターフェイス バインド情報を登録できませんでした。

    • インターフェイスのエンドポイントを登録できませんでした。

    • 認証機構を登録できませんでした。

    • リッスンに失敗しました。

    これらのエラーは、詳細なセキュリティ設定を変更した場合、または RPC サービス内の問題により IPsec ポリシー エージェント サービスの起動時に正常に初期化できなくなった場合に発生します。 したがって、IPsec ポリシー エージェントは正常に機能しません。ハングアップするかシャットダウンする場合もあります。

  • ポリシー エージェントは ... を開始できませんでした。 SCM データベースに接続できませんでした。 エラー: <番号> : IPsec サービスがサービス制御マネージャ データベースを開けません。この問題は、IPsec サービスが権限のないサービス アカウントとして実行されるように構成されている場合に発生します。 IPsec サービスは、ローカル システムとして実行する必要があります。 そうしない場合は、サービス制御マネージャの問題を確認してください。

  • ポリシー エージェントは IPSEC ドライバに接続できませんでした。: IPsec ドライバを正常に読み込めなかったため、TCP/IP スタックとのインターフェイスを確立できませんでした。 Windows 2000 では、IPsec サービスの起動時に読み込みが行われるように設計されています。 接続を禁止するサードパーティ製ソフトウェアが存在するか、この機能に必要なコード モジュールがオペレーティング システムで見つからない可能性があります。

  • ポリシー エージェントは IPSEC ポリシーを読み込めませんでした。: IPsec ポリシー エージェントがすべてのフィルタを IPsec ドライバに読み込んでいるときにエラーが発生しました。 このエラーは、カーネル メモリの不足、または IPsec ドライバの不適切な初期化が原因で発生している可能性があります。 問題が解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。

  • ポリシー エージェントは ISAKMP サービスを開始できませんでした。: このエラーは通常、別のサービスによって既に使用されているために UDP ポート 500 またはポート 4500 の排他的制御を IKE が取得できない場合に発生します。 また、ネットワーク ポートの割り当てを禁止するサードパーティ製セキュリティ ソフトウェアや、IPsec サービスをローカル システム環境で実行していないことが原因で発生する場合もあります。

  • ISAKMP/Oakley サービスの SSPI プリンシパル名を特定できませんでした。: Windows 2000 では、セキュリティ サポート プロバイダ インターフェイス (SSPI) による QueryCredentialsAttributes の呼び出しが失敗すると、このメッセージがログに記録されます。 コンピュータがドメインに正常にログインできないことを示す場合もあります。

  • ISAKMP/Oakley サービスのための Kerberos サーバーの資格情報を取得できませんでした。: Windows 2000 では、このエラー メッセージは通常、Kerberos 認証を必要とする IPsec ポリシーが (おそらくはドメイン ポリシーのレジストリ キャッシュから) 割り当てられ、利用できるドメイン コントローラが存在しないリモート ネットワークで IPsec サービスが (おそらくはコンピュータの起動時に) 開始された場合に生成されます。 したがって、Kerberos 認証は機能しません。 内部ネットワークでは、このイベントは、ドメインのメンバではないコンピュータか、または IPsec サービスの初期化中に Kerberos プロトコルを使用してドメイン コントローラにアクセスできないコンピュータで、ログとして記録されます。

  • セキュリティで保護された通信ポリシーは施行されませんでした。IP セキュリティ ドライバを開始できませんでした。 今すぐシステム管理者に問い合わせてください。: このエラーは、IPsec ドライバの読み込み、TCP/IP スタックへのバインド、またはポリシーを追加する前の初期化に問題がある場合に発生します。 ファイルの破損やアクセス許可が原因になる場合もあります。 セキュリティの設定、またはドライバの読み込みを禁止するサードパーティ製セキュリティ ソフトウェアの有無を確認してください。 初期化中に FIPS.sys 内部署名を確認できないと、FIPS.sys が読み込まれないため、IPsec ドライバの読み込みも失敗します。 FIPS.sys 署名に関する問題が発生した場合は、署名済みの元のバイナリ ファイルに置き換えるか、新しいバイナリ ファイルをマイクロソフトから入手する必要があります。 それから、コンピュータを再起動します。 それでも問題が解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。  

Windows XP および Windows Server 2003 では、サービスを開始できないことを示す IPsec サービスのエラー イベントとして、次のようなものがあります。

  • IPSec サービスはエラー コード <番号> により IPSec ドライバを初期化できませんでした。 IPSec サービスを開始できませんでした。: 何らかの理由で IPsec ドライバを読み込めませんでした。 問題が解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。

  • IPSec サービスはエラー コード <番号> により IKE モジュールを初期化できませんでした。 IPSec サービスを開始できませんでした。: この問題は通常、サードパーティ製 Winsock LSP が存在するために IKE で特定のソケットを使用できないことが原因です。 このエラーは、IKE で UDP ポート 500 および 4500 の排他的制御を取得できない場合にも報告されます。

  • IPSec サービスはエラー コード <番号> により RPC サーバーを初期化できませんでした。 IPSec サービスを開始できませんでした。: IPsec サービスは、IKE、SPD、およびポリシー エージェントのプロセス間通信が行われる RPC サブシステムに依存しています。 RPC のトラブルシューティング方法を使用して、RPC が正常に動作していることを確認してください。 コンピュータを再起動しても問題が解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。

  • IPSec サービスは重大な障害があったため、エラー コード <番号> でシャットダウンしました。 IPSec サービスを停止すると、コンピュータのセキュリティに危害を与える可能性があります。 コンピュータの管理者に連絡して、サービスを再起動するようにしてください。: IPsec サービスでイベント テキストのエラー コード番号が示すエラーが発生し、サービスが停止しました。 ただし、IPsec ドライバの読み込みは完了しており、通常モード (IPsec ポリシーのフィルタを適用) またはブロック モードのいずれかの状態にあります。 IPsec ドライバがブロック モードに設定されたかどうかは、別のイベントが示します。 ドライバが通常モードの場合、許可とブロックのフィルタ操作は通常どおり機能します。 IKE は使用できなくなるため、ネゴシエート操作を含むフィルタではトラフィックがドロップされるだけになります。

  • IPSec サービスは、以前のエラー (エラー コード <番号>) のため、IPSec ドライバをブロック モードにしました。: このメッセージは、IPsec ポリシーの処理中にエラーが発生したため、フェイルセーフ動作として IPsec ドライバがブロック モードに移行したことを示します。 これは、Windows Server 2003 のみの動作です。 ブロック モードでも、netsh ipsec コマンドを使用して構成された受信トラフィックの適用除外リストは適用されます。  

IPsec ポリシーの取得に関するトラブルシューティングを行う

IPsec サービスは、暗号化された認証済みの TCP LDAP クエリを使用して、割り当てられた IPsec ポリシーをすべてのプラットフォームにダウンロードします。 Kerberos セッション キーを使用して LDAP の署名と封印を行うこともできます。 したがって、ローカル システムとして実行されている IPsec サービスは、Active Directory サーバーで LDAP サービス用の Kerberos サービス チケットを取得できる必要があります。 割り当てられている適切な IPsec ポリシーが IPsec CSE によって GPTIPsecPolicy レジストリ キーに確かに保存されており、そのサービスが実行されている場合、次のような問題が原因で IPsec サービスが Active Directory からポリシーを取得できなくなる可能性があります。

  • ドメイン コントローラとの通信に関する問題。

  • コンピュータ アカウントによるドメイン コントローラへのログオンに関する問題。

  • Kerberos チケットの発行に関する問題。

  • LDAP サービスの可用性に関する問題。

  • LDAP クエリで要求された特定の IPsec ポリシーまたはコンポーネント オブジェクトの検索に関する問題。

  • 要求された IPsec ポリシー オブジェクトのいずれかの読み取りアクセス許可に関する問題。

  • オブジェクトをストアに保存する際に問題が発生したことによる、あるいは、ストア内のオブジェクトを誤ってまたは意図的に削除したことによる、ポリシーの破損。  

    : Windows XP または Windows Server 2003 で IPsec ポリシーを作成し、これらのバージョンでのみ利用できる新機能を使用している場合、このポリシーを Windows 2000 の [IP セキュリティ ポリシーの管理] MMC スナップインで編集して保存すると、それらの新機能は警告なしに削除される可能性があります。 ただし、Windows 2000 システムで追加機能を含む IPsec ポリシーを取得した場合、それらの機能は単に無視されるだけで済みます。この IPsec ポリシーを Windows 2000 システムで強制的に適用した場合、ポリシーの動作が変化するかどうかは予測できません。

[IP セキュリティ ポリシーの管理] MMC スナップインには、Active Directory またはリモート コンピュータで IPsec ポリシーを管理すると発生する既知の問題があります。 MMC スナップインを低速リンクで実行すると、サイズの大きいポリシーの変更をすべて保存する際に一定の時間がかかる場合があります。 MMC スナップイン ウィンドウを閉じると、保存していない IPsec ポリシーのオブジェクトや変更内容はすべて失われます。 このとき、IPsec ポリシーが破損する可能性があります。 [IP セキュリティ ポリシーの管理] MMC スナップインを低速リンクで実行する場合は、リモート デスクトップ セッションを使用してローカル プロセスとしてスナップインを実行してください。

一般に、IPsec ポリシーを作成するコマンドライン ツール スクリプトは、テストを実施する必要があります。 そのためには、ローカル ストアでポリシーを作成し、[IP セキュリティ ポリシーの管理] MMC スナップインでこれを表示して整合性を確認します。 テスト コンピュータでローカル IPsec ポリシーを適用し、[IP セキュリティ モニタ] MMC スナップインで詳細を検証して、フィルタの順序を確認します。

IPsec ポリシーの読み取りエラーと破損に対してトラブルシューティングと修正を行う手順は、ポリシーの保存場所によって異なります。 このソリューションでは、ドメインベースの IPsec ポリシーのみを使用していますが、他の種類の IPsec ポリシーの構成が原因で問題が発生している場合があります。

ポリシーの種類別のトラブルシューティング手順については、このセクションの以降の部分で説明します。 一般に、第 2 層のサポートでは、コマンドラインまたは GUI ツールのいずれかを使用して、適切な IPsec ポリシーが取得されているか、ポリシーは適切に解釈されているかを確認できる能力が求められます。 ポリシーを更新することで適切なポリシーが正常にインストールされると考えられる場合は、ポリシーを削除します。ポリシーを削除する手順は、ポリシーの種類ごとに以下で説明します。 適切なポリシーをスクリプトで取得またはインストールできないと考えられる場合は、問題を第 3 層のサポートにエスカレートします。

スタートアップ IPsec ポリシー

Netsh ユーティリティを使用すると、Windows Server 2003 のみでサポートされている bootmode および bootexemptions オプションを構成できます。 構成は、次に示すレジストリ キーに既定の値で保存されます。

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\
    OperationMode=3 (ステートフル)

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\
    BootExemptList = (受信 DHCP の適用除外リスト、下記参照)

OperationMode が既定値の場合、IPsec ドライバは送信トラフィックのステートフル フィルタリングを実行します。 IPsec サービスが実行されている場合は、

Netsh ipsec dynamic show config

コマンドを使用するとスタートアップ構成を表示できます。 IPsec サービスが実行されていない場合 (セーフ モードで起動した場合など) は、レジストリ ツールを使用するとレジストリ キーの値を確認して変更することができます。
起動中の IPsec ステートフル フィルタリングが原因と考えられるトラフィックに関する問題を解決するには、起動時にステートフル フィルタリングを実行せずにトラフィックを許可するように IPsec ドライバを設定します。 IPsec サービスが実行されている場合は、

netsh ipsec dynamic set config bootmode value=permit

を使用してスタートアップ モードを許可に設定します。 IPsec サービスが実行されていない場合は、レジストリ ツールを使用して OperationsMode=1 に変更すると、許可に設定できます。 または、IPsec サービスを手動で開始されるように構成するか、サービス自体を無効にすると、IPsec ドライバはスタートアップ セキュリティ モードを適用しません。 サービスを手動で開始されるように構成するか、サービス自体を無効にした場合は、コンピュータを再起動して IPsec ドライバを許可モードで読み込みます。

継続 IPsec ポリシー

継続ポリシーは、Windows XP および Windows Server 2003 でサポートされています。 新しい継続ポリシーを定義する前に既存の継続ポリシーが検出されない場合、または新しいポリシーの設定が既に割り当てられている他の設定と矛盾する場合は、一般的なエラーが発生します。 このガイドで説明しているソリューションでは、継続ポリシーは使用していません。 ただし、一部の環境で使用される可能性があるため、この章では、継続ポリシーに関するトラブルシューティング手順も紹介します。

継続ポリシーのレジストリ キーは既定で存在しますが、次に示すように空の状態になっています。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Persistent

Windows XP では、このレジストリ キーが空かどうかを確認することで、継続ポリシーの有無を簡単に確認できます。 ipseccmd show コマンドを実行すると、IPsec サービスに含まれているアクティブなポリシーが報告されます。継続ポリシーに含まれている特定の設定は報告されません。 IPsec サービスで継続ポリシーの設定がアクティブと解釈された場合、そのポリシーの規則に付けられた名前は破棄されます。 ipseccmd コマンドではフィルタおよびフィルタ操作の名前を付けられないため、命名規則を使用して継続ポリシーに含まれているフィルタおよびフィルタ操作を表すことはできません。 ipsecpol.exe または ipseccmd.exe でフィルタを作成すると、フィルタの名前は "text2pol{GUID}" という形式になります。この名前には、継続ポリシーのエントリも含まれます。 ただし、スクリプトを使用して作成したローカル ポリシーまたはドメイン ポリシーの名前も、このような形式の名前になる場合があります。

継続ポリシーは、適用された後にローカルまたはドメイン IPsec ポリシーと結合します。 したがって、継続ポリシーの設定のみを表示するには、その前にローカル ポリシーとドメイン ポリシー双方の適用を解除する必要があります。

ipseccmd show all

を使用すると、IPsec サービスの開始時に継続ポリシーも含めてアクティブなポリシーがすべて表示されます。
特定の継続ポリシーに関連付けられているすべてのオブジェクト (規則、フィルタ一覧、フィルタ操作) を削除するには、次のコマンドで継続ポリシーの名前を指定します。

ipseccmd.exe -w PERS -p "policy name" –o

Persistent キーの下にあるサブ キーをすべて削除すると、すべての継続ポリシーを簡単に削除できます。 ただし、Persistent キー自体を削除すると、次回に継続ポリシーを作成するときに ipseccmd コマンドが失敗します。 継続ポリシーの破損とポリシーの競合を解消するには、継続ポリシーのストア内にあるオブジェクトをすべて削除し、ipseccmd スクリプトを再度実行して継続ポリシーを作成します。

Windows Server 2003 では、継続ポリシーは、ローカル/ドメイン IPsec ポリシーと同様の完全な管理機能を備えています。 継続ポリシーは、前述したレジストリと同じ場所に保存されます。 次の Netsh コマンド スクリプトでは、show_persistent.netsh ファイルのコマンドを使用して構成済みの継続ポリシーを表示します。

Netsh –f show_persistent.netsh

show_persistent.netsh ファイルは、次の各行が記載されているテキスト ファイルです。

Pushd ipsec static
Set store persistent
show all
exit

次の Netsh コマンド スクリプトを使用すると、すべての継続ポリシーを削除できます。

pushd ipsec static
set store persistent
delete all
exit
ローカル IPsec ポリシー

ローカル IPsec ポリシーは、Windows 2000、Windows XP、Windows Server 2003 でサポートされており、次のレジストリ キーに保存されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local

ローカル ポリシーが割り当てられた場合、割り当てられたポリシーは次のキーに保存されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local\ActivePolicy

ドメイン ポリシーが割り当てられていない場合は、割り当てられたローカル ポリシーが構成済みの継続ポリシーに追加され、アクティブなポリシーになります。 トラブルシューティングを容易にするため、ipsecpol または ipseccmd スクリプトで作成した IPsec ポリシーは、運用環境で使用する前に [IP セキュリティ ポリシーの管理] MMC スナップインで編集して、フィルタごとにフィルタ名を定義することをお勧めします。 または、 netsh ipsec コマンドを使用して Windows Server 2003 ベースのコンピュータでポリシーを作成し、Windows 2000 および Windows XP ベースのコンピュータにインポート可能なファイルにエクスポートするか、ポリシーのテスト後にドメインにインポートします。

Windows 2000 では、 netdiag /test:ipsec /debug コマンドを使用すると、割り当てとアクティブなポリシーの詳細を表示できます。 ローカルに保存された IPsec ポリシー オブジェクトを削除するには、[IP セキュリティ ポリシーの管理] MMC スナップインかまたはレジストリ ツールを使用します。 割り当てられた IPsec ポリシーを強制的に再読み込みするには、サービスを停止して再起動します。

Windows XP では、 ipseccmd show gpo または netdiag /test:ipsec コマンドを使用すると、割り当てとアクティブなポリシーの詳細を表示できます。 [IP セキュリティ ポリシーの管理] MMC スナップインか、レジストリ ツールか、または ipseccmd.exe -w REG -p "<policy_name>" –o コマンドを使用すると、名前が付けられた IPsec ポリシーを削除できます。 前述の保存場所にあるサブキーをすべて削除すると、すべてのローカル ポリシーを簡単に削除できます。

IPsec サービスでポリシーの再読み込みを強制的に行うには、IPsec サービスを停止して再起動するか、[IP セキュリティ ポリシーの管理] MMC スナップインを使用して IPsec ポリシーの割り当てを解除し、再割り当てを行います。 または、 sc policyagent control 130 コマンドを使用してポリシーの再読み込みを行うこともできます。 ポリシーの再読み込みが行われると、すべての IPsec および IKE SA が削除されます。このとき、IPsec SA を使用してトラフィックの送受信を実施しているコンピュータで、接続の遅延や中断が発生する場合があります。

Windows Server 2003 では、
netsh ipsec static show gpoassignedpolicy コマンドか、[IP セキュリティ ポリシーの管理] MMC スナップインか、または [IP セキュリティ モニタ] の [アクティブなポリシー] ノードを使用して、現在割り当てられているローカル ポリシーを表示できます。

netsh ipsec dynamic show all コマンドを使用すると、現在のアクティブなポリシー構成を表示できます。 または、[IP セキュリティ モニタ] MMC スナップインを使用すると、アクティブなポリシーの別の部分を確認できます。

Windows Server 2003 のローカル ポリシーを削除して再読み込みを行う場合は、Windows XP の場合と同じコマンドを使用します。 netsh ipsec コマンドを使用すると、ポリシーの割り当ての解除、再割り当て、削除を行うことができます。

Active Directory IPsec ポリシー

このポリシーは、Windows 2000、Windows XP、および Windows Server 2003 でサポートされています。 割り当てられたドメイン IPsec ポリシーは、ローカル レジストリの次の場所に保存されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

ドメイン ポリシーのローカル レジストリ キャッシュは、次の場所に保存されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Cache

ディレクトリ ストアの管理は、[IP セキュリティ ポリシーの管理] MMC スナップインを使用するか、Active Directory に対して netsh ipsec コマンドをローカル プロセスとして実行することで行います。 キャッシュの内容を直接確認できるツールはありません。 レジストリ ツールは、キャッシュの有無とキャッシュに正しい内容が格納されているかどうかの確認に使用します。 同様に、レジストリ ツールを使用して GPTIPsecPolicy および Cache レジストリ キーを削除すると、ドメイン ポリシーを削除できます。 この場合、IPsec サービスを再起動するか、サービス制御コマンドを使用してドメイン ポリシーなしで IPsec ポリシーの再読み込みを強制的に行う必要があります。

ドメインベースの IPsec ポリシーの割り当てを更新して IPsec ポリシーの再読み込みを行い、キャッシュの内容を更新するには、gpudpate /force を使用します。

ドメイン ポリシーのローカル コンピュータへの適用を一時的にブロックするには、ローカル システム アカウントへの読み取りアクセスを拒否するように GPTIPsecPolicy および Cache レジストリ キーの権限を設定します。 [IP セキュリティ モニタ] MMC スナップインおよびコマンドライン ツールを使用した場合、ローカル管理者ユーザーの環境で実行されている GPTIPsecPolicy 情報が読み取られるため、ドメイン ポリシーは依然として割り当てられている状態で表示されます。 ドメインベースの IPsec ポリシーを長期間ブロックする場合は、コンピュータで Active Directory の 適切な GPO の読み取りをできなくする必要があります。

Windows 2000 では、ポリシーに問題がある場合、次のようなエラーが表示される可能性があります。

  • Directory スキーマにバインドできませんでした。: IPsec ポリシー エージェント サービスで、認証済みの LDAP を Active Directory の IP Security Policies コンテナにバインドできませんでした。 このエラーは、コンピュータ アカウントが正常なログインに失敗し、Kerberos 資格情報の取得にも失敗した場合に発生すると考えられます。 また、Kerberos プロトコルで IPsec ポリシー エージェント サービスに LDAP サービス チケットを発行できなかった場合にも発生する可能性があります。

  • IPSEC ポリシーの記憶域オブジェクトにバインドできませんでした。: 現時点で存在しない IPsec ポリシーのオブジェクトが定義されました (規則やフィルタ一覧など)。 IPsec ポリシーが破損しているか、Active Directory の記憶域ポリシーが破損しているか、またはオブジェクトが削除された (ただし、既存の IPsec ポリシーはこのオブジェクトをまだ参照している) 可能性があります。 [IP セキュリティ ポリシーの管理] MMC スナップインを使用して IPsec ポリシーをチェックし、すべてのポリシー規則に損傷がなく、[プロパティ] の [全般] タブにある [キー交換の設定] が正常に表示されることを確認します。

  • ドメイン コントローラが見つかりませんでした。 コンピュータがドメインのメンバであるか、またはネットワークに接続されているか確認してください。: IPsec ポリシーの記憶域モジュールが、ドメインベースの IPsec ポリシーを取得するための LDAP ディレクトリを検出できませんでした。

  • ドメイン コントロール上のディレクトリ サービスと通信できませんでした。 システム管理者に問い合わせてください。: IPsec 記憶域モジュールが、割り当てられた IPsec ポリシーをダウンロードする際に LDAP の署名と封印を正常に使用できませんでした。

  • 記憶域にオブジェクトが見つかりませんでした。: 通常、これは深刻なエラーです。IPsec ポリシーを完全に取得できていないため、このポリシーは正常に機能しません。 IPsec ポリシーの記憶域モジュールは、LDAP 呼び出しまたはリモート レジストリ呼び出しのいずれを使用しても、IPsec ポリシーまたはいずれかの規則に格納されているオブジェクト (規則、フィルタ一覧、フィルタ操作、ISAKMP の設定など) の GUID を検出できませんでした。 このエラーは、次のいずれかの原因により発生します。

    • 複製の遅延により、参照されるオブジェクトが到着する前に参照するオブジェクトが到着した場合。または、クエリが 2 つの異なるドメイン コントローラに対して実行されている場合。

    • IPsec ポリシーでオブジェクトを使用しているときに、そのオブジェクトが削除された場合。

    • オブジェクトに列挙機能や読み取り機能を拒否する権限が与えられている場合。または、IPsec ポリシーの記憶域が、オブジェクトが存在していなかった時機のものに復元された場合。

    • IPsec ポリシーの破損により、クエリ内の GUID が無効になった場合。

    • 宛先 IP アドレスにネットワークで接続できない場合。

    • LDAP またはリモート レジストリ サービスを利用できない場合。

  • 要求された操作を完了できません。 ポリシーの記憶域が開かれていません。: Active Directory、リモート コンピュータ、またはローカル コンピュータのストアを開けません。 このエラーは通常、アクセス許可または認証の失敗が原因で発生します。

  • (i) Active Directory 記憶域ポリシーがない、または (ii) Active Directory 記憶域ポリシーが正しく適用されず、キャッシュされたポリシーがないので、アクティブなローカル レジストリ ポリシーを使用します。: このイベントは、IPsec ポリシーがローカルのコンピュータ上で定義されているため、ドメインベースのポリシーを適用して上書きすることができなかったことを示します。

  • (1) Active Directory 記憶域ポリシーまたはアクティブなローカル レジストリ ポリシーがない、または (2) Active Directory 記憶域ポリシーが正しく適用されず、キャッシュされたポリシーまたはアクティブなローカル レジストリ ポリシーがないので、IPSEC ポリシーは使用されません。: このイベントは、ポリシーがコンピュータに割り当てられていないときの既定の状態を示します。

Windows XP および Windows Server 2003 では、次のイベントが発生した場合、IPsec サービスが特定の種類のポリシーを取得できなかったことを示します。 Windows Server 2003 および Windows XP SP2 でローカル ポリシーを正常に読み取れない場合、そのポリシーは無視され、継続の順序として次に割り当てられるポリシーを読み取ります。

  • PAStore Engine は固定記憶域 IPSec ポリシー ""<ポリシー名>"" をコンピュータに読み込むことができませんでした。エラー コード: <番号> : 継続ポリシーが割り当てられていてローカル レジストリに保存されているものの、継続ポリシー オブジェクトの少なくとも 1 つのオブジェクトの内容を読み取れなかったことを IPsec サービスが検出しました。 すべてのレジストリ キーのアクセス許可を確認してください。 ポリシーが破損している可能性があります。 継続ポリシーをすべて削除して、再作成します。

  • PAStore Engine はローカル記憶域 IPSec ポリシー ""<ポリシー名>"" をコンピュータに読み込むことができませんでした。エラー コード: <番号> : ローカル ポリシーが割り当てられていてポリシーを読み取ろうとしているものの、割り当てられたポリシーに関連付けられているオブジェクトの少なくとも 1 つを読み取る際にエラーが発生したことを IPsec サービスが検出しました。 すべてのレジストリ キーのアクセス許可を確認してください。 ポリシーが破損している可能性があるため、ポリシーを削除して再作成します。

  • PAStore Engine はディレクトリ記憶域 IPSec ポリシー ""<ポリシー名>"" をコンピュータに読み込むことができませんでした。エラー コード: <番号> : IPsec サービスが割り当てられた IPsec ポリシーを Active Directory から読み取るときに、少なくとも 1 つのエラーが発生しました。 このエラーは、ポリシー オブジェクトをすべて取得する前にネットワーク接続が無効にされた場合、または、IPsec ポリシー オブジェクトが見つからないか読み取りアクセス許可を与えられていない場合に発生する可能性があります。

  • PAStore Engine は Active Directory IPSec ポリシーをポーリングして変更を調べました。Active Directory に到達できなかったので、キャッシュ化された Active Directory IPSec ポリシーのコピーを使用することにしました。 前回のポーリング以降に Active Directory IPSec ポリシーに行われた変更は適用できませんでした。: このメッセージは、IPsec サービスが定期的なポーリング間隔で Active Directory と正常に通信できなくなり (DNS サービスの中断などのため)、現在のアクティブな IPsec ポリシーの変更が不可能になったことを示しているにすぎません。 アクティブなポリシーが適用された段階では Active Directory に接続できる状態だったため、IPsec サービスは最新のバージョンを取得してキャッシュに保存していると考えられます。 したがって IPsec サービスは、この時点では IPsec ドメイン ポリシーのレジストリ キャッシュをポリシーのプライマリ ソースとして扱います。 ただし、ディレクトリとの接続を試行するポーリングは続行されます。  

IPsec ポリシーの解釈に関するトラブルシューティングを行う

IPsec ポリシーの解釈は、適切な保存場所からポリシー全体を正常に取得した後で行われます。 現在のネットワーク インターフェイス IP アドレスを使用して、ポリシーの汎用フィルタが特定のフィルタに拡張されます。 その後、特定の受信/送信フィルタのリストが IPsec ドライバに読み込まれ、これによってパケットが処理されます。 インターフェイス変更イベントが IPsec サービスに送信されます。このイベントでは、必要に応じて、できるだけ迅速に IPsec ドライバ内の IPsec フィルタ構成が調整されます ("このコンピュータの IP アドレス" フィルタなど)。

Windows 2000 では、ポリシーを強制的に適用する IPsec コンポーネントの適切に解釈または構成が行われる際に問題が発生した場合、次のようなメッセージが表示されることがあります。

  • データ型属性に認識されないデータ形式が指定されています。: IPsec ポリシーの一部に、ポリシー記憶域エンジンで認識されていないデータ形式が含まれています。 このエラーは、ポリシーが破損していることを示しています。または、同じ箇所で今後ポリシー バージョンに関する問題が発生することも考えられます。 Windows XP および Windows Server 2003 の IPsec ポリシー機能は、Windows 2000 IPsec ポリシー エージェントで解釈できるように設計されています。

  • BLOB のデータの読み取ることができませんでした。: IPsec ポリシー オブジェクトの IPsecData 属性のデータ形式が、想定されていない形式です。 このエラーは、ほとんどの場合、ポリシーの破損かバージョンに関する問題の発生を示しています。 すべての IPsec ポリシー設定を正しく適用するには、その前にこのエラーを修正する必要があります。

  • ポリシー エージェントにインターフェイスの一覧がありません。: IPsec ポリシー エージェントが、フィルタリングを実行する IP ネットワーク インターフェイスを検出しませんでした。 このメッセージの内容は、Windows ソース コードから直接引用されたものです。一部誤りがありますが、エラー メッセージとしてはこのまま表示されます。

  • Ip Public Help Api はインターフェイスの表を取得できませんでした。 インターフェイスに基づいたフィルタは Ipsec ドライバへの展開や組み込みが行われません。: IPsec ポリシー エージェントがコンピュータ上のインターフェイス リストを列挙しようとしたときにエラーが発生しました。 ネットワーク インターフェイスが存在しないか、ネットワーク インターフェイス マネージャ内に内部エラーが存在する可能性があります。 完全な PnP 準拠ではないデバイス、ファイルの破損、または NIC ドライバ内部か関連するその他の Windows ネットワーキング コンポーネントの問題が原因と考えられます。 すべての接続ではなく特定の種類の接続 (リモート アクセスなど) を対象にした規則で構成されたフィルタのような IPsec フィルタは、インターフェイスの種類に基づきます。 再起動しても問題が解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。

  • Ip Public Help Api は IP アドレスの表を取得できませんでした。 インターフェイスに基づいたフィルタは Ipsec ドライバへの展開や組み込みが行われません。: IPsec ポリシー エージェントが IP Helper API の関数呼び出しを用いてコンピュータ上のすべての IP アドレスを列挙しようとしたときにエラーが発生しました。 IP アドレスが設定されていないか、上の項目と同様の問題が発生している可能性があります。

  • IP アドレス エントリ インデックスがインターフェイスの表にありませんでした。 IP アドレスを破棄します。: IPsec ポリシー エージェントは、ネットワーク インターフェイス リストにすべての IP アドレスが登録されていることを確認します。 一時的に新しいネットワーク インターフェイスを追加するか既存のネットワーク インターフェイスを削除した場合、この問題が発生する可能性があります。 このメッセージが意味することは、ポリシーの汎用的な "このコンピュータの IP アドレス" フィルタして使用するために、この破棄された IP アドレスに対応する特定のフィルタを IPsec サービスは作成しないということです。したがって、この IP アドレスを使用すると予期しない一時的な接続動作として現れることがあります。 このエラーはまた、IP インターフェイス構成の内部の状態に問題があることを示している場合もあります。この問題については、マイクロソフトの製品サポート サービスが詳しく調査します。 TCP/IP スタックではなく IPsec ポリシー エージェントが IP アドレスを破棄するため、この IP アドレス用の IPsec フィルタは作成されません。 したがって、セキュリティ操作 (許可やブロックなど) や IPsec SA のネゴシエーションは、この IP アドレスを使用しているトラフィックに対しては実行されません。

  • フィルタ一覧の中に一致するフィルタ ミラーが存在します。: このエラーは、IPsec ポリシーのフィルタ条件が重複していることを示します。 IPsec ポリシーの設計を分析して、受信/送信方向の特定のクイック モード フィルタで重複が発生していないか確認する必要があります。

  • メインのフィルタ一覧にフィルタは追加されませんでした。: IPsec ポリシー エージェントにより、記憶域から取得したフィルタが IPsec ポリシーに含まれていないことが検出されました。 IPsec ポリシーに既定の応答規則しか含まれていないか、規則またはフィルタ一覧を読み取るときにエラーが発生した可能性があります。

  • フェーズ 1 のオファー数が 0 です。 ISAKMP ポリシーを破棄します。: IKE メイン モードのセキュリティ メソッド (ISAKMP ポリシー オブジェクト) が見つからない場合は、IPsec ポリシーが破損していると考えられます。

  • フェーズ 2 のオファー数が 0 です。 ネゴシエーション ポリシーを破棄します。: フィルタ操作のセキュリティ メソッド (IKE クイック モードのフェーズ 2 のオファー) が設定されていない場合、対応するフィルタと一致するトラフィックに対して行われる IKE のクイック モード ネゴシエーションは失敗します。 IPsec ポリシーが破損していると考えられます。

  • ポリシーに有効なオファーが含まれていません。: IPsec ポリシーで、フィルタ操作規則に有効なセキュリティ メソッドが含まれていないか、IKE メイン モードの設定 ([全般] タブの [キー交換の設定] で構成) が含まれていません。

  • ポリシー エージェントは既存のフィルタの IPSEC への挿入を試みました。: IPsec ドライバによって重複フィルタが検出され、その重複フィルタが拒否されました。 IPsec ドライバに既に適用されているフィルタ操作と同じものが重複フィルタにも設定されている場合は、特に問題は発生しません。 ただし、フィルタ操作が異なる場合、この IPsec ポリシー設計はサポートされません。 経過時間やポリシーの変更処理の順序によって、結果が異なる場合があります。 IPsec ポリシーを設計する場合、フィルタを重複させないように注意してください。

  • IPSEC ポリシー テーブルにエントリを追加できませんでした。: IPsec ポリシー エージェントが新しいフィルタを IPsec ドライバに追加できませんでした。 このエラーが発生した場合、そのフィルタと一致するトラフィックはセキュリティ保護されません。 このエラーは、カーネル メモリが不足している場合に発生する可能性があります。 エラーが解決しない場合は、マイクロソフトの製品サポート サービスまでお問い合わせください。

  • ポリシー エージェントはフィルタを IPSEC に挿入または更新できませんでした。: フィルタの挿入に関する上のメッセージと同じく、IPsec ドライバ内のフィルタのリストが、割り当てられている IPsec ポリシーで必要とされるリストと一致しません。 したがって、セキュリティはそのとおりに機能していません。

  • Active Directory の記憶域ポリシーが正しく適用されなかったので (ネットワークに到達できない、ポリシーの整合性が無効、など)、キャッシュされたポリシーを使用します。: ドメインベースの IPsec ポリシーを割り当てると、IPsec ポリシー エージェントはまず Active Directory から最新のポリシーを読み取ろうとします。 このメッセージは、ディレクトリから IPsec ポリシーを取得できなかったため、レジストリにキャッシュされている最新のドメイン ポリシーを使ってポリシーを適用していることを示しています。  

Windows Server 2003 では、IPsec ポリシーを解釈するときに問題が発生した場合、次のようなイベントが発生する可能性があります。 多くの場合、Windows XP でも同じイベント テキストが使用されます。 IPsec ポリシーを正常に機能させるには、これらの問題を解決する必要があります。

  • PAStore Engine は固定記憶域 IPSec ポリシー ""<ポリシー名>"" をコンピュータに適用できませんでした。エラー コード: <番号> : IPsec サービスはレジストリで構成済みの継続ポリシーを検出しましたが、一部を正常に適用できませんでした。 別のメッセージのところで説明したように、既に適用されている継続ポリシーは削除され、Psec ドライバは boottime 適用除外リストにより自動的にブロック モードに設定されます。

  • PAStore Engine はローカル レジストリ記憶域 IPSec ポリシーを ""<ポリシー名>""のコンピュータに適用できませんでした。エラー コード:<番号> : このメッセージは、サービスがローカル レジストリからローカル IPsec ポリシーを適用するときに、少なくとも 1 つのエラーが発生したことを示します。 また、ポリシーが破損しているか、許可設定に誤りがあることを示している場合もあります。

  • PAStore Engine は Active Directory 記憶域 IPSec ポリシーを DN ""<CN=ipsecPolicy{GUID}"" のコンピュータに適用できませんでした。エラー コード:<番号> : IPsec サービスは、GPTIPsecPolicy レジストリ キーの DN で指定されているドメイン ポリシーを検出しましたが、これを適用できませんでした。 このメッセージは情報として提供されるものであり、多くの場合、ドメイン コントローラがモバイル クライアントにアクセスできないことを通知するものです。このメッセージが表示された場合は、キャッシュに保存されているポリシー (存在する場合) を正しく適用する必要があります。 ただし、GPO が配布している IPsec ポリシーが存在しないか、読み取ることができないか、破損しているポリシーであることを示す場合もあります。

  • PAStore Engine は Active Directory 記憶域 IPSec ポリシーのローカルにキャッシュされたコピーを ""<ポリシー名>"" のコンピュータに適用できませんでした。エラー コード:<番号> : このメッセージは、IPsec サービスがドメイン ポリシーを割り当てる必要があることを認知しているものの、Active Directory から取得したポリシーの適用に既に失敗したことを示しています。 割り当てられたドメイン ポリシーのキャッシュ コピーをローカル レジストリから適用する際に、少なくとも 1 つのエラーが発生しています。 また、キャッシュが破損しているか、許可設定に誤りがあることを示している場合もあります。 ドメインベースのポリシーをどれも適用できない場合、他の分離ドメインのメンバとの接続に影響する可能性があるため、これは深刻な事態です。 順番として、ローカル ポリシー (定義されている場合) が次に適用されます。

  • PAStore Engine はアクティブな IPSec ポリシー ""<ポリシー名>"" のいくつかの規則をエラー コード <番号> によりコンピュータに適用できませんでした。 IPSec モニタのスナップインを実行して問題を診断してください。: この問題は通常、クイック モードのセキュリティ メソッド (オファー) が存在しない場合など、ここで紹介している他の問題と同時に発生します。

  • IPSec サービスはコンピュータのネットワーク インターフェイスの完全な一覧を取得できませんでした。 IPSec フィルタが適用されることによる保護を受けることができないネットワーク インターフェイスがいくつか発生するので、これはセキュリティへの危害となります。 IPSec モニタのスナップインを実行して問題を診断してください。: このメッセージは、Windows 2000 で表示されるいくつかの IP Helper API メッセージに代わるものです。 インターフェイスの追加や削除を行ったときや接続状態が変化したとき (ワイヤレス ネットワークの範囲内から外れた場合など) に発生した場合、これは特に害のあるエラーではありません。 また、スタンバイ モードや休止状態モードから再開するときや、再開時に別のネットワーク インターフェイス構成が検出されたときに発生した場合も、特に害はありません。  

RRAS VPN のポリシー構成に関する問題

この章の第 1 層のサポートに関するセクションで説明したように、RRAS サービスは、一部の組織で発生する IPsec ポリシーの競合の一般的な原因です。 このセクションでは、L2TP/IPsec VPN サーバーのビルトイン IPsec ポリシーとこのソリューションで使用するドメイン ポリシーの間で競合が発生する理由について説明します。 この状況は、重複フィルタに関する問題の一例です。

ここでは、Woodgrove Bank シナリオで使用される IPsec ポリシー設計を使って説明を進めますが、 その原理は、企業規模の IPsec 展開のさまざまな例に適用することができます。

L2TP/IPsec サーバー用の IPsec ポリシーは、RAS Manager サービス (RASMAN) によって自動的に生成されます。このポリシーには次のフィルタが割り当てられます。

  • 任意の IP アドレスからこのコンピュータの IP アドレス、UDP、発信元 1701、宛先 任意 (受信)

  • このコンピュータの IP アドレスから任意の IP アドレス、UDP、発信元 任意、接続先 1701 (送信)

    注 : このポリシーの詳細については、マイクロソフト サポート技術情報 248750「L2TP/IPSec に作成された IPSec ポリシーの説明」を参照してください。

結果的に、このサーバーに対する IKE ネゴシエーションの応答を制御するメイン モード固有のフィルタは、受信フィルタのアドレス部分になります。

  • 任意の IP アドレスからこのコンピュータの IP アドレス -> 証明書認証

"このコンピュータの IP アドレス" を使用すると、受信フィルタが VPN サーバーの各 IP アドレス用に拡張されるため注意が必要です。 VPN サーバーにインターネット接続用の外部インターフェイス IP アドレスと LAN 接続用の内部インターフェイスがある場合、IKE メイン モード固有の受信フィルタは次のようになります。

  • 任意の IP アドレスから <外部インターフェイス IP アドレス> -> 証明書認証

  • 任意の IP アドレスから <内部インターフェイス IP アドレス> -> 証明書認証

2 つ目の内部 LAN インターフェイス用のフィルタは、次に示すように、サーバー/ドメイン分離の IKE メイン モード受信フィルタより具体的な内容になります。

  • 任意の IP アドレスからサブネット -> Kerberos 認証

結果として、管理者が信頼されたクライアントを使用して VPN サーバーを管理している場合は、VPN サーバーの内部 IP アドレスに対して IKE が開始されます。 IKE 受信ポリシーで検索を実行すると、さらに具体的なメイン モード フィルタとの照合が行われ、L2TP の IKE メイン モード設定で結果が返されます。 ここでは、このソリューションで使用している Kerberos 認証ではなく証明書認証が使用されます。

第 2 のケースとして、インターネット VPN クライアントが接続マネージャ クライアントの検疫機能を使用した場合に競合が発生します。 検疫クライアントは、検疫を完了してネットワークに対する VPN フル アクセスを取得するために、VPN サーバーの内部 LAN IP アドレスに "検疫キー" を渡す必要があります。 このシナリオでは、VPN クライアントのドメイン IPsec ポリシーは、ラップトップの起動時にキャッシュから適用されます。 VPN 検疫接続が正常に確立されると、内部 IP アドレスが VPN クライアントに割り当てられます。 クライアントの内部 IP アドレスは、ドメイン分離 IPsec ポリシーで定義されたサブネット フィルタ (Any <-> Internal Subnet) のいずれかでカバーされます。 このフィルタは、VPN クライアントが VPN トンネルを介して内部サーバーおよびその他のアクセスする可能性のあるワークステーションとエンドツーエンドの IPsec 認証アクセスを行うために必要です。

ただし、このソリューションのサブネット フィルタは、クライアント VPN トンネル仮想インターフェイスの内部 IP アドレスから VPN サーバーの内部 LAN インターフェイスに対して、IKE ネゴシエーションを開始します。 サーバーは証明書認証のみを受け入れると応答するため、IKE メイン モードは失敗します。証明書認証は、ドメイン/サーバー分離で使用するポリシーに対応していません。 ポリシーで証明書認証が許可されていない場合でも、クライアントから行われる IKE クイック モードではすべてのトラフィックへのフィルタ適用が提案されます。ただし、提案されたフィルタは具体性に設定されたものではないため、VPN サーバーはネゴシエーションに失敗します。 VPN サーバーは、L2TP 固有のクイック モード フィルタ (UDP 発信元 1701、宛先 任意、または UDP 発信元 1701、接続先 1701) のみを受け付けます。

RRAS サーバーの L2TP/IPsec ポリシーと分離ポリシーの間の競合を解消するには、次の方法を使用します。

  • RRAS サーバーの内部 LAN IP アドレスを適用除外リストに登録する。

  • VPN サーバーの L2TP ポートを無効にして、 PPTP のみを使用する。

  • RASMAN 用の ProhibitIPsec レジストリ キーを使用して、L2TP の自動 IPsec ポリシーを無効にする。 UDP 1701 トラフィックに対しては証明書認証用の外部 IP アドレスのみを使用し、すべてのトラフィックに対しては内部 IP アドレスを使用するドメイン分離用の Kerberos 認証のみを使用するには、L2TP の IPsec ポリシー構成を手動でカスタマイズします。

    注 : この構成の詳細については、マイクロソフト サポート技術情報 240262「仮共有キー認証を使って L2TP/IPSec 接続を構成する方法」を参照してください。

ここに挙げた解決方法の中で最も簡単なものは、最初に挙げた、RRAS サーバーの内部 NIC が IPsec を使用できなくする方法です。

IKE のトラブルシューティングを行う

IKE と IPsec の不具合は、ネットワーク フィルタリングで UDP 500 または IPsec プロトコル パケットが許可されていないため、最初の展開時に最もよく発生します。 そのため、事前共有キーを使用する定義済みのサンプル サーバー (要求) ポリシーなど、単純なポリシーを割り当てた静的 IP ワークステーションまたはサーバーをテスト用に用意しておくと便利です。 IKE 監査イベントを取得するには、監査を有効にする必要があります。 既定のドメイン IPsec ポリシーは、同じ事前共有キーで認証を行うすべてのドメイン メンバに展開されます。このポリシーには、テスト コンピュータの IP アドレスに送信されるすべてのトラフィック (ICMP を含む) に対応した 1 つのフィルタという形で、1 つの規則が格納されています。

次に、ドメイン ログオン スクリプトが展開され、 <testserver> または nbtstat –n <testserver> の ping が実行されます。その結果、すべてのドメイン メンバからテスト サーバーに対して IKE ネゴシエーションが開始されます。 IKE メイン モードの成功監査の IP アドレスを分析してまとめておくと、すべてのコンピュータがポリシーを受信しているかどうか、また、IKE および IPsec プロトコルを使用してネットワークのどのエリアからでもテスト コンピュータにアクセスできるかどうかを確認できます。

さらに高度なテストを行うと、ネットワークの各エリアで IPsec のカプセル化を行うと断片化が発生するかどうかを確認できます。このテストを行うには、テスト サーバーから各エリアのコンピュータに対して、 ping –l 5000 <IP address> を使用します。 –l 5000 オプションを指定すると、5000 バイトの ICMP パケット ペイロードが作成されます。 このフル IP パケットは、IPsec プロトコルによってカプセル化され、送信される前にワイヤ上の IP 層によって断片化されます。 すべての断片が送信先で受信される必要があります。受信が完了すると、同じ数の断片で構成された応答が返信されます。 過去のデータによれば、デバイスが密集している場合、または速度の異なるネットワーク (1 ギガビットと 100 メガビットのイーサネットなど) の境界の役割を果たしている場合には、断片の通過時に問題が発生する可能性があります。 同様に、異なる MTU リンク (非同期転送モード (ATM)、光ファイバ分散データ インターフェイス (FDDI)、トークン リングなど) に位置するホストでは、IPsec で保護された TCP パケットのネットワーク パス MTU を正しく検出するため、ICMP PMTU メッセージが必要になります。 さまざまなネットワーク MTU の既定の設定については、マイクロソフト サポート技術情報 314496「各種ネットワーク トポロジの既定の MTU サイズ」を参照してください。

IKE ネゴシエーションのトラブルシューティングを行う

IKE の場合、通常は応答側のコンピュータからのみ IKE クイック モードを開始する場合など、特定の条件下でしかエラーが発生しないことがあるため、トラブルシューティングの実施は困難です。 Kerberos プロトコル エラー、互換性のないポリシー設計、または既存のポリシーがドメイン ポリシーに統合された場合など、認証システムの問題が原因でエラーが発生することもあります。 IKE に障害が発生すると、障害を起こしているコンピュータは IKE ネゴシエーションへの参加を中断します。そのため、ネゴシエーションの相手にあたるコンピュータは通常、再試行回数の上限に達してタイムアウトになります。 IKE が失敗した場合、何も変更せず、まず障害の内容を確認してログを取得するようにしてください。 標準の監査は、IPsec 構成やサービスの実行状態を変更しなくても動的に有効にすることができます。 ただし、Windows 2000 で IKE の詳細なログが Oakley.log ファイルに記録されるようにするには、IPsec サービスを再起動する必要があります。Windows XP SP2 および Windows Server 2003 では、IKE ログ記録は、コマンドラインから必要に応じて有効または無効にすることができます。

場合によっては、ネットワーク トラフィックの調査を行いクリーンな状態からの Oakley.log ファイル結果を取得するため、IPsec サービスを停止して再起動します。 IPsec サービスを手動で停止するか、コンピュータの再起動またはシャットダウンのプロセスに組み込んで停止すると、IKE は削除メッセージを送信して、接続されているすべてのアクティブなピアの IPsec SA 状態をクリーンアップしようとします。 削除メッセージをアクティブなすべてのピアに送信する作業が IKE によって実行される前に、オペレーティング システムによりパケットの送信機能が無効にされる場合もあります。この場合、IPsec SA の状態はピアにそのまま残されます。 このような場合、ピアは、再起動中のコンピュータに安全に接続されていると解釈します。 再起動後にコンピュータがピアに対して新しい IKE ネゴシエーションを開始しない場合は、5 分が経過して IPsec SA がタイムアウトになるまで IPsec SA は再確立できません。 SA を再確立する場合は、まずクイック モード ネゴシエーションを 1 分間試行し、その後、IKE メイン モードを開始します。

IKE ログ記録は、Windows 2000 以降、リリースごとに改良が加えられています。 ここで説明するイベントは、Windows XP および Windows Server 2003 に適用されるものです。ただし、Windows 2000 のイベントも基本的には同じ内容です。

IKE ネゴシエーションが失敗した理由を特定する場合、まず最初に Windows セキュリティ ログを使用することをお勧めします。 IKE のイベントを確認するには、グループ セキュリティ ポリシーの [ログオン イベントの監査] 設定で監査を有効にして、成功したか失敗したかを確認できるようにする必要があります。監査機能を有効にすると、IKE サービスにより監査エントリが作成され、ネゴシエーションが失敗した理由が説明されます。 ただし、IKE ネゴシエーションの失敗に関する説明は、ほとんどの場合、イベント 547 エラーとして報告されます。また、エラー メッセージは同じでも、複数の原因が存在する場合があります。 イベント 547 エラーとその発生原因については、以降のセクションで詳しく説明します。

Windows XP SP2 および Windows Server 2003 では、DisableIKEAudits レジストリ キーですべての IKE 監査を無効にすることができます。 調査するコンピュータのこの値を必ず確認してください。 IKE 監査によって生成される成功/失敗イベントが多すぎるため、ログオン/ログオフ カテゴリのその他のイベントを効果的に監視できない場合は、IKE 監査を無効にします。

エラー コード値は、多くの場合、IKE 監査イベントとログの詳細で報告されます。 エラー コード値の詳細については、Microsoft MSDN® Web サイトの「System Code Errors (12000-15999)」ページ (英語) を参照してください。

IKE ネゴシエーションのトラブルシューティングを行うには、IPsec ポリシー設計で予想される動作、IKE ネゴシエーションのプロセス、および IKE エラー イベントに関する詳しい知識が必要です。 ここでは、Woodgrove Bank のドメイン分離シナリオに関連する最も一般的なイベントに関してのみ説明します。 すべての IKE 監査イベントおよび障害状況については扱いません。

IKE ネゴシエーションのプロセスを十分に理解したら、可能な場合は、Oakley.log ファイルを収集する前に最低でも通信の一方の側からネットワーク トレースを取得して、IKE 内の問題を特定してください。 サーバー/ドメイン分離シナリオで展開対象とするサーバーでは、ネットワーク モニタでトレースを取得する機能が必要になります。

Oakley.log ファイルを使用すると、最も詳細なログ記録を参照できます。このログ ファイルは、ネゴシエーションの両端で (時刻を同期させた状態で) 取得する必要があります。 ただし、このログを有効にすると、IKE ネゴシエーションの速度が低下する可能性があります。そのため時刻設定条件が変化し、サービスを再起動してレジストリ キーの再読み取りを行った場合 (Windows 2000 および Windows XP SP1 で必須)、既存の状態がすべて失われます。 現時点では、Oakley.log ファイルの解読方法に関するガイダンスは公開されていません。 このガイドでは、Oakley.log ファイルの解読は、第 3 層のサポートで使用されるスキルの一部として扱います。 ここではスペースの関係上、ログの詳細からいくつかのエラーに関する記述のみを抜粋して紹介します。 Oakley.log ファイルの解読方法については、マイクロソフトの製品サポートまでお問い合わせください。

IKE では、次の 4 つの詳細なログ ファイルが使用されます。

  • Oakley.log: IKE の最新のログが記録されています。上限は 50,000 行です。

  • Oakley.log.bak: Oakley.log が 50,000 行を超えた場合、このファイルが作成され、空の Oakley.log ファイルへの記録が新たに開始されます。 このファイルは、IPsec サービスが実行されている間、新しい Oakley.log ファイルによって繰り返し上書きされます。

  • Oakley.log.sav: IPsec サービスを起動すると、この名前で前回の Oakley.log ファイルが保存されます。

  • Oakley.log.bak.sav: IPsec サービスを起動すると、この名前で前回の Oakley.log.bak ファイルが保存されます。

トラブルシューティングを行う際に重要なことは、ログ記録を取得するコンピュータとネットワーク トレースを取得するコンピュータの、2 台のコンピュータの時刻を同期させることです。 時刻を同期させないと、ログの相関関係の解釈が、不可能ではないまでも困難になります。 IKE のメッセージとネットワーク トレース内のパケットの相関関係は、ISAKMP ヘッダーのクッキーと IKE クイック モード メッセージ ID フィールドを使用して照合する必要があります。

想定されている IKE の動作

ネットワークによって IKE メイン モードの開始がブロックされ、目的の宛先 IP アドレスに接続できなかった場合、IPsec でセキュリティ保護された通信をネゴシエートできません。 開始側でクリアテキストへのフォールバックが設定されていない場合、宛先との接続エラーがシステム ログの監査イベント 547 として報告されます。このイベントには、次のいずれかのテキスト エントリが表示されます。

  • ピアから応答がありません

  • ネゴシエーションがタイムアウトしました

  • IKE SA は確立が完了する前に削除されました  

ただし、ドメイン分離クライアントのポリシーでクリアテキストへのフォールバックが許可されている場合、この状態はエラーとして報告されないことがあります。 ソフト SA が確立されると、IKE メイン モードの成功イベント 541 が生成されます。 541 イベントがソフト SA を示している場合、送信 SPI はゼロ (0)、すべてのアルゴリズムはなし (None) と表示されています。 次の例は、541 イベントでこれらのパラメータがどのように表示されるかを示したものです。

ESP Algorithm None
HMAC Algorithm None
AH Algorithm None
Encapsulation None
InboundSpi 31311481 (0x1ddc679)
OutBoundSpi 0 (0x0)
Lifetime (sec) <whatever is configured for QM lifetime>
Lifetime (kb) 0

: ソフト SA イベントには、宛先 IP アドレスが同じ場合でも異なるタイムスタンプと異なる受信 SPI 値が割り当てられます。

2 台のコンピュータ間にアクティブな IKE メイン モードが存在するかどうかに関してそのコンピュータ同士が同期されていない場合、1 分間の接続遅延が必ず発生します。 一方のコンピュータでアクティブな IPsec SA ペアの存在が想定されており、他方のコンピュータ (サーバーなど) ではその SA が削除されていてクイック モード キー更新も開始されていない場合は、5 分間の遅延が発生する可能性があります。 Windows 2000 の IKE では単一の削除メッセージがサポートされていましたが、このメッセージは失われることがよくありました。 Windows XP および Windows Server 2003 では、パケットがドロップされるのを防ぐ保護対策として複数の削除メッセージを使用するという "信頼性の高い" 削除機能サポートが追加されています。

このような状況として最もよくある例は、ドメイン分離ラップトップのユーザーが会議に持って行くためにラップトップをドッキング ステーションから取り外した場合です。 ドッキング ステーションではワイヤード イーサネット接続が使用されています。そのネットワーク インターフェイスを取り外すということは、そのインターフェイスに関連付けられているすべてのフィルタが削除されることを意味します ([このコンピュータの IP アドレス] から拡張されたフィルタの場合)。

ただし、ネゴシエート操作を含むフィルタの場合、ドメイン分離ソリューションの [このコンピュータの IP アドレス] は使用されていません。Any <-> subnet フィルタが使用されています。 これらのフィルタはアドレスが変更されるたびに削除されないため、結果的に、IPsec SA および IKE SA の状態はラップトップ内でアクティブのままです。 フィルタが [このコンピュータの IP アドレス] から拡張されたものである場合、IP アドレスが表示されなくなると、これらのフィルタは削除されます。

IPsec ドライバで任意の種類のフィルタが削除されると、その IP アドレスを使用しているすべての IKE SA および IPsec SA も削除するようにという通知がドライバから IKE に送信されます。 IKE は、これらの SA の削除メッセージを送信して内部的に削除しようとします。 これらの削除メッセージでは、IKE SA で使用されたものと同じ発信元 IP が指定されますが、削除メッセージが送信される時点では、接続されているインターフェイスに異なる発信元 IP が割り当てられている場合があります。 ISAKMP ヘッダー クッキー ペアが認識されており、パケットの暗号化チェックが有効な場合、発信元 IP アドレスはリモート コンピュータにとって重要なものではありません。 ただし、切断 (ラップトップの取り外し) 後の数秒間はネットワーク接続が存在しなくなるため、多くの場合、削除メッセージは送信されません。

この Any <-> subnet フィルタの例の場合、フィルタは削除されません。つまり、IKE および IPsec SA は、すぐには削除されません。 その間、IPsec SA は接続先のリモート コンピュータでタイムアウトになり、IKE クイック モードの削除がラップトップの以前のアドレスに送信されます。 IKE メイン モード SA は、既定ではリモート コンピュータ上で 8 時間動作し続けますが、IKE の内部的な理由により 8 時間が経過する以前に削除されます。 当然、以前の IP アドレスに送信された IKE SA 削除メッセージは、ラップトップで受信されません。 ラップトップをドッキング ステーションに再接続すると、同じ IP アドレスが再度割り当てられます。 ファイル共有や電子メール クライアントなどのアプリケーションは、通常同じ宛先に再接続されます。 ただし、その時点では、ラップトップとこれらのリモートの宛先の間の IKE の状態は異なる場合があります。 ラップトップがまだ IKE メイン モードの状態にある場合は、IKE クイック モード ネゴシエーションが試行されます。 クイック モードではリモート ピアによって削除された暗号化状態が使用されるため、これらのメッセージは認識されず、応答も得られません。 1 分後にラップトップ上の IKE 再試行は制限回数に達し、次に新しい IKE メイン モード ネゴシエーションが試行されて、こちらは正常に完了します。 したがって、ラップトップ ユーザーは、リモート リソースに再接続する場合、1 分間ほど待たなければならないことがあります。 マイクロソフトでは、IPsec に対応しているすべての Windows バージョンでこの動作が改善されるように、今後の更新プログラムで対応していく予定です。

IKE ネゴシエーションは、さまざまな理由でタイムアウトになります。 "ネゴシエーションがタイムアウトしました" イベントは、再試行の制限回数に達して IKE ネゴシエーションの手順 (クリアテキストにフォールバックする場合を除く) が失敗した場合に発生します。ただし、IKE によってネゴシエーションが中止された場合は、"IKE SA は確立が完了する前に削除されました" イベントが発生します。 この 2 つのイベントは、基本的には同じものです。 モバイル クライアントの通常の操作の範囲内では、これらのイベントは多くの場合一般的なものであり特に害はありません。ただし次のようなことが行われた場合、ネットワーク接続の状態は高い頻度で即座に変化します。

  • ユーザーがラップトップ コンピュータをドッキング ステーションに接続した場合、またはステーションから取り外した場合

  • ユーザーがワイヤード接続のケーブルなどを取り外した場合

  • ラップトップ コンピュータが休止状態またはスタンバイ モードになった場合

  • コンピュータがワイヤレス接続の範囲から外れた場合

  • VPN 接続が切断された場合

  • 接続中に PCMCIA ネットワーク カードが取り外された場合

リモート コンピュータで上に挙げたようなことのいずれかが行われると、ピア コンピュータがネットワークからドロップしたような状態になります。 リモート コンピュータは、IKE ネゴシエーションの手順がタイムアウトになるまで、キー更新や再ネゴシエーションを繰り返します。

Windows Server 2003 では、ネゴシエーション タイムアウト エラーが改善されています。ネゴシエーションに成功した最後の手順を特定して、IKE ネゴシエーションのどの段階でタイムアウトが発生したかを確認できるようになっています。 このイベントは、IKE が NAT-T 機能を使用せずにネゴシエーションを行っている場合には、ネットワーク アドレス変換 (NAT) の存在が原因で発生することもあります。 ただし、リモート ピアで IKE ネゴシエーションが失敗する原因となるようなエラーが発生している場合にも、IKE ネゴシエーションはタイムアウトになります。

したがって、ネゴシエーションがタイムアウトして "IKE SA は確立が完了する前に削除されました" イベントが発生したときはどのような場合でも、第 2 層のサポートは、IKE ログがタイムアウトする直前の最大 1 分間に記録されたそのコンピュータの 547 エラー監査イベントを確認して、リモート コンピュータが実際にネゴシエーションに失敗しているかどうかを特定する必要があります。

IKE ネゴシエーションの成功イベント

IKE ネゴシエーションが成功すると、[IP セキュリティ モニタ] MMC スナップインおよびコマンドライン クエリ ツールでそのことを確認できます。

現在の IKE メイン モード SA のリストを表示するには

  • Windows 2000:

    ipsecmon.exe, netdiag /test:ipsec /v

    : このコマンドでは IPsec SA のみが表示されます。IKE メイン モード SA は表示されません。

  • Windows XP:

    IPsec monitor snapin, ipseccmd show sas

  • Windows Server 2003 :

    注 : 表示の関係上、ここでは 1 つの行が複数の行に分割されています。 システムで実際に入力するときは、改行を入れずに 1 行として入力してください。

    IPsec monitor snapin, netsh ipsec dynamic 
    show [mmsas | qmsas]
    

メイン モード SA およびクイック モード SA が成功すると、監査が有効になっている場合にはセキュリティ ログに次のイベントが生成されます。

  • 541: IKE メイン モードまたはクイック モードが確立しました。

  • 542: IKE クイック モードが削除されました。

  • 543: IKE メイン モードが削除されました。

IKE メイン モードの情報ログ エントリ

メイン モードの交換で問題が発生しているかどうかを判断するには、コンピュータのイベント ログで次のログ イベントを確認します。

表 7.5: IKE メイン モードの情報ログ メッセージ

ログ テキスト 説明
新しいポリシーは古いポリシーで作られた SA を無効にしました Windows 2000 のメッセージで、IPsec ポリシーの変更により現在の IKE または IPsec SA が削除されたことを示します。 このエラーは、特に問題になるものではありません。 新しい IPsec SA は、新しい IPsec ポリシーを使用する現在のトラフィック フローに基づいて形成されます。
IKE には、保留中の数多くのセキュリティ アソシエーションの確立要求があり、サービス拒否 (Denial-Of-Service) の防御モードを始めています。 この状態は通常の動作の範囲内です。コンピュータに高い負荷がかかっている場合や、多数のクライアントが接続を試みている場合に発生します。 また、IKE に対してサービス拒否攻撃が行われているためである可能性もあります。 そのような場合は通常、偽装 IP アドレスへの IKE ネゴシエーションが失敗し、それに対する監査が多数行われています。 または、コンピュータが単に、極端な負荷がかかった状態にあります。
IKE メイン モード SA 確立要求が氾濫状態にあると IKE が認識し、サービス拒否攻撃への対応策の一部としてその大部分をドロップする処理を進めている最中です。
IKE は、サービス拒否 (Denial-Of-Service) の防御モードから復旧し、通常の操作を再開しました。 IKE がサービス拒否攻撃と考えられる状況から復旧し、通常の動作を再開しました。
これらのエントリは、通信でエラーが発生したことを示すものではありません。 これらは情報として記録されるものであり、問題の本当の原因を判断するための補足情報として使用します。 ###### IKE メイン モード ネゴシエーションの失敗イベント \#547 IKE メイン モード ネゴシエーションが失敗すると、次の IKE 失敗イベントが発生します。 - **ピアから応答がありません** : このイベントは、IPsec を使用していない、適用除外リストのメンバではないコンピュータへの送信接続で発生します。 ただし、第 2 層のサポートは、IKE ネゴシエーションをブロックする接続上の問題にも注意を払う必要があります。このような問題がある場合にもこのイベントは生成されます。 - **ポリシーが構成されていません** : このイベントは、発信元 IP アドレスが内部サブネット内のアドレスである場合に、問題があることを示します。フィルタ セットの不一致を示すこともあります。 あるいは、特定のアドレス範囲またはサブネットとネゴシエートするための規則がコンピュータに割り当てられていないことを示す場合もあります。 このようなサブネット上にあるコンピュータは、IKE を開始しようとしても、ポリシーが構成されていないため応答が得られません。 - **IKE セキュリティ属性は受け付けられません** : このイベントは、適切に構成されているシステムでは発生しません。 「IPsec ポリシーが正しいことを確認する」の手順に従って調査します。 次に挙げる "ネゴシエーションがタイムアウトしました" のメッセージも、上に挙げた理由によって表示される場合があります。 または、リモート コンピュータで IKE ネゴシエーションが失敗したことを示す場合もあります。 通常、第 2 層のサポートが重点を置いて調査するのは、コンピュータが切断されたことが原因で発生するよくあるネゴシエーションのタイムアウトではなく、リモート コンピュータで発生する IKE のエラーであり、また、IKE メイン モードまたは IKE クイック モード ネゴシエーションで応答側が着信要求を照合する特定のフィルタを検出できなくなるポリシー設計の非互換性の問題です。 - ネゴシエーションがタイムアウトしました - ネゴシエーションがタイムアウトしました。- 最初の SA ペイロードを処理しました。応答側。 デルタ時間 63 - ネゴシエーションがタイムアウトしました。- 2 番目の KE ペイロードを処理しました。発信側。 デルタ時間 63 - ネゴシエーションがタイムアウトしました。- 2 番目の KE ペイロードを処理しました。応答側。 ###### IKE クイック モードの監査の失敗 (547) IKE クイック モード ネゴシエーションが失敗すると、次の IKE 失敗イベントが発生します。 - ポリシーが構成されていません。- 3 番目の ID ペイロードを処理しました。発信側。 - 属性が一致しないため、セキュリティ アソシエーションのネゴシエーションに失敗しました。 - 一般処理エラー - IPSec ドライバから受信 SA のために新しい SPI を取得できませんでした。 - IPSec ドライバとの oakley ネゴシエーションに失敗しました。・・・フィルタが存在しません。 - IPSec ドライバに、セキュリティ アソシエーションを追加できませんでした。 - ネゴシエーションがタイムアウトしました IKE クイック モードは、適切に設計された IPsec ポリシーや通常の運用負荷環境では失敗しません。 これらのエラーのいずれかが報告された場合、第 2 層のサポーまず、「IPsec ポリシーが正しいことを確認する」の手順に従ってください。 次に、これらのイベントとパフォーマンスの異常 (CPU 使用率が 100% である、カーネル メモリの速度が非常に遅い、など) との関連性を確認する必要があります。 既に説明した理由によりコンピュータで以前の IP アドレスが使用されていない場合、ネゴシエーションがタイムアウトして IKE クイック モードは失敗すると考えられます。 ##### 認証に関する IKE エラーのトラブルシューティングを行う 次のメッセージは、IKE 認証エラーに関連するものです。 - 指定された対象は不明か、または到達できません。/認証するときにどの機関にもアクセスできませんでした。 - 指定された対象は不明か、または到達できません。- 最初の SA ペイロードを処理しました。発信側。 デルタ時間 0 - 認証資格情報は受け付けられません - ログオンに失敗しました - Kerberos を使って認証できませんでした - IKE は有効なコンピュータの証明書を検出できませんでした 最初の 2 つのメッセージは、リモート コンピュータの Kerberos ID を使用してリモート コンピュータのサービス チケットを取得できないことを示しています。 このような状況は、信頼されたドメインが存在しないか、ドメイン コントローラにアクセスできない場合に発生します。 "ネットワーク経由でコンピュータへアクセス" の設定が原因で受信 IKE ネゴシエーションが失敗した場合は、アクセス権限を強制的に適用する側の IKE ネゴシエーションによって、前述の 547 イベント "Kerberos を使って認証できませんでした" が報告されます。 このイベントは、"ネットワーク経由でコンピュータへアクセス" 権限の確認の際にエラーが発生したことを示しているとは限りません。したがって、**Oakley.log** ファイルをサーバーから取得し、生成されたエラーの内容を確認する必要があります。 認証されたグループのメンバであることを確認するために、IKE の開始側のグループ メンバシップを調査する必要があります。 コンピュータが認証アクセス権を持つグループのメンバである場合は、新しいメンバシップが反映された Kerberos チケットがコンピュータに存在しない可能性があります。 または、コンピュータで適切な Kerberos チケットを取得できない可能性もあります。 この章で既に説明した「ドメイン コントローラでの接続と認証を確認する」の手順に従ってください。 #### アプリケーションに関連する問題のトラブルシューティングを行う ここでは、Microsoft Windows で IPsec を使用する場合の、アプリケーション設計との相互の影響について説明します。 IPsec ポリシーの設計担当者は、この影響を理解する必要があります。また、サポート担当者は、問題を迅速に分類して特定できるように、この影響が出ているかどうかを認識できる必要があります。 IPsec ポリシーの適用は、アプリケーションに対してかなり透過的である必要があります。 ただし、IPsec ポリシーを割り当てたりトラフィックを保護することで、アプリケーションの動作が変化する場合もあります。 以降のセクションでは、Woodgrove Bank ドメイン分離ソリューションにおける IPsec の影響について説明します。 ##### ICMP は許可されているが、TCP および UDP には IPsec が必要な場合 一部のアプリケーションは、ICMP エコー要求 (Ping) メッセージを使用して宛先アドレスにアクセスできるかどうかを判断します。 たとえば、このソリューションでは IPsec は ICMP トラフィックを保護していません。そのため、アプリケーションは対象となる宛先から ICMP 応答を受信する可能性があります。 ただし、IKE ネゴシエーションが失敗した場合、アプリケーションは IPsec で保護された TCP および UDP トラフィックを使用して対象となる宛先に接続することはできません。 ##### 初期接続の遅延 IKE ネゴシエーションでは、TCP 3 方向ハンドシェイクや認証されない Nbtstat 単一パケットのクエリ/応答よりも、はるかに多くの処理と時間が必要になります。 対象となる宛先から迅速な TCP または UDP 接続応答が返ることを想定しているアプリケーションは、宛先が応答していないと判断し、エラーの報告や代替接続先との接続の試行など、別の作業を実行します。 Kerberos 認証を使用する IKE ネゴシエーションの場合は、通常は 1 ~ 2 秒以内に正常に完了します。 ただし、このタイミングはさまざまな要素により変化します。特に、双方のコンピュータの CPU 使用率やネットワーク パケット損失は大きな要因になります。 クリアテキストへのフォールバックが行われた場合は、TCP ハンドシェイクの最初のパケットを保護していない状態で送信するまでに 3 秒かかります。 ##### ネットワーク応答の待機中に発生するアプリケーションのハングアップ 一部のアプリケーションでは、接続時間やエラー メッセージの受信時間が非常に短く設定されています。 このようなアプリケーションは、接続が完了するまで (ソケット バインド操作が完了するまで) 待機してから、ユーザー インターフェイスに変更結果を表示します。 このアプリケーションのトラフィックが IPsec で保護されている場合、アプリケーションは、正常な接続が確立されるまで一時的にハングアップしたような状態になります。 IKE ネゴシエーションに失敗するか IPsec フィルタによってブロックされたために接続を正常に確立できなかった場合、そのアプリケーションは、強制的に終了するか他の異常なエラーが発生するまで、ハングアップしたままの状態になります。 ネットワーク ソケット層では、IPsec フィルタの存在や IKE がトラフィックのセキュリティをネゴシエートしていることは認識されません。 アプリケーションは通常、このような状況をリモート ホストのダウンやネットワーク障害によるものと解釈します。 ただし、ドメイン コントローラへのアクセスに失敗した場合は、宛先コンピュータが利用できない状態にある、または接続が拒否されていると解釈する場合もあります。 ##### カーネル モードのネットワーク パケット処理への影響 ネットワーク ドライバなどのアプリケーション、またはその他のカーネルレベルのパケット処理は、IPsec でトラフィックが保護されている場合、正常に機能しないことがあります。 このようなアプリケーションはパケットに変更を加える場合があり、変更されたパケットは IPsec によってドロップされます。 また、IPsec の変更によってアプリケーションが混乱し、システム エラー (ブルー スクリーン) が発生する場合もあります。 ##### 分離ドメインのホストによるネットワーク スキャニングへの影響 リモート IP アドレスのプローブを短時間で行ったりネットワークのポートを開いたりするホストベースのツールでは、このようなプローブ トラフィックが IPsec でセキュリティ保護されると、実行速度が極端に遅くなる場合があります。 プローブ トラフィックによって数百もの IP アドレスに対する IKE ネゴシエーションが開始され、この処理に数秒または数分かかるため、ローカル ホストでサービスが拒否される可能性があります。 一部の SNMP ベース ツールは、イベント回収が業務の信頼されていないホストに送信される SNMP トラップ イベントに依存しています。 IPsec でクリアテキストへのフォールバックが許可されていても、送信 SNMP トラップ パケットは、ソフト SA が確立される前に IPsec ドライバによって破棄されます。 同様に、一部の UDP ベース アプリケーション (NTP や Windows ドメイン コントローラ ロケータなど) は、応答を受信するまで 3 秒しか待機しせ。そのため、アプリケーション エラーが発生するか宛先にアクセスできないことを示すエラー メッセージが報告されます。 ##### Winsock Layered Service Provider に関する問題 一部の正規のアプリケーション (パーソナル ファイアウォールなど) および一部の悪意のあるアプリケーション (スパイウェアなど) は、Winsock Layered Service Provider (LSP) と呼ばれる独自のネットワーク トラフィック検査機能を挿入して問題を発生させる場合があります。マイクロソフトの IPsec 実装の IKE コンポーネントでは、WSAIoctl() を呼び出して関数ポインタを決定する拡張 Winsock API 機能が使用されています。 インストールされている LSP がこの関数呼び出しを渡すことを許可しない場合、IKE は要求された UDP ポートを監視できません。 Windows Server 2003 では、IPsec はこの状態をコンポーネントの障害と解釈し、要求されたセキュリティ ポリシーを強制的に適用して防御的に対応します。 "Secure Mode の失敗" が呼び出され、IPsec ドライバはブロック モードに移行します。 管理者は、デスクトップ ログインを使用してログインし、IPsec サービスを停止して接続を復旧する必要があります。 IPsec サービスが停止要求に応答しない場合は、IPsec サービスの設定を無効にしてコンピュータを再起動する必要があります。 IKE が正常に初期化されているように見える場合でも、LSP やインストールされている他のサードパーティ製プログラムによって、IKE および IPsec プロトコルの送受信を行うコンピュータの機能がブロックされる場合があります。 第 2 層のサポートでは、Winsock LSP のトラブルシューティングを行う作業は LSP の存在を特定するという作業で構成されています。 第 3 層のサポートでは、LSP をインストールしたアプリケーションを特定するさらに詳細な調査が行われ、そのアプリケーションの再配置または削除を実施して、IPsec サービスまたは IKE の問題が解消されるかどうかの確認が行われます。 Winsock LSP を検出するには、次のツールを使用します。 - **Sporder.exe**: Windows Platform Software Development Kit (SDK) に含まれているアプレットで、Winsock 2.0 の LSP を確認できます。 - **Netdiag /debug**: ##### サードパーティ製 IPsec VPN クライアント リモート アクセス VPN クライアントの一部としてサードパーティ IPsec 実装をインストールした場合、いくつかの問題が発生する可能性があります。 通常、これらのクライアントは IPsec サービスを無効にするため、ネイティブの Windows IPsec と競合することはありません。 ただし、このソリューションでは、信頼されたドメインのメンバがネイティブの IPsec サービスを使用する必要があります。 したがって、サードパーティの IPsec 実装を使用すると、次の理由により競合が発生する場合があります。 - 双方の IKE 実装で UDP ポート 500 を必要とする場合がある。 - 双方の IPsec カーネル パケット処理で ESP プロトコルを必要とする場合がある。 - クライアントの一部としてインストールされている Winsock LSP 機能。 - VPN クライアントが提供するファイアウォール機能。 - レイヤリングにより、ネイティブの IKE および IPsec カプセル化パケットがサードパーティ IPsec トンネルを通過できない。 これらのクライアントでネイティブの Windows IPsec サービスの有効化がサポートされているかどうか、また IPsec で保護されたトランスポート モード トラフィックがリモート アクセス接続全体でサポートされているかどうかについては、その VPN のベンダにお問い合わせください。 VPN ベンダのゲートウェイで、Windows 2000 および Windows XP の PPTP および L2TP/IPsec VPN クライアントがサポートされている場合もあります。 ネイティブの Windows VPN クライアントは、VPN トンネル全体で IPsec トランスポート モードと互換性があります。 [](#mainsection)[ページのトップへ](#mainsection) ### 第 3 層のトラブルシューティング 第 2 層のトラブルシューティングで問題を解決できなかった場合は、別の専門スタッフが問題を分析して解決方法を導き出す必要があります。 この専門スタッフが第 3 層のサポートに相当します。 多くの場合、このサポートは、マイクロソフトの製品サポート サービスなど IPsec の専門家やサポート組織が提供します。 第 3 層の IPsec サポートでは、IPsec の運用とマイクロソフトの TCP/IP スタックに関する深い知識が求められます。 第 3 層のサポート スタッフ メンバは、IPsec 自体と サーバー/ドメイン分離シナリオにおける IPsec の使用に関する重要なトレーニングを受ける必要があります。 そのようにしてスキルを取得することで、第 3 層のスタッフ メンバは、下位層のスタッフ メンバに対してトレーニングを実施したり、技術解説、ホワイト ペーパー、サポート ガイド、FAQ、IPsec アーキテクチャや分類学に関する情報などのサポート ドキュメントを作成することができます。 第 3 層のサポートでは、災害復旧計画の作成と文書化の役割を担う場合もあります。 #### マイクロソフト製品サポート サービスの利用 この章で紹介したトラブルシューティング手順で問題を解決できない場合、または高度なトラブルシューティング方法を実行できるほど専門的な知識がない場合は、問題をマイクロソフトの製品サポート サービスにエスカレートする必要があります。 製品サポート サービスを利用する前に、ログやネットワーク監視などの診断情報をできるだけ多く収集しておくことが重要です。 次のリストを参考にして、第 3 層のサポートまたはマイクロソフトの製品サポート サービスが問題を分析する場合に必要な情報を収集してください。 - 各コンピュータで受信/送信の認証および承認を行うためのセキュリティ要件。 この要件に対応するためにコンピュータのグループ ポリシーおよび IPsec を構成した方法について簡単に説明した文書も提供する必要があります。 - シナリオの説明図。発信元コンピュータと宛先コンピュータの名前、ログ ファイルを収集した時点でのそれぞれの IP アドレス、およびオペレーティング システムのバージョン (Service Pack 情報を含む) をまとめておきます。 また、DNS サーバー、WINS サーバー、およびドメイン コントローラの IP アドレスも記載します。 - IPsec ポリシーがアクティブなときに通信の両端から取得したネットワーク モニタによる通信のトレース。2 つのトレース ファイルでパケットの相関関係を容易に確認できるように、この 2 つは同時に取得する必要があります。 ネットワークをトレースする場合、認証要求、DNS 検索、およびその他の関連するトラフィックを特定できるように、各コンピュータの可能な限りすべての受信および送信トラフィックを対象にします。 また、IPsec ポリシーがアクティブなときには通信が失敗し、IPsec ポリシーが無効なときかサービスを停止したときに通信が成功する場合は、IPsec を無効にしたときのトラフィックのネットワーク トレースも取得しておきます。 ログとトレース ファイルを対比できるように、これらのシステムのシステム時間は同期させておくことが非常に重要です。 - Windows 2000、Windows XP、および Windows Server 2003 では、 netdiag /debug >netdiag-debug-computername.txt ログが、ネットワーク トレースを取得する直前または直後に出力されます (Netdiag によって多数のネットワーク トラフィックが生成されますが、このトラフィックはネットワーク トレースの対象に含める必要はありません)。Windows XP および Windows Server 2003 の場合、次のコマンドも出力されます。 portqry -v -local >portqry-v-computername.txt. - IKE の双方の側から取得した **Oakley.log** ファイル。このファイルは、問題が発生したとき、およびネットワーク モニタによってトレースが記録されたときに収集します。 このファイルのファイル名はコンピュータ名を表しています。 Windows RAS または VPN クライアントが関連している場合は、RASDIAG ツールを使用して情報を収集してください。 - **Oakley.log** ファイルとネットワーク トレースを収集した時点での、各コンピュータの完全なシステム ログ、セキュリティ ログ、およびアプリケーション ログ。 - **Oakley.log** とネットワーク トレースの取得と同時に作成されたグループ ポリシー固有のログ ファイル。 - 各コンピュータの IPsec ポリシーの詳細。 各コンピュータに適用する IPsec ポリシーを簡単に保存できる場合は、このポリシーも収集情報の中に含めます。 ただし、コンピュータのアクティブな IPsec ポリシーは、多くの場合、ただのドメイン ポリシーまたはローカル ポリシーではなく、さまざまな種類の IPsec ポリシー構成を組み合わせたものになっています。 コンピュータのアクティブなポリシーを分析する場合に最適な形式は、\[IP セキュリティ モニタ\] MMC スナップインで作成した、IKE メイン モード専用のフィルタと IKE クイック モード専用のフィルタのリストです。 **フィルタの書式化されたテキスト ファイルを作成するには** 1. ツリーの左側のペインで、**\[クイック モード\] - \[特定のフィルタ)\]** ノードを右クリックします。 2. **\[一覧のエクスポート\]** を選択します。 3. **IKE-qm-*<特定のコンピュータ名>*.txt** のようなコンピュータ名を含めた名前を付けて、タブ区切りテキスト ファイルを保存します。 フィルタの詳細がすべて含まれたタブ区切りテキスト ファイルは、スプレッドシートまたはワード プロセッサ文書にインポートすることができます。 [](#mainsection)[ページのトップへ](#mainsection) ### 要約 この章では、第 1 層のサポート (ヘルプ デスク スタッフ) および第 2 層のサポート (IT 専門のネットワーク サポート スタッフ) が IPsec 通信に関する一般的な問題のトラブルシューティングを行う方法を把握する際に役立つプロセスについて詳しく説明しました。 IPsec およびネットワークのセキュリティは非常に複雑なため、あらゆる事例を網羅することはできません。そのため、発生の可能性のあるすべてのエラーについてここで説明することはできません。 この章では、このガイドで説明しているサーバー/ドメイン分離環境で問題が起こる可能性が最も大きいと考えられる箇所を中心に説明を行い、必要に応じて選択可能なオプションを簡潔に紹介しました。 このガイドに同梱されているサンプル スクリプトは、Woodgrove Bank シナリオのテスト ラボの実装でテスト済みであり、有効に機能することが証明されています。 ただし、このスクリプトは組織のニーズに合わせて各自でカスタマイズできるように設計されているため、マイクロソフトではサポートを提供していません。 IPsec のトラブルシューティングは技術的に複雑な作業であり、ネットワーキング、Active Directory、グループ ポリシーなど、IPsec 以外にも多くの技術分野のスキルを必要とします。 しかし、この章で紹介した情報を参考にすれば、サーバー/ドメイン分離ソリューションに影響する可能性のあるほとんどの問題を解決することができます。 第 3 層のサポートのレベルまで知識を高める必要がある場合は、このガイドに加えて、次のセクションで紹介するその他の参考資料をお読みください。 #### 関連情報 - IPsec の詳細な背景情報については、「Windows Server 2003 Technical Reference」の「[How IPsec Works](https://technet2.microsoft.com/windowsserver/en/library/8fbd7659-ca23-4320-a350-6890049086bc1033.mspx)」(英語) を参照してください。 - TCP/IP に関する問題のトラブルシューティングの詳細については、次の技術資料を参照してください。 - 「[TCP/IP in Windows 2000 Professional](https://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/prork/prcc_tcp_slnb.asp)」www.microsoft.com/resources/documentation/Windows/ 2000/server/reskit/en-us/prork/prcc\_tcp\_slnb.asp (英語) - 「Windows XP Resource Kit」の「[TCP/IP Troubleshooting](https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnbd_trb_tctu.mspx)」の章 www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnbd\_trb\_tctu.mspx (英語) - 「[Windows XP における TCP/IP 接続のトラブルシューティング](https://support.microsoft.com/?kbid=314067)」https://support.microsoft.com/?kbid=314067 - 「[Windows Server 2003 TCP/IP Troubleshooting](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/operations/system/tcpiptrb.mspx)」www.microsoft.com/technet/prodtechnol/windowsserver2003/ operations/system/tcpiptrb.mspx (英語) - Windows 2000、Windows XP、および Windows Server 2003 で IPsec のトラブルシューティングを行う方法について具体的に解説したオンライン ヘルプおよびリソース キット文書については、以下を参照してください。 - 「[Windows 2000 での IPSec の基本的なトラブルシューティング](https://support.microsoft.com/?kbid=257225)」 https://support.microsoft.com/?kbid=257225 - 「[Microsoft Windows 2000 Advanced ドキュメント](https://www.microsoft.com/windows2000/ja/advanced/help/sag_ipsectrouble.htm?id=3352)」 www.microsoft.com/windows2000/ja/advanced/help /sag\_ipsectrouble.htm?id=3352 - 「[Windows XP での L2TP/IPSec の基本的なトラブルシューティング](https://support.microsoft.com/?kbid=314831)」 https://support.microsoft.com/?kbid=314831 - 「Windows Server 2003 Help – IPsec [Troubleshooting tools](https://technet2.microsoft.com/windowsserver/en/library/b0b726fc-c6b7-426a-964f-9c7b1c8ef3a81033.mspx)」 https://technet2.microsoft.com/windowsserver/en/library/b0b726fc-c6b7-426a-964f-9c7b1c8ef3a81033.mspx (英語) - 「[Microsoft Windows 2000 TCP/IP 実装の詳細](https://www.microsoft.com/japan/windows2000/techinfo/howitworks/communications/networkbasics/tcpip_implement.mspx)」ホワイト ペーパーに掲載されているアーキテクチャ概要図 https://www.microsoft.com/japan/windows2000/ techinfo/howitworks/communications/networkbasics/ tcpip\_implement.asp - 「[Windows 2000 Network Architecture](https://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/cnet/cnad_arc_jypf.asp)」の図 B.1 www.microsoft.com/resources/documentation/windows/ 2000/server/reskit/en-us/cnet/cnad\_arc\_jypf.asp (英語) - 「[How TCP/IP Works](https://technet2.microsoft.com/windowsserver/en/library/3a9b874b-188a-4352-b542-27f433db07b01033.mspx)」https://technet2.microsoft.com/windowsserver/en/library/3A9B874B-188A-4352-B542-27F433DB07B01033.mspx (英語) - 「[How IPSec Works](https://technet2.microsoft.com/windowsserver/en/library/8fbd7659-ca23-4320-a350-6890049086bc1033.mspx)」https://technet2.microsoft.com/WindowsServer/en/library/8fbd7659-ca23-4320-a350-6890049086bc1033.mspx (英語) [](#mainsection)[ページのトップへ](#mainsection)