ネットワーク

特定しにくいネットワークの問題を突き止める

Christopher Stoneff

概要:

• ネットワークの問題の一般的な原因
• 明らかな原因の先を見る
• トラブルシューティング ツールが役に立たないとき
• なぜ接続制限を構成する必要があるのか

コンピュータが他のコンピュータと通信できなくなったが、その原因がわからないという事態には何度も遭遇したことがあるでしょう。管理システムは、ルーティング ネットワークの 1 つのセグメントにあり、ルーティング ネットワークは Microsoft Internet Security and Acceleration (ISA) Server や

別のハードウェア デバイスによって、その他のネットワーク セグメントに接続されています。数十個から 100 個までのシステムであれば、管理する際に問題は発生しませんが、500 個のシステムを管理しようとすると、コンピュータでは、既に接続が開いているコンピュータ以外とはネットワークを介しての通信ができないという状況が発生することがあります。他のあらゆるシステムと通信できず、インターネットにも接続できないのに、(あなたのコンピュータが存在しているセグメント上を含め) ネットワーク上で、同じ現象が発生しているコンピュータは 1 台もありません。このような場合には、まずどこを確認したらいいでしょうか。

問題を診断する

この状況で最も一般的な原因として考えられるのは、管理ソフトウェアに問題があるということです。多くの積極的な管理ツールはシステムに接続して、システムを管理しますが、そういったツール自体が、原因を突き止めようとしている問題の根源だという合があります。積極的な管理ツールは、管理機能の向上という名目で、デバイスで何千もの接続を確立することがあります。Windows® では、接続がアイドル状態の場合でも、ツール、アプリケーション、またはサービスが接続を長い時間維持しようとしない限りは、そういった接続を既定で 2 分間開いたままにします。これは、つまり、管理システムが 2 分間どのコンピュータにアクセスしていなくても、1,000 個以上の接続が開いている可能性があるということです (コマンド プロンプトで NETSTAT を実行すると、開いている接続を確認することができます。NETSTAT コマンドは、システムで開いている接続、保留中の接続、および終了中の接続すべてを表示します。ステータス メッセージの説明については、RFC 793 (tools.ietf.org/html/rfc793) を参照してください。)

誤作動している管理ソフトウェアを問題の原因の候補から除外するには、リモート システムに接続を確立するバッチ ファイルを作成します。バッチ ファイルを実行したときにも同じ問題が発生した場合は、管理ソフトウェアとそのスレッドが問題の原因ではないということが特定できます。このバッチ ファイルには、次のような内容が記載されている必要があります。

Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...

問題の管理プログラムが、独自のネットワークと認証スタックを実装している場合は、それが原因である可能性があります。しかし、そういったほとんどの管理パッケージのようにエージェントを使用しないソリューションでは、ツールはオペレーティング システムのネットワークと認証スタックを使用してネットワーク操作を実行しています。障害を起こさずにできるだけ多くのネットワーク接続を確立するバッチ ファイルを使用すると、(バッチ ファイルでも OS のネットワークおよび認証スタックを使用しているので) プログラムでオペレーティング システムのネットワークおよび認証スタックを使用していることが原因で問題が発生したのではないことがわかります。

役に立たないログとエラー メッセージ

接続が確立できなくなり始めたとき、適切ではないエラーに関する情報が表示されることはご存知でしょう。たとえば、"エラー 53 ネットワーク パスが見つかりません"、"エラー 64 ネットワーク名は削除されました"、"エラー 1203 指定されたネットワーク パスはどのネットワーク プロバイダによっても受け付けられませんでした" などのような情報が表示されます。通常、これらの情報は、名前解決に関する問題を示すものですが、他のすべてのコンピュータでは、名前解決や同じシステムへの接続では問題が発生していません。コンピュータの設定が間違っていないことを確認するには、ipconfig を実行して設定が正しいことを確認します。

