Windows で TCP/IP 接続の問題のトラブルシューティングを行う方法を教えてください。

問題

Amazon EC2 Windows インスタンスへの接続時に問題が発生します。ネットワーク接続のトラブルシューティング用のツールを教えてください。

短い説明

TCP/IP ネットワークのノード間の接続の問題は通常、以下の要因による誤ったルーティング情報の結果ですが、これらに限定されるものではありません。

非認証の DNS サーバー - クライアントが正しく設定されていない不正な DNS サーバーからの情報をリクエストした場合、返された情報は信頼できません。
HOSTS ファイルのエントリが正しくない - Windows でホストと IP マッピングが静的に定義できる HOSTS ファイルが実装されています。Windows オペレーティングシステムでは、このファイルは「%SystemRoot%\system32\drivers\etc\hosts」になります。ここで、%SystemRoot% は、Windows のインストールドライブ文字とフォルダーの場所を参照する環境変数です。Windows HOSTS ファイルのエントリには以下の形式が使用されます。
1.2.3.4 hostname
ここで、1.2.3.4 は hostname の参照時に使用される物理 IP アドレスです。
Windows のすべてのバージョンのデフォルトの動作は、DNS などのホスト名解決の他の方法を試みる前に、HOSTS ファイルを確認することです。したがって、Windows クライアントのローカル HOSTS ファイルでホスト名に割り当てられた IP アドレスが誤っている場合、HOSTS ファイルのエントリが修正されるか、Windows ネットワークの名前解決の順序が変更されるまで、ホスト名は誤った IP アドレスに解決されます（「Windows 95 と Windows NT で名前解決の順序を変更する方法」を参照）。

注意: 「Microsoft KB の記事で「Windows 2000 以降のバージョンではデフォルトで、以前のバージョンのノードタイプの構成により解決しようとする前に、DNS により名前を解決しようとする」とありますが、これは誤りです。

ハードウェア障害が発生している – DNS サーバーにハードウェア障害が発生していると、DNS サーバーによって維持されている DNS レコードが想定どおりに更新されず、クライアントに送信されるホスト - IP マッピングが正しくなくなる場合があります。
TCP / IP ポートがブロックされている - アプリケーションレイヤーのプロトコルまたはサービスに必要なポートがブロックされている場合、ネットワーク通信がブロックされます。
クライアントの TCP / IP 設定が正しくない - クライアントが正しく設定されていない場合、クライアントでさまざまな程度で接続の問題が発生していることが考えられます。この問題が発生するのは、クライアントが TCP/IP の自動設定を使用するように設定されており、設定情報を取得することができないか、誤った設定情報を受け取ったときです。

解決

ping ユーティリティを使用して、TCP/IP ネットワーク上のノード間の接続を確認します。

ping ユーティリティでは、ICMP (Internet Control Message Protocol) パケットがクライアントから、指定したネットワーク名または IP アドレスに送信されます。

C:\WINDOWS\system32>ping www.amazon.com

www.amazon.com [205.251.242.54] に対して 32 バイトのデータで ping を実行:

リクエストがタイムアウトしました。

205.251.242.54 の ping の統計:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

多くの公開サーバーによって着信 ICMP パケットの優先順位が下げられます。その結果、ping リクエストによって「Request timed out」レスポンスが返されることがあります。ping リクエストを開始するとき、以下のことを確認することが重要です。

ping リクエストにより IP アドレスに名前が解決されているか。たとえば、先ほどの例では、すべての ping リクエストがタイムアウトになっても、名前 www.amazon.com は IP アドレス 205.251.242.54 に解決されています。これが www.bamazon.com のような別のホスト名を使用していた場合、名前解決が失敗し ping リクエストは実行されません。
C:\WINDOWS\system32>ping www.bamazon.com
Ping request could not find host www.bamazon.com. 名前を確認して、もう一度お試しください。
名前が IP アドレスに解決される場合、ターゲットに別のアプリケーションレイヤーのプロトコルまたはサービスを介してアクセスできる可能性が高くなります。たとえば、www.amazon.com への ping リクエストがタイムアウトになった場合、http://www.amazon.com への接続は一般的に成功します。このターゲットが TCP ポート 80 上のブラウザーのリクエストを受け入れるウェブサーバーであるためです。
ping リクエストが成功して、応答が返された場合は、4 つの応答が妥当な時間以内（250 ミリ秒未満）に返されたことを確認します。ping リクエストの番号を指定するには -c スイッチを使用します。4 つ未満の応答が返された場合、または応答時間が 250 ミリ秒を超えた場合、追加のトラブルシューティング手順が必要になることがあります。ping リクエストのタイムアウトをミリ秒単位で指定するには、-w スイッチを使用します。停止するまで継続的にターゲットに対して ping を実行するには、-t スイッチを使用します。
IP アドレスがホスト名に解決されているか。アドレスからホスト名への解決をテストするには、-a スイッチを使用し、ターゲットの IP アドレスを指定します。たとえば、以下の ping リクエストでは、www.ubuntu.org に関連付けられているいずれかの IP アドレスに対してホスト名への解決をテストしています。
       C:\WINDOWS\system32>ping -a 82.98.134.233
       Pinging hl231.dinaserver.com [82.98.134.233] with 32 bytes of data:
       Reply from 82.98.134.233: bytes=32 time=166ms TTL=49
     Reply from 82.98.134.233: bytes=32 time=184ms TTL=49
   Reply from 82.98.134.233: bytes=32 time=176ms TTL=49
       Reply from 82.98.134.233: bytes=32 time=165ms TTL=49
   Ping statistics for 82.98.134.233:
           Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
       Approximate round trip times in milli-seconds:
           Minimum = 165ms, Maximum = 184ms, Average = 172ms

