TCP/IP 通信のトラブルシューティングに関するガイダンス

  • [アーティクル]

仮想エージェントを試す - Active Directory レプリケーションに関する一般的な問題をすばやく特定して修正するのに役立ちます。

この記事は、TCP/IP 通信の問題のトラブルシューティングに役立つよう設計されています。

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

ping コマンドは、基本的な接続をテストするのに役立ちます。 ただし、全体的な接続性を証明するために使用しないでください。 Telnet と PsPing は、次の理由により便利です。

  • これらのツールは、トランスポート プロトコルとして TCP または UDP (PsPing のみ) を使用して、アプリケーション層への接続をテストできます。
  • 使用するポートを指定できます。 そのため、ファイアウォールで開いているポートを移動できます。
  • 宛先ノードの任意の "リッスン" ポートに接続して、特定のアプリケーションのポートへのアクセスを確認できます。

トラブルシューティング チェックリスト

手順 1: ネットワークダイアグラムをキャプチャする

影響を受ける領域へのパスにあるデバイスの詳細を示すネットワーク図をキャプチャします。 具体的には、次のデバイスに注意してください。

  • ファイアウォール
  • IPS (侵入防御/防止システム)
  • DPI (ディープ パケット検査)
  • WAN アクセラレータ

この図は、問題の原因を探す場所を視覚化して特定するのに役立ちます。

手順 2: ネットワーク トレース

ネットワーク トレースは、問題が発生したときにネットワーク レベルで何が発生しているかを確認するのに役立ちます。

手順 3: コンピューターのローカル IP アドレスに ping を実行する

コンピューターのローカル IP アドレスに ping を実行してみてください。

ノードがローカル IP に ping を実行できない場合、ローカル スタックは機能しません。 表示されるエラー メッセージに注意してください。

一般的なエラー エラーが発生した場合、このエラーは、要求を処理する有効なインターフェイスがないことを意味します。 この問題は、ハードウェアの問題またはスタックの問題が原因である可能性があります。

システム トレイの [ネットワーク接続 ] アイコンに赤い "X" 文字または黄色の感嘆符が表示されているかどうかを確認します。 赤い X は、Windows がネットワーク接続を検出していないことを示します。 黄色の感嘆符は、ネットワーク接続状態インジケーター (NSCI) がプローブ チェックに失敗したことを示します。

この問題をトラブルシューティングするには、ネットワーク アダプターが接続を報告することを確認します。 ネットワーク アダプターが接続されていること、およびノードが接続されているスイッチ ポートがエラー状態になっていないことを確認します。 ケーブル、スイッチ ポート、ネットワーク アダプターを変更して、この問題が発生した場所を絞り込むことができます。 ただし、最終的には、問題は OS の外部にあります。 さらに調査するには、ハードウェア ベンダーに問い合わせてください。

ネットワーク ドライバーと Windows の間でも問題が発生する可能性があります。 この問題は通常、スタックの破損が原因です。 次のトラブルシューティング手順を使用します。

  1. ノードの最新ビット (TCP/IP、NDIS、AFD、Winsock など) を確認します。

  2. 次のコマンドを実行して、IP と Winsock をリセットします。 すべてのネットワーク構成をバックアップします。

    netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset

  3. ノードを再起動します。

  4. 再起動後にネットワーク設定を復元します。 この操作は、インターフェイス名が変更されていない場合、またはスクリプトが更新されて新しい名前を使用する場合にのみ機能します。

    netsh -f C:\netConfig.txt

  5. 必要に応じて、ネットワーク アダプター ドライバーをアンインストールまたは再インストールします。

  6. サード パーティ製のフィルター ドライバー (ウイルス対策など) を確認して削除します。

  7. ネットワークを使用してセーフ モードでコンピューターを起動してみてください。 ネットワークを使用したセーフ モードが機能する場合は、MSConfig 内のすべてのサード パーティ製アプリとサービスを無効にして "クリーン ブート" プロセスを実行し、問題が返されるまでそれらを 1 つずつ再度有効にします。 その後、ベンダーに問い合わせてサポートを受けることができます。

    1. これらの項目のいずれも成功しなかった場合、問題はレジストリの破損である可能性があります。
    2. レジストリのバックアップ コピー (物理バックアップやシステム復元ポイントなど) がある場合は、以前に動作していた構成にノードを復元できます。 破損の根本原因をキャッチすることは困難で非常に時間がかかる場合があります。 破損が見つかったとしても、原因を知ることはさらに困難です。 破損したレジストリ キーを変更すると、ノードがサポートされていない状態になります。 そのため、破損を修正するために、お客様がノードを復元または再読み込みすることをお勧めします。