この現象の原因が管理システムにあることが特定できたら、イベント ログを確認する必要があります。アプリケーション ログを検索しても意味はありませんが、システム ログを検索すると、接続の最大数に達したことを示す、イベント ソースが TCP/IP の警告イベント 4226 が見つかります (図 1 参照)。

図 1** TCP 接続が制限に達したことを示すイベント **

HKLM\System\CurrentControlSet\Services\TCPIP\Parameters で、いくつかのレジストリ エントリを調整し、前述の要因を制御することができます。TcpNumConnections は TCP が同時に開くことのできる接続の最大数 (既定値は 10) を設定し、TCPTimedWaitDelay は接続が終了中のときの TIME_WAIT 状態の時間を設定します。既定の半減期は 120 秒です。これは基本的に接続が 4 分間使用されるということです。また、MaxFreeTcbs の設定も接続の最大数に影響します。すべての TCP 制御ブロックが使用されている場合、TCPTimedWaitDelay に設定されている時間が経過していなくても、TCP は TIME_WAIT 状態になっている接続を開放し、より多くの接続を作成できるようにする必要があります。TCPTimedWaitDelay に設定できる値の範囲は 30 ~ 300 秒 (0x1E ～ 0x12C) です。

シナリオによっては、これらのレジストリに変更を加えることで全体のパフォーマンスにわずかな改善が見られることがあります。別の解決策として、TCPIP.sys ファイルを修正して、この制限を取り除くこともできます。ただし、この方法で状況を改善できるのは P2P アプリケーションに限られます。

ネットワーク キャプチャ

接続の問題を解決できずにあれこれ試した後、問題に関連のあるコンピュータのネットワーク キャプチャを撮ることが有望な解決策であると思いました。Microsoft ネットワーク モニタ (Netmon) を実行すると、管理ツールとテスト スクリプトで発生していたのとまったく同じ結果が表示されるキャプチャが作成されました。それは、問題なく動作していたのに、突然、問題が発生して詳細なエラー情報が提示されないという状況です。

図 2 は Netmon を実行した結果を示すもので、最初のいくつかのシステム間で通信が正常に行われていることを示しています。この図では、RPC 要求の承認を得ていることが確認でき、これが望ましい正常な双方向の通信の状態です。

図 2** Netmon での正常な通信状態 **(画像を拡大するには、ここをクリックします)

次に、エラー 53 とエラー 1203 が発生する思われる管理システムとリモート コンピュータのネットワーク キャプチャを確認する必要があります。ご想像のとおり、コンピュータでは通信が行われていないので、画面上には何も表示されません。図 3 のネットワーク キャプチャでは、管理システムが IP アドレスを解決し、ポート 445 (Microsoft SMB ポート) を使用してシステムに接続しようとしていますが、応答がありません。

図 3** ポート 445 を使用してシステムへの接続を試行しているが応答がない状態 **(画像を拡大するには、ここをクリックします)

現在コンピュータで接続できる以上のスレッドがある場合に表示されるエラーには一貫性がありません。たとえば、ソース システムから、名前解決は行われたが、IP アドレスが見つからないということを示す、エラー 53 が返されることがあります。これは、DNS が接続できないアドレスを提供していることを示しています。また、要求した名前または IP アドレスに対応するコンピュータがないことを表す、エラー 1203 が返されることがあります。この場合、エラー 1203 は DNS が使用できないことを示しています。nslookup を実行した場合にはこういうことが起こります。

この時点でおそらくストレスを感じているでしょうが、検討すべきオプションはまだあります。ほとんどのユーザーは、この問題が発生している状況から、接続元のインフラストラクチャを確認しようとは思わないでしょう。つまり、ネットワークに接続できないのが、あなたのコンピュータだけで、イベント ログにはコンピュータが許可された最大接続数に達したことを示すイベントが記録されているので、アーキテクチャの性質上の問題ではないように思う人が多いのです。

