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) メッセージの ping と tracert を使用して、ネットワーク パスをテストします。
名前解決 : 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 に進みます。
.gif)
図 7.1: 対象コンピュータとの通信に失敗した場合のトラブルシューティング プロセス
拡大表示する
.gif){kind=link}
注 : このフローチャートは、連絡者のコンピュータが IPsec を実行しており、ping –a コマンドが正常に機能するように DNS 逆引き参照ゾーンが構成されていることを前提としています。
図 7.2 は、連絡者自身のコンピュータに関する問題を特定する場合に使用します。 このフローチャートでは、診断以外にも、問題を特定せずに解決する IPsec ポリシー更新スクリプト (この章で後述する「サポート スクリプトの例」を参照) を使用することが想定されています。 図 7.2 の手順に従うと、連絡者のコンピュータで次のどの問題が発生しているのかを確認できます。
RRAS に関する問題。 この場合は、RRAS サービスを停止するか (RRAS を必要としない場合)、問題を第 2 層のサポートにエスカレートします。
ポリシーに関する問題。 この場合は、グループ ポリシーと IPsec ポリシーを更新を試みます。
ドメイン アカウントに関する問題。 この場合は、連絡者のコンピュータ用のドメイン アカウントを作成します。
上記のいずれにも当てはまらない。 Psec ポリシーの更新やドメイン アカウントの作成によって問題が解決されない場合は、問題を第 2 層のサポートにエスカレートします。
.gif)
図 7.2: 連絡者のコンピュータの IPsec 関連の問題のトラブルシューティング 拡大表示する
.gif){kind=link}
図 7.3 は、特定の対象コンピュータの問題を特定する場合に使用します。 このフローチャートでは、問題を特定せずに解決する IPsec ポリシー更新スクリプトの使用も想定されています。 図 7.3 を参照すると、対象コンピュータ (または対象コンピュータへのパス) で次のどの問題が発生しているのかを特定できます。
RRAS に関する問題。 この場合は、第 2 層のサポートにエスカレートします。
IPsec ポリシーに関する問題。 この場合は、グループ ポリシーと IPsec ポリシーを更新を試みます。 次に、ネットワークの接続を確認します。
ネットワークの接続に関する問題。 この場合は、第 2 層のサポートにエスカレートします。
ログオン権限に関する問題。 この場合は、第 2 層のサポートにエスカレートします。
.gif)
図 7.3: 対象コンピュータの IPsec 関連の問題のトラブルシューティング
拡大表示する
.gif){kind=link}
第 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 ポリシー、フィルタ、メイン モードの統計情報を表示します | 利用可 | 利用可* | 利用不可** |
| ツール | サポートしているオペレーティング システム | 取得方法 | 役割 | 詳細情報 |
|---|---|---|---|---|
| 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 ファイルのコピー (存在する場合)。 |
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
ドメイン コンピュータ チケットを表示するには
タスク スケジューラ サービスが実行されており、ログオンしたユーザーが Local Administrators グループのメンバであることを確認します。
コマンドライン プロンプトで、現在のシステム時間の 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 はローカル システム環境で実行する必要があります)
タスク スケジューラ サービスが実行されており、ログオンしたユーザーが Local Administrators グループのメンバであることを確認します。
コマンドライン プロンプトで、現在のシステム時間の 1 分後に当たる時間を選択し (4:38 pm など)、次のように入力します。
at 4:38pm /interactive cmd「klist purge」と入力し、チケットごとに Y キーを押してすべての Kerberos チケットを削除します。
「klist tickets」と入力し、チケットが存在しないことを確認します。
この手順を IKE ネゴシエーションで発生した障害のトラブルシューティングの一部として使用する場合は、IKE ネゴシエーションがタイムアウトになるまで 1 分待ち、アプリケーションで対象サーバーに再度アクセスを試みます。 新しい IKE メイン モード ネゴシエーションにより、宛先コンピュータ用の新しい Kerberos TGT およびサービス チケットが要求されます。この結果、最新のグループ情報がそのコンピュータに適用されます。 アプリケーションは、ローカル システム環境で実行しているコマンド ウィンドウからは実行しないでください。
Kerberos のトラブルシューティングを行う場合のその他の手順の詳細は、次のホワイト ペーパーに記載されています。
「Troubleshooting Kerberos Errors」www.microsoft.com/downloads/details.aspx?
FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en (英語)「Troubleshooting Kerberos Delegation」www.microsoft.com/downloads/details.aspx?
FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en (英語)
Active Directory の IPsec ポリシーの許可と整合性を確認する
Active Directory の IPsec ポリシー コンテナに関する情報の確認が必要になる場合があります。 次の手順では、サポート ツールの ldp.exe を使用します。
IPsec ポリシー コンテナに関する情報を確認するには
[スタート]、[ファイル名を指定して実行] の順にクリックし、「ldp.exe」と入力して ENTER キーを押します。
[Connection]、[Connect] の順に選択します。 対象ドメインの名前を指定します。
[Connection]、[Bind] の順に選択します。 対象ドメインのログオン資格情報を指定します。
[View]、[Tree] の順に選択します。 ベースの DN を指定せずにナビゲートして IPsec ポリシー コンテナを選択するか、ベース ロケーションとして IPsec ポリシー コンテナの LDAP DN を指定します。
ツリー ビューのコンテナ ノードの横にある + (プラス記号) をクリックします。 コンテナに読み取り許可が設定されている場合は、コンテナ内のすべての 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} |
コマンドを使用するか、または \[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 の構成を変更するとドメイン メンバに徐々に影響が表れるため、このような影響を十分に考慮して慎重に計画を立てる必要があります。
グループ ポリシーのトラブルシューティング手順については、次の資料を参照してください。
「Windows 2000 でのグループ ポリシーのトラブルシューティング」https://support.microsoft.com/?kbid=810739
「Troubleshooting Group Policy in Microsoft Windows Server」www.microsoft.com/downloads/details.aspx?
FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en (英語)
ドメインベースの 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 sasWindows 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 がサービス拒否攻撃と考えられる状況から復旧し、通常の動作を再開しました。 |