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

2025-01-15

仮想オペレーターを試す - Active Directory レプリケーションに関する一般的な問題をすばやく特定、解決するのに役立ちます。

この記事は、TCP/IP 通信の問題のトラブルシューティングに役立ちます。

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

ping コマンドは、基本的な接続をテストするのに役立ちます。ただし、接続全体を確認するために、これだけに頼るのは避けてください。次の理由により、Telnet と PsPing がより便利です。

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

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

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

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

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

図を利用して、問題の原因を探す場所を視覚的に見極め特定します。

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

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

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

コンピューターのローカル IP アドレスに対して ping を試します。

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

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

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

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

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

ノードで最新のビット (TCP/IP、NDIS、AFD、Winsock など) を確認します。
次のコマンドを実行して、IP と Winsock をリセットします。すべてのネットワーク構成をバックアップします。
```
netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset
```
ノードを再起動します。
再起動後にネットワーク設定を復元します。この操作は、インターフェイス名が変更されていない場合、または新しい名前を使用するようにスクリプトが更新された場合にのみ機能します。
```
netsh -f C:\netConfig.txt
```
必要に応じて、ネットワークアダプターのドライバーをアンインストールまたは再インストールします。
サードパーティ製のフィルタードライバー (ウイルス対策など) を確認し、削除します。
[セーフモードとネットワーク] でコンピューターの起動を試みます。ネットワークを使用したセーフモードが機能する場合は、 MSConfig 内のすべてのサードパーティ製アプリとサービスを無効にして"クリーンブート" プロセスを実行し、問題が返されるまでそれらを 1 つずつ再度有効にします。その後、ベンダーに問い合わせてサポートを受けることができます。
1. これらの項目がどれも正常ではない場合、問題の原因として考えられるのはレジストリの破損です。
2. レジストリのバックアップコピー (物理バックアップやシステム復元ポイントなど) がある場合は、ノードを以前に動作していた構成に復元できます。破損の根本原因をキャッチすることは困難で、非常に時間がかかる場合があります。破損が見つかった場合でも、原因を知ることはさらに困難です。破損したレジストリキーを手動で変更すると、ノードがサポート対象外の状態になります。そのため、破損を修復するために、ノードを復元または再読み込みすることをお客様にはお勧めします。

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

この場合、NCSI によるプローブチェックが失敗した原因を特に集中して調査する必要があります。これについて詳しくは、個別のトピックで説明します。
それ以外の場合は、接続が復元された後に修正される可能性があるため、最初に接続の問題を調査してください。

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

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

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

宛先ホストに到達できません エラーは、ノードによって送信された ARP 要求が応答を取得していないことを意味します。
テストするノードから両面トレースを収集します。ソースノードによって送信された ARP 要求が宛先ノードに到達し、それに応じて宛先ノードが応答することを確認します。この応答は、送信元のトレースで確認できます。このプロセスが失敗している場合、問題の原因として考えられるのは、インフラストラクチャに影響する構成の誤りやその他の問題です。

次の原因が考えられます。
1. VLAN が正しくないか、一致していない。
2. スイッチポートの構成 (トランクとアクセスポート) が正しくない。
3. ハードウェアに関するその他の問題。
Request がタイムアウトエラーは、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 を実行できる場合は、インフラストラクチャ内の基本的な接続とルーティングが機能しています。この結果は、特定の宛先ノードに影響する問題を示します。

アプリケーションがリッスンしている特定のポート (たとえば、SMB の TCP ポート 445) に対して Telnet または PsPing を試します。接続が成功した場合、基本的なアプリケーションレベルの接続を確認できたことになります。このような状況では、アプリケーションが接続しない原因の調査を支援するようアプリケーションベンダーに依頼する必要があります。

Note

たとえば、問題が共有に接続できない場合、アプリケーションベンダーは Microsoft である可能性があります。このような状況では、追加情報を収集し、ネットワークスタックに問題がないことを確認できるようにするために、双方向の netsh netconnection シナリオトレースを取得すると便利です。
特定のポートへの接続が成功しない場合:
1. ポートが "リッスン中" 状態であることを確認します。
  CMD: netstat -nato | findstr :<port>
  PowerShell: Get-NetTcpConnection -LocalPort <port>
2. すべてのファイアウォールプロファイルを一時的に無効にします。 (注: プロファイルのみを無効にします。サービスを無効にしないでください)。)
  これが成功した場合、特定ポートでのアプリケーショントラフィックを許可するために、ファイアウォールを再構成する必要があります。
3. サードパーティ製のアプリケーションを 1 つずつ削除し、削除のたびにテストを行います。
  これが成功した場合、問題のあるソフトウェアのベンダーに問い合わせます。
4. [セーフモードとネットワーク] を試します。
  これが成功した場合は、 MSConfig を使用してノードの "クリーンブート" を実行し、問題が再発するまでサードパーティのアプリケーションとサービスを 1 つずつ有効にして、原因を特定します。
5. 接続の試行を再現する場合は、送信元から影響を受ける宛先ノードに対して netsh netconnection シナリオトレースを実行する必要があります。ネットワーク SDP も便利です。
ノードが宛先サブネット上の他のノードに ping、Telnet、または PsPing できない場合、問題はインフラストラクチャに関連している可能性があります。ここでも、ICMP が環境内でブロックされている可能性があります。このため、Telnet または PsPing を使用して既知のリスニングポートに接続することで、接続を確認します。この時点で、ネットワーク上でパケット損失が発生している場所を確認するために、双方向のネットワークトレースが必要になります。問題がキャプチャされるように、接続テストを試す前に、両方のトレースが実行されていることを確認します。

一般的な問題と解決方法

ホストへの TCP/IP 接続が停止しているように見える

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

この問題をトラブルシューティングするには、 netstat -a コマンドを使用して、ローカルコンピューター上の TCP ポートと UDP ポート上のすべてのアクティビティの状態を表示します。
適切な TCP 接続の状態は確立され、送受信キューに 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 と比較して、既定のゲートウェイがコンピューターのネットワークアダプターと同じ論理ネットワーク上にあるかどうかを確認します。

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

データ収集

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

前提条件

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

Note

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

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

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

すべてのノードで TSS をダウンロードし、 C:\tss フォルダーに解凍します。
管理者特権の PowerShell コマンドプロンプトから C:\tss フォルダーを開きます。
次のコマンドレットを使用して、ソースサーバーと移行先サーバーでトレースを開始します。
```
TSS.ps1 -Scenario NET_General
```
ソースサーバーまたは移行先サーバーでトレースが初めて実行される場合は、EULA に同意します。
記録を許可する (PSR またはビデオ)。
Yに入る前に問題を再現してください。

Note

クライアントとサーバーの両方でログを収集する場合は、両方のノードでこのメッセージを待ってから問題を再現してください。
Y を入力して、問題の再現後にログ収集を完了します。

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

次の方法で共有

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

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