管理ソリューションが同時に何千もの接続を確立しないとしても、転送の keep-alive と接続のタイムアウトにより、想像以上に多くの接続が同時に開かれている可能性があります。そのため、ネットワークを接続するシステムについても調べる必要があります。

これについて説明しましょう。既に説明したように、ネットワーク トラフィックがネットワークを通過するときは、スイッチやルーター (場合によってはファイアウォール) を通過します。このようなデバイスのいずれか (通常ルーターまたはファイアウォール) には、侵入検出システムが存在します。また、管理されたスイッチやルーターでもトラフィックのフィルタリングが行われています。そのため、ログにエラーと警告が記録されていないかどうかを確認する必要があります (または、デバイスの管理者に、その作業を依頼する必要があります)。通信の問題は、このようなシステム自体にある場合が往々にしてあります。

内部システムから他の内部システムに接続しているので、警告が発生していないことがあります。それはデバイスが警告を発生させるように構成されていないこと、または問題が侵入またはサービス拒否 (DOS) 攻撃と見なされないことが原因です。繰り返しになりますが、まずログを確認する必要があります。例として ISA Server を使用すると、このようなログは ISA Server の管理コンソールの "アレイ\<ArrayName>\監視\ログ" にあります。

問題となっているのが特定のポリシーである場合は、(ISA Server の場合は) 送信元の IP アドレスが管理コンピュータのアドレスである、次の結果コードがあるかどうかを確認します。

• 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
• 0xc004000d FWX_E_POLICY_RULES_DENIED
• 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

このような結果コードが記録されていた場合は、接続の問題の原因を特定できたことになります。

解決策を実装する

問題の原因を特定できたら、解決策は簡単です。しかし、部門の方針によっては、解決策の実装が困難になることもあります。ファイアウォール、ルーター、および侵入検出システムでセキュリティ構成の除外を作成することは常に許可されているとは限らないので、変更を加える前に、適切な権限があることを確認してください。

ここでも、例として ISA Server を使用して、 ネットワーク上にある特定のホスト コンピュータまたはすべてのコンピュータの接続の最大数を増やす手順を説明します (図 4 参照)。ISA Server の管理コンソールを開き、"アレイ\<ArrayName>\構成\全般\フラッド防止設定の構成" に移動します。

図 4** ISA Server を使用して特定のホスト コンピュータまたはすべてのコンピュータの接続の最大数を増やす **

重要なのは、[IP アドレスごとの同時 TCP 接続の最大数] と [分単位、IP アドレスごとの TCP 接続要求の最大数] という 2 つの設定です。通常、[IP アドレスごとの同時 TCP 接続の最大数] には、積極的な管理が行われない (つまり、1 台のコンピュータが他の何千台ものコンピュータとアクティブな状態で接続されることがない) 場合に十分な値が設定されています。ISA Server では、同時 TCP 接続の最大数の既定値は 160 です。[分単位、IP アドレスごとの TCP 接続要求の最大数] はネットワークのスキャンによる損傷や可視性を制限するように設計されています。この TCP 接続要求の最大数の既定値は 600 です。

既に説明したように、Windows は、接続を長い時間維持するようにするものがなければ、既定の 2 分間接続を維持します。これには接続が使用されていない場合も含まれます。つまり、コンピュータを適切に管理し終えて通信する必要がなくても、接続はアクティブなままになるということです。この開いている接続は、許可されている接続の総数に加えられます。接続を削除しないでこのプロセスを 160 回繰り返すと、ルーターによってすべての接続の試行が拒否されます。管理プログラムが積極的にセッションを停止しても、Windows では、接続を TIME_WAIT 状態のままにし、接続しているコンピュータがセッションの切断を許可するまで待機します。

まず、問題の原因として最も可能性が高いと思われる [IP アドレスごとの同時 TCP 接続の最大数] の設定を調整します。この設定の値は、管理コンピュータが、アクセス拒否されることなく、システムを管理するのに必要なすべての接続を作成できる数にします。この設定の隣にある [編集] をクリックして、値を変更します。

