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

問題

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

短い説明

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

非認証の DNS サーバー - クライアントが正しく設定されていない不正な DNS サーバーからの情報をリクエストした場合、返された情報は信頼できません。
正しくない HOSTS ファイルエントリ – ほとんどのオペレーティングシステムでは、ホスト - IP マッピングを静的に定義する HOSTS ファイルが実装されています。Linux オペレーティングシステムでは、このファイルは通常 /etc/hosts に保存されており、次の形式を使用します。
1.2.3.4 hostname
1.2.3.4 は、hostname を参照する際に使用する物理 IP アドレスです。
ハードウェア障害が発生している – DNS サーバーにハードウェア障害が発生していると、DNS サーバーによって維持されている DNS レコードが想定どおりに更新されず、クライアントに送信されるホスト - IP マッピングが正しくなくなる場合があります。
TCP / IP ポートがブロックされている - アプリケーションレイヤーのプロトコルまたはサービスに必要なポートがブロックされている場合、ネットワーク通信がブロックされます。
クライアントの TCP / IP 設定が正しくない - クライアントが正しく設定されていない場合、クライアントでさまざまな程度で接続の問題が発生していることが考えられます。この問題が発生するのは、クライアントが TCP/IP の自動設定を使用するように設定されており、設定情報を取得することができないか、誤った設定情報を受け取ったときです。

解決

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

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

ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.amazon.com
PING www.amazon.com (54.239.19.16) 56(84) bytes of data.
--- www.amazon.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

多くの公開サーバーによって着信 ICMP パケットの優先順位が下げられます。その結果、ping リクエストで 100% パケットロス統計が返ることも珍しくありません。ping リクエストを開始するとき、以下のことを確認することが重要です。

ping リクエストにより IP アドレスに名前が解決されているか。たとえば、前述の例では ping レスポンスは返ってきませんでしたが、www.amazon.com という名前は IP アドレス 54.239.19.16 として解決されています。これが www.bamazon.com のような別のホスト名を使用していた場合、名前解決が失敗し ping リクエストは実行されません。
ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.bamazon.com
ping: unknown host www.bamazon.com
名前が IP アドレスに解決される場合、ターゲットに別のアプリケーションレイヤーのプロトコルまたはサービスを介してアクセスできる可能性が高くなります。たとえば、www.amazon.com への ping リクエストがタイムアウトになったとしても、この宛先はポート 80 を使用したブラウザリクエストを受け取るウェブサーバーであるため、通常は http://www.amazon.com への接続は成功します。
ping リクエストが成功して応答が返った場合は、その応答が妥当な時間内 (250 ms 未満) に返ったことを確認します。ping リクエストの番号を指定するには -c スイッチを使用します。指定した ping リクエストの半分以下しか返らない場合や、平均応答時間が 250 ms を超えている場合は、追加のトラブルシューティング手順を必要とすることがあります。ping リクエストのタイムアウトをミリ秒で指定するには、-W スイッチを使用します。停止するまで宛先に ping を打ち続けるには、次の例のように、-W スイッチに値 0 をつけます。
sudo ping –W 0 www.ubuntu.org
ping リクエストの生成を停止するには、キー組み合わせ Ctrl+C を押します。
アドレスはホスト名に解決されますか?アドレスからホスト名への解決をテストするには、Linux の nslookup コマンドを使用し、宛先 IP アドレスを指定します。たとえば、以下の非インタラクティブモード nslookup リクエストでは、www.ubuntu.org に関連付けられた IP アドレスの 1 つに対して、アドレスからホスト名への解決をテストしています。
       ubuntu@ip-10-0-0-252:~$ nslookup 82.98.134.233
       Server:    10.0.0.2
       Address:    10.0.0.2#53

       Non-authoritative answer:
       233.134.98.82.in-addr.arpa    name = hl231.dinaserver.com.

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

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

Linux traceroute ユーティリティを使用してパケットロスまたはルーティングの問題を検証する

Linux traceroute ユーティリティは、クライアントノードから指定された宛先ノードへのパスを識別し、またパス内で識別された各ルーターがリクエストに応答するまでの時間をミリ秒単位で識別します。デフォルトでは、traceroute ユーティリティはデフォルトの最大値である 30 ホップを使用します。クライアントと宛先間のパスに 30 を超えるルーターまたはホップが必要な場合は、-h スイッチを使用してホップの最大値を大きくできます。traceroute のリクエストは ICMP リクエストへの応答に依存するため、より優先度の高いネットワークトラフィックを優先して、ルートのホップの一部でリクエストが欠落することがあります。

以下の traceroute コマンドは Ubuntu Linux 14.04 のアマゾンウェブサービス EC2 インスタンスから発行されたものです。引数 -T -p 80 -n はポート 80 で TCP ベースのトレースを実行し、ホスト名ではなく IP アドレスを返します。ほとんどのインターネットデバイスでは ICMP ベースのトレースリクエストの優先度が下げられているため、Linux traceroute のオプションで ICMP 依存ではなく TCP ベースのトレースを指定すると便利です。IP アドレスのみを取得する Linux traceroute のオプションは、返されるホスト名が間違っていたり誤解を招く場合に便利です。

ubuntu@ip-10-0-0-252:~$ sudo traceroute -T -p 80 -n www.ubuntu.org

traceroute to www.ubuntu.org (82.98.134.233), 30 hops max, 60 byte packets

1 * * *

