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 ユーティリティでは、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 リクエストを開始するとき、以下のことを確認することが重要です。

  1. 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
  2. 名前が IP アドレスに解決される場合、ターゲットに別のアプリケーションレイヤーのプロトコルまたはサービスを介してアクセスできる可能性が高くなります。たとえば、www.amazon.com への ping リクエストがタイムアウトになったとしても、この宛先はポート 80 を使用したブラウザリクエストを受け取るウェブサーバーであるため、通常は http://www.amazon.com への接続は成功します。
  3. ping リクエストが成功して応答が返った場合は、その応答が妥当な時間内 (250 ms 未満) に返ったことを確認します。ping リクエストの番号を指定するには -c スイッチを使用します。指定した ping リクエストの半分以下しか返らない場合や、平均応答時間が 250 ms を超えている場合は、追加のトラブルシューティング手順を必要とすることがあります。ping リクエストのタイムアウトをミリ秒で指定するには、-W スイッチを使用します。停止するまで宛先に ping を打ち続けるには、次の例のように、-W スイッチに値 0 をつけます。
           sudo ping –W 0 www.ubuntu.org
    ping リクエストの生成を停止するには、キー組み合わせ Ctrl+C を押します。
  4. アドレスはホスト名に解決されますか?アドレスからホスト名への解決をテストするには、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 ユーティリティは、クライアントノードから指定された宛先ノードへのパスを識別し、またパス内で識別された各ルーターがリクエストに応答するまでの時間をミリ秒単位で識別します。デフォルトでは、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 コマンドは最新の出力を継続して提供するため、時間経過によるネットワークパフォーマンスを分析できます。

: Ubuntu Linux に mtr がインストールされていない場合は、次のコマンドを入力して入手してください。
       sudo apt-get install 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 ネットワークでは、方向が逆転するとノード間のパスが変更されるため、両方向でルートのトレース結果を取得することが重要です。

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

ping、traceroute、mtr を使用する方法の他にも、"looking glass" サーバーのようなインターネットサービスプロバイダーが提供するユーティリティも多数公開されています。これらの使用も検討してください。詳細については、Wikipedia の「Looking Glass Server」の記事を参照してください。

TCP/IP に関する問題のトラブルシューティングの詳細については、「Traceroute」を参照してください。

最もよく使う Linux コマンドを教えてください。


このページは役に立ちましたか? はい | いいえ

AWS サポートナリッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。