次に表示されるダイアログ ボックス (図 5 参照) には、すべてのクライアントに適用される既定の制限を表す [制限] ボックスがあります。[カスタム制限] ボックスの値は、[フラッド防止] ダイアログ ボックスの [IP 例外] タブで指定されているすべてのコンピュータ、ネットワークなどに適用されます。すべてのコンピュータでより多くの接続を作成できるようにする必要がある場合は、[制限] ボックスの値を変更します。管理コンピュータ専用の例外を構成するには、[カスタム制限] ボックスの値を調整し、[IP 例外] タブに当該の管理コンピュータを追加します。一般的に、自分のコンピュータだけで例外を許可するのが適切です。

図 5** 既定の接続の制限とカスタム接続の制限 **

カスタム制限を使用して、特定のシステムについてだけ、この値を変更する必要がある場合は、[カスタム制限] ボックスの値を変更し、[OK] をクリックします。その後、[フラッド防止] ダイアログ ボックスの [IP 例外] タブに当該コンピュータを追加します。例外の一覧にコンピュータを 1 台追加するには、[IP 例外] タブで [追加] をクリックし、[コンピュータ セット] ダイアログ ボックスを開きます。例外を適用するコンピュータを含むネットワーク セットがまだ存在していない場合は、[新規作成] をクリックして、このようなコンピュータを含むネットワーク セットを作成します。このネットワーク セットを選択し、[追加] をクリックして "内部ネットワーク" ネットワーク セットを追加し、[閉じる] をクリックします。もう一度、内部ネットワーク ネットワーク セットを選択し、[編集] をクリックします。これにより、[内部ネットワークのプロパティ] ダイアログ ボックスが開きます (図 6 参照)。このダイアログ ボックスで [追加] をクリックすると、コンピュータ、アドレス範囲、サブネットを追加して、コンピュータを選択できるサブメニューが表示されます。このエントリを後で見た人があなたのシステムを削除しないように、エントリを特定できるような名前、コンピュータの IP アドレス、説明を入力します (図 7 参照)。[OK] をクリックしてシステムを追加し、もう一度 [OK] をクリックして例外を追加します。設定を変更したら、変更内容を適用する必要があります。

図 6** 内部ネットワークのプロパティの設定 **

図 7** コンピュータ名、IP アドレス、説明を入力してシステムが消去されないようにする **

もう一度、積極的な管理ツールを使用してみると、パフォーマンスが大幅に向上し、少なくともネットワーク トラフィックが原因で、接続が失敗することはありません。結局、管理ソフトウェアが確立した接続の数が問題なのではなく、接続を確立できないという状況を引き起こした接続に対して適切な計画が立てられていなかったことが問題だったということがわかりました。

得られた教訓

IT における最も大きな頭痛の種の 1 つは、本当に特定しにくい問題に直面し、それを解決しなければならないということです。その問題はエンド ユーザーが作り出したものではなく、サーバー チームに原因があるものでもなく、ヘルプ デスクが認識していないものです。そして残念なことに、それを解決するのが IT プロフェッショナルの役割です。このような問題のトラブルシューティング、分離、および解決に利用できるツールは多数ありますが、そのツールでも十分でないときがあります。ツールも間違いを犯すことがあるので、ときにはツールよりも賢くなる必要があります。

今後、明らかな原因がないのに、ネットワーク上にある複数台のコンピュータと接続を確立できなくなったときは、このコラムで説明した手順を試してみてください。ここで紹介した手順に従い、管理ソフトウェアを詳しく見て、適切な最大接続数を設定すれば、高い確率で問題を解決できるでしょう。

Christopher Stoneff は、セキュリティとシステム管理に関するソフトウェアを開発している Lieberman Software (liebsoft.com) のプロダクト マネージャです。Chris は普通の人が取得する以上の技術認定資格を保持しています。彼を最も駆り立てるのは、物事のしくみを理解することだけでなく、なぜ物事がそういうしくみなのかを知ることです。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.