2 * * *

3 * * *

4 100.64.16.75 1.176 ms

100.64.16.129 1.059 ms

100.64.16.209 0.923 ms

5 54.239.48.178 3.958 ms

54.239.48.184 1.200 ms

54.239.48.178 1.805 ms

6 205.251.232.204 1.198 ms

205.251.232.154 1.793 ms

205.251.232.142 1.549 ms

7 205.251.232.76 6.341 ms

205.251.232.78 6.546 ms

205.251.232.76 7.611 ms

8 205.251.226.230 6.220 ms 7.418 ms

205.251.226.192 8.096 ms

9 198.104.202.189 9.178 ms

129.250.201.165 9.006 ms

198.104.202.181 9.001 ms

10 129.250.5.44 8.746 ms

129.250.5.48 8.912 ms

129.250.5.44 27.57 ms

11 * 129.250.2.50 86.83 ms *

12 129.250.3.127 153.9 ms 144.401 ms 161.867 ms

13 129.250.4.138 176.5 ms 165.466 ms 181.772 ms

14 62.73.183.78 166.5 ms 166.834 ms 169.297 ms

15 * * *

16 82.98.134.233 177.9 ms 164.656 ms 169.607 ms

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

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

Linux mtr コマンドを使用する

Linux mtr コマンドは最新の出力を継続して提供するため、時間経過によるネットワークパフォーマンスを分析できます。

注: Ubuntu Linux に mtr がインストールされていない場合は、次のコマンドを入力して入手してください。
sudo apt-get install mtr

Ubuntu Linux からの mtr コマンドの実行

mtr コマンドラインのオプションのリストについては、mtr -h を実行してください。

ubuntu@ip-10-0-0-252:~$ mtr www.ubuntu.org

My traceroute [v0.85]

ip-10-0-0-252 (0.0.0.0) Sat Nov 22 18:54:13 2014

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. ???

2. ???

3. ???

4. 100.64.16.139 0.0% 64 2.4 2.3 0.6 32.6 5.4

5. 54.239.48.186 0.0% 64 0.9 2.2 0.8 19.8 4.0

6. 205.251.232.210 0.0% 64 1.5 2.4 0.7 17.7 3.7

7. 205.251.232.76 0.0% 64 37.6 11.1 6.1 47.2 7.9

8. 205.251.225.165 0.0% 64 14.2 7.1 5.6 28.4 4.2

9. ae-8.r05.sttlwa01.us.bb.gin.ntt.net 0.0% 63 7.7 9.3 7.3 26.7 4.9

10. ae-7.r21.sttlwa01.us.bb.gin.ntt.net 0.0% 63 7.4 10.2 7.2 35.4 6.1

11. ae-3.r22.nycmny01.us.bb.gin.ntt.net 22.2% 63 73.7 82.2 73.1 101.7 8.8

12. ae-5.r22.londen03.uk.bb.gin.ntt.net 0.0% 63 153.1 159.2 142.1 223.3 17.7

13. ae-6.r01.mdrdsp03.es.bb.gin.ntt.net 0.0% 63 174.9 176.1 165.4 193.2 6.3

14. dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net 0.0% 63 174.6 182.7 164.1 263.1 21.3

15. ???

16. hl231.dinaserver.com 0.0% 63 175.5 178.4 166.1 200.4 7.4

mtr には、--report オプションもあります。各ホップに 10 個の ping パケットを送信した結果を要約します。

ubuntu@ip-10-0-0-252:~$ mtr --report www.ubuntu.org

Start: Sat Nov 22 19:06:10 2014

HOST: ip-10-0-0-252 Loss% Snt Last Avg Best Wrst StDev

1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0

2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0

3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0

4.|-- 100.64.16.139 0.0% 10 0.8 0.8 0.5 1.4 0.0

5.|-- 54.239.48.186 0.0% 10 1.0 1.1 0.8 2.0 0.0

6.|-- 205.251.232.210 0.0% 10 0.8 1.3 0.8 2.9 0.5

7.|-- 205.251.232.76 0.0% 10 6.1 8.3 6.1 18.2 3.4

8.|-- 205.251.225.165 0.0% 10 6.3 5.8 5.6 6.3 0.0

9.|-- ae-8.r05.sttlwa01.us.bb.g 0.0% 10 7.5 7.5 7.4 7.6 0.0

10.|-- ae-7.r21.sttlwa01.us.bb.g 0.0% 10 8.8 10.2 7.3 33.4 8.1

11.|-- ae-3.r22.nycmny01.us.bb.g 0.0% 10 73.8 78.2 73.3 108.2 10.9

12.|-- ae-5.r22.londen03.uk.bb.g 10.0% 10 151.6 154.8 145.4 169.5 6.5

13.|-- ae-6.r01.mdrdsp03.es.bb.g 0.0% 10 175.0 174.1 165.7 178.3 3.5

14.|-- dinahosting-0.r01.mdrdsp0 0.0% 10 173.8 172.2 165.1 176.4 4.3

15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0

16.|-- hl231.dinaserver.com 10.0% 10 183.1 177.9 168.1 192.4 7.5

注: TCP/IP ネットワークでは、方向が逆転するとノード間のパスが変更されるため、両方向でルートのトレース結果を取得することが重要です。

Keywords

Amazon Elastic Compute Cloud、Linux、ネットワークのトラブルシューティング、ping、traceroute、tracert、mtr