NSCI がプローブのチェック (黄色の感嘆符) に失敗した場合、これは必ずしも接続の問題を示すわけではありません。 一般的な通信が必要に合って発生していることを確認します。

  • その場合、調査では、NCSI がプローブチェックに失敗した理由に特に焦点を当てる必要があります。 この詳細については、別のトピックで説明します。
  • そうでない場合は、接続が復元された後に修正される可能性があるため、最初に接続の問題を調査します。

手順 4: ping または telnet テスト中に発生するエラー メッセージのトラブルシューティング

ノードが同じサブネットまたはネットワーク セグメント上のノードに ping または telnet できる場合は、外部接続が機能していることを確認します。 基本的な接続の問題が存在するかどうかを理解するには、さらにテストする必要があります。

ノードが同じサブネット/ネットワーク セグメント上のノードに ping/telnet できない場合。 表示されるエラー メッセージに注意してください。

  1. 宛先ホストに到達できない エラーは、ノードによって送信された ARP 要求が応答を受け取っていないことを意味します。

  2. テストするノードから両面トレースを収集します。 ソース ノードによって送信される ARP 要求が宛先ノードに到達し、宛先ノードがそれに応じて応答することを確認します。 この応答は、ソース トレースに表示されます。 このプロセスが失敗した場合、問題は構成ミスまたはその他の問題でインフラストラクチャに影響を与える可能性があります。

    考えられる原因は次のとおりです。

    1. VLAN が正しくないか一致していません。
    2. スイッチ ポートの構成が正しくありません (トランクとアクセス ポート)。
    3. その他のハードウェアの問題。

  3. 要求タイムアウト エラーは、ARP 要求が応答を受け取ったが、ノードによって送信された ICMP エコー要求が ICMP エコー応答を受け取っていないことを意味します。 これは単独では、問題を示すわけではありません。 ICMP トラフィックは、ノード上のネットワークまたはファイアウォール ソフトウェアによってブロックされる可能性があります。 ファイアウォール プロファイル (Windows) をオフにするか、ファイアウォール ベンダーでサポートされている ICMP テスト方法を使用して無効にすることが有益な場合があります。

    1. Telnet と PsPing は、テストに適しています。 ソース ノードからリッスン ポート (445 など) の宛先ノードに Telnet または PsPing を実行します。
    2. 手順 1 が成功した場合、外部接続が機能しています。 基本的な接続のテストを続行します。
    3. 手順 1 が成功しない場合 (およびファイアウォール プロファイルが無効になっている場合)、両面 netsh netconnection シナリオ トレースを収集して、さらにトラブルシューティングを行います。

手順 5: 既定のゲートウェイに Ping または Telnet を実行する

ノードが既定のゲートウェイに ping を実行できる場合、ソース ノードから外部接続 (オフボックス接続など) が可能になります。 基本的な接続の問題が存在するかどうかを理解するには、さらにテストする必要があります。 ノードがデフォルト ゲートウェイに ping または Telnet できない場合、これはルータで ICMP 応答が無効になっていることを意味します。

手順 6: 特定の宛先ノードに影響する問題を確認する