応答が hl231.dinaserver.com という名前を返していることに注目してください。これは、http://www.ubuntu.org へのリクエストを処理する負荷分散ウェブサーバーの 1 つです。

ICMP プロトコルの詳細については、「Understanding the ICMP Protocol (Part 1)」および「Understanding the ICMP Protocol (Part 2)」を参照してください。

Windows の tracert ユーティリティを使用したパケットの損失やルーティングの問題の特定

Windows の tracert ユーティリティでは、クライアントノードから指定したターゲットノードへのパスと、そのパスで認識された各ルーターでリクエストへのレスポンスにかかった時間（ミリ秒単位）が特定されます。デフォルトでは、tracert ユーティリティで最大 30 ホップが使用されます。クライアントとターゲットとの間のパスに 30 を超えるルーター（ホップ）が必要な場合は、-h スイッチを指定して最大ホップ数を増やすことができます。tracert リクエストが ICMP リクエストに対するレスポンスに依存しているため、ルート上の数ホップでは、優先順位の高いネットワークトラフィックが先に処理されるため、リクエストがドロップすることがあります。

以下の出力は、デフォルトの Windows の tracert コマンドを使用して作成されました。この例では、ホップ 1、2、3、15 で「Request timed out」というメッセージが返されています。

C:\Users\Administrator>tracert www.ubuntu.org

Tracing route to www.ubuntu.org [82.98.134.233]

over a maximum of 30 hops:

1 * * * Request timed out.

2 * * * Request timed out.

3 * * * Request timed out.

4 1 ms <1 ms <1 ms 100.64.16.13

5 1 ms 1 ms 1 ms 205.251.232.254

6 2 ms 3 ms 2 ms 205.251.232.148

7 9 ms 9 ms 9 ms 205.251.232.91

8 9 ms 8 ms 8 ms 205.251.226.188

9 10 ms 9 ms 9 ms ae-14.r04.sttlwa01.us.bb.gin.ntt.net [129.250.201.169]

10 10 ms 9 ms 7 ms ae-6.r21.sttlwa01.us.bb.gin.ntt.net [129.250.5.44]

11 75 ms 76 ms 91 ms ae-3.r22.nycmny01.us.bb.gin.ntt.net [129.250.2.50]

12 145 ms 145 ms 145 ms ae-5.r22.londen03.uk.bb.gin.ntt.net [129.250.3.127]

13 170 ms 168 ms 172 ms ae-6.r01.mdrdsp03.es.bb.gin.ntt.net [129.250.4.138]

14 171 ms 171 ms 168 ms dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net [62.73.183.78]

15 * * * Request timed out.

16 176 ms 165 ms 179 ms hl231.dinaserver.com [82.98.134.233]

Trace complete.

少数のリクエストがタイムアウトになっても、一般的に懸念する必要はありません。代わりに、ターゲットやルートの最終ホップでのパケット損失をモニタリングします。複数のホップにわたって蓄積されたパケット損失も問題として示されることがあります。

重要: Windows の tracert ユーティリティを使用してネットワーク接続のトラブルシューティングを行うときは、多くの場合、サーバーからクライアントに、その後、クライアントからサーバーに、両方向にコマンドを実行することが役立ちます。いずれかのパスでレイテンシーの差異が顕著である場合、Richard A Steenbergen によるすばらしい記事「Traceroute」(http://cluepon.net/ras/traceroute.pdf) を確認してみてください。この記事では、適切なトレース解析の複雑さについて詳細に説明されています。

サードパーティの Windows トレースユーティリティをインストールして使用することで機能を追加する

Tracetcp（http://simulatedsimian.github.io/tracetcp.html）には、トレース情報を取得する目的で TCP ポートを指定する機能が用意されています。この機能は、ソースとターゲットとの間の複数のルーターが ICMP に対して優先順位を下げるか完全にブロックする場合に特に便利です。
Winmtr（http://winmtr.net/）は Windows で Linux の mtr ユーティリティに相当します。

Keywords

Amazon Elastic Compute Cloud, Windows, ネットワークのトラブルシューティング, ping, tracert