ソース ノードが宛先サブネット上の他のノードに ping、Telnet、または PsPing できる場合は、インフラストラクチャ内の基本的な接続とルーティングが機能しています。 この結果は、特定の宛先ノードに影響を与える問題を指します。

  1. アプリケーションがリッスンしている特定のポート (SMB の場合は TCP ポート 445 など) に対して Telnet または PsPing を試みます。 接続に成功した場合は、基本的なアプリケーション レベルの接続を確認できます。 このような場合は、アプリケーションベンダーに問い合わせて、アプリケーションが接続しない理由を調査する必要があります。

    注:

    たとえば、問題が共有に接続できない場合、アプリケーション ベンダーは Microsoft である可能性があります。 このような状況では、両側 netsh netconnection シナリオ トレースを使用して追加情報を収集し、ネットワーク スタックに問題がないことを確認するのに役立ちます。

  2. 特定のポートへの接続が成功しない場合:

    1. ポートが "リッスン中" 状態であることを確認します。
      Cmd： netstat -nato | findstr :<port>
      Powershell： Get-NetTcpConnection -LocalPort <port>
    2. すべてのファイアウォール プロファイルを一時的に無効にします。 (注: プロファイルのみを無効にします。サービスを無効にしないでください)。
      これが成功した場合は、特定のポートでアプリケーション トラフィックを許可するようにファイアウォールを再構成する必要があります。
    3. サード パーティ製アプリケーションを一度に 1 つずつ削除し、各削除の間でテストします。
      これが成功した場合は、問題のあるソフトウェアのベンダーに問い合わせてください。
    4. ネットワークでセーフ モードを試す。
      これが成功した場合は、MSConfig を使用してノードの "クリーン ブート" を実行し、問題が再発するまでサード パーティのアプリケーションとサービスを 1 つずつ有効にすることで、原因を特定します。
    5. 接続試行を再現するときは、ソースから影響を受ける宛先ノードへの netsh netconnection シナリオ トレースを実行する必要があります。 ネットワーク SDP も有益です。

  3. ノードが宛先サブネット上の他のノードに ping、Telnet、または PsPing できない場合、問題はインフラストラクチャに関連している可能性があります。 ここでも、環境内で ICMP がブロックされる可能性があります。 そのため、Telnet または PsPing を使用して既知のリッスン ポートに接続することで、接続を確認します。 この時点で、ネットワーク上でパケット損失が発生している場所を示すために、両面ネットワーク トレースが必要です。 問題がキャプチャされるように接続テストを試す前に、両方のトレースが実行されていることを確認してください。

共通の問題と解決策

ホストへの TCP/IP 接続が停止しているようです

この問題は、TCP キューと UDP キューでデータがブロックされているか、ネットワークまたはユーザー レベルのソフトウェア遅延の問題があるために発生します。

この問題をトラブルシューティングするには、 コマンドを netstat -a 使用して、ローカル コンピューター上の TCP ポートと UDP ポート上のすべてのアクティビティの状態を表示します。
良好な TCP 接続の状態は、送信キューと受信キューに 0 バイト (0) バイトが含まれている間に確立されます。 いずれかのキューでデータがブロックされている場合、または状態が不規則な場合は、接続に障害が発生している可能性があります。 そうでない場合は、ネットワークまたはユーザー レベルのソフトウェアの遅延が発生している可能性があります。

名前解決に Lmhosts を使用する場合の接続時間が長い

この問題は、lmhosts ファイルが順番に解析され、#PRE オプションのないエントリが検索されるために発生します。

この問題のトラブルシューティングを行うには、よく使用されるエントリをファイルの上部近くに配置し、#PRE エントリを下部の近くに配置します。 大きな Lmhosts ファイルの末尾にエントリが追加された場合は、#PRE オプションを使用して、Lmhosts のエントリを事前に読み込まれたエントリとしてマークします。 次に、 コマンドを nbtstat -R 実行して、ローカル名キャッシュを直ちに更新します。

システム エラー 53 が発生しました

コマンドの使用時に特定のコンピューター名 net use の名前解決に失敗した場合、システム エラー 53 が返されます。

コンピューターがローカル サブネット上にある場合は、名前のスペルが正しく、ターゲット コンピューターも TCP/IP を実行していることを確認します。 コンピューターがローカル サブネット上にない場合は、その名前と IP アドレスのマッピングが Lmhosts ファイルまたは WINS データベースで使用できることを確認します。 すべての TCP/IP 要素が正しくインストールされているように見える場合は、コマンドを ping リモート コンピューターと共に使用して、TCP/IP ソフトウェアが動作していることを確認します。

特定のサーバーに接続できない

この問題は、NetBIOS の名前解決で名前が解決されていないか、間違った IP アドレスが解決されているために発生します。

この問題をトラブルシューティングするには、サーバーの コマンドを nbtstat -n 使用して、ネットワークに登録されているサーバーの名前を特定します。 接続しようとしているコンピューターのコンピューター名は、表示される一覧に表示されます。 名前が一覧にない場合は、 で nbtstat表示される他の一意のコンピューター名のいずれかを試してください。 リモート コンピューターで使用される名前がコマンドによって nbtstat -n 表示される名前と同じ場合は、リモート コンピューターに WINS サーバー上または Lmhosts ファイル内のサーバー名のエントリがあることを確認します。

既定のゲートウェイを追加できません

この問題は、既定のゲートウェイの IP アドレスが IP アドレスと同じ IP ネットワーク ID 上にないために発生します。

この問題をトラブルシューティングするには、既定のゲートウェイの IP アドレスとコンピューターのいずれかのネットワーク アダプターのネットワーク ID を比較して、既定のゲートウェイがコンピューターのネットワーク アダプターと同じ論理ネットワーク上にあるかどうかを判断します。

たとえば、コンピューターには、192.168.0.33 の IP アドレスと 255.255.0.0 のサブネット マスクで構成されている 1 つのネットワーク アダプターがあります。 そのためには、既定のゲートウェイが "192.168" という形式である必要があります。<y>。<z>" は、IP インターフェイスのネットワーク ID 部分が 192.168.0.0 であるためです。

データ収集

Microsoft サポートに問い合わせる前に、問題に関する情報を収集できます。

前提条件

  1. TSS は、ローカル システムの管理者権限を持つアカウントで実行する必要があり、EULA を受け入れる必要があります (EULA が承認されると、TSS は再度プロンプトを表示しません)。
  2. ローカル コンピューター RemoteSigned の PowerShell 実行ポリシーをお勧めします。

注:

現在の PowerShell 実行ポリシーで TSS の実行が許可されていない場合は、次のアクションを実行します。

  • コマンドレット を RemoteSigned 実行して、プロセス レベルの実行ポリシーを設定します PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned。
  • 変更が有効かどうかを確認するには、 コマンドレット を実行します PS C:\> Get-ExecutionPolicy -List。
  • プロセス レベルのアクセス許可は現在の PowerShell セッションにのみ適用されるため、TSS が実行される特定の PowerShell ウィンドウが閉じられると、プロセス レベルに割り当てられたアクセス許可も以前に構成された状態に戻ります。

Microsoft サポートに連絡する前に重要な情報を収集する

  1. すべてのノードで TSS をダウンロードし、 C:\tss フォルダーに解凍します。

  2. 管理者特権の PowerShell コマンド プロンプトから C:\tss フォルダーを開きます。

  3. 次のコマンドレットを使用して、ソース サーバーと移行先サーバーでトレースを開始します。

    TSS.ps1 -Scenario NET_General

  4. トレースがソースまたは移行先サーバーで初めて実行される場合は、EULA に同意します。

  5. 記録を許可する (PSR またはビデオ)。

  6. Y に入る前に問題を再現します。

    注:

    クライアントとサーバーの両方でログを収集する場合は、問題を再現する前に、両方のノードでこのメッセージを待機します。

  7. 問題の再現後にログ収集を完了するには、「 Y 」と入力します。

トレースは、分析のためにワークスペースにアップロードできる C:\MS_DATA フォルダー内の zip ファイルに格納されます。

関連情報