VPC 内の EC2 Linux または Windows インスタンスと、インターネットゲートウェイ経由のオンプレミスホスト間のネットワークパフォーマンスの問題をトラブルシューティングする方法を教えてください。

所要時間4分

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとオンプレミスホストの間で、インターネットゲートウェイ経由のパケットロスやレイテンシーの問題をトラブルシューティングしたいです。

簡単な説明

パケットロスや遅延などのネットワーク問題を診断するには、まずネットワークをテストして問題の原因を特定します。問題のトラブルシューティングを行う前に、パフォーマンスの結果をベンチマークするのがベストプラクティスです。

前提条件:

ネットワークユーティリティが両方のエンドポイント (EC2 インスタンスとオンプレミスホスト) にインストールされていることを確認してください。
拡張ネットワーキングをサポートする EC2 インスタンスを使用し、ドライバーが最新であることを確認してください。拡張ネットワーキングが有効になっていない場合は、「Linux での ENA カーネルドライバーのトラブルシューティング」または「Elastic Network Adapter Windows ドライバーのトラブルシューティング」を参照してください。
EC2 インスタンスに接続してインスタンスにアクセスします。EC2 インスタンスとオンプレミスホスト間のエンドツーエンドの接続を確認します。

解決策

ネットワークのトラブルシューティングとテストに役立つ次のツールをインストールしてください。

AWSSupport-SetupIPMonitoringFromVPC: パケットロス、遅延、MTR、tcptraceroute、tracepath などのネットワークメトリクスを収集します。
MTR: ICMP または TCP のパケット損失と遅延をチェックする
Traceroute: 遅延またはルーティングの問題を特定します。
Hping3: エンドツーエンドの TCP パケット損失と遅延の問題を特定します
Tcpdump: パケットキャプチャのサンプルを分析します。

Traceroute または MTR レポートの確認

ボトムアップアプローチを使用して、traceroute または MTR レポートのホップを確認します。ボトムアップアプローチでは、最初に最後のホップまたは宛先の損失をチェックし、次に前のホップを確認します。

パケットロスまたは遅延の問題がラストホップまで続く場合は、ネットワークまたはルーティングに問題がある可能性があります。
該当ノードにコントロールプレーンのレート制限がある場合、パス内の 1 ホップでパケット損失または遅延が発生する可能性があります。
報告された最後のホップがコマンドで記録された宛先であるかどうかを確認します。最後のホップが目的地として表示されていない場合、制限の厳しいセキュリティグループが原因の可能性があります。

AWSSupport-SetupIPMonitoringFromVPC を使用してパフォーマンスをテストする

この組み込みツールは、ネットワークのトラブルシューティングに必要な多くのメトリックを収集します。詳細については、「Amazon VPC からのネットワーク接続のデバッグツール」を参照してください。

Linux インスタンスのパフォーマンストラブルシューティング

Linux のパフォーマンス統計情報を確認する

ソースインスタンスまたは宛先インスタンスにアクセスできる場合は、CPU、メモリ使用率、および負荷平均に問題がないかどうかを確認します。

MTR を使用してパフォーマンスをテストする

Linux MTR コマンドは、継続的に更新される出力を提供します。この診断ツールは、traceroute と ping ユーティリティの機能を組み合わせたものです。このツールの出力により、ネットワークパフォーマンスを分析できます。ほとんどの Linux ディストリビューションには、traceroute と MTR があらかじめインストールされています。ディストリビューションのソフトウェアパッケージマネージャーから MTR をダウンロードすることもできます。

次のコマンドを実行して MTR をインストールします。

Amazon Linux の場合:

sudo yum install mtr

Ubuntu の場合:

sudo apt-get install mtr-tiny

MTR を使用してネットワークのパフォーマンスをテストするには、このテストを EC2 インスタンスのパブリック IP アドレスとオンプレミスホストの間で双方向で実行します。方向が逆になると、TCP/IP ネットワーク上のノード間のパスが変わる可能性があります。両方向の MTR 結果を取得するのがベストプラクティスです。ほとんどのインターネットデバイスは ICMP ベースのトレース要求の優先順位を下げるため、ICMP の代わりに TCP ベースのトレースを使用できます。

パケットロスを確認してください。通常、シングルホップでのパケット損失は問題ではありません。この損失は、「ICMP time exceeded」メッセージがドロップされる原因となるコントロールプレーンポリシーが原因である可能性があります。宛先ホップまでの持続的なパケット損失、または複数のホップにわたるパケット損失に気付いた場合は、この損失が問題を示している可能性があります。

**注:**いくつかのリクエストがタイムアウトするのは一般的です。

PUBLIC_IP を、パブリック IP の EC2 インスタンスまたはオンプレミスホストのアドレスに置き換えてください。

ICMP ベースの MTR:

mtr -n -c 200 PUBLIC_IP --report

TCP ベースの MTR:

mtr -n -T -c 200 PUBLIC_IP --report

-T 引数は TCP ベースの MTR を実行し、report オプションで MTR をレポートモードにします。MTR は -c オプションで指定されたサイクル数だけ実行されます。統計情報を出力し、その後終了します。

**注:TCP ベースの MTR は、宛先 TCP ポート 80 をテストし、特定の宛先 TCP ポート (-P ** の後にポート番号を付けたもの) をテストします。MTR 宛先 TCP ポート 443 の例を次に示します。

mtr -n -T -c 200 PUBLIC_IP -P 443 --report

traceroute を使用してパフォーマンスをテストする

Linux traceroute ユーティリティは、クライアントノードから宛先ノードまでのパスを識別します。このユーティリティは、各ルータが要求に応答するまでの時間をミリ秒単位で記録します。また、各ホップが宛先に到達するまでにかかる時間も計算します。

次のコマンドを実行して traceroute をインストールします。

Amazon Linux の場合:

sudo yum install traceroute

Ubuntu の場合:

sudo apt-get update

 `sudo apt-get install traceroute`

注: MTR レポートを実行する場合、traceroute は不要です。MTR は、遅延とパケット損失の統計情報を宛先に提供します。

ポート 22 またはテストするポートが両方向に開いていることを確認します。traceroute を使用してネットワーク接続をトラブルシューティングするには、クライアントからサーバーに対してコマンドを実行します。次に、サーバーからクライアントにコマンドを実行し直します。TCP/IP ネットワーク上のノード間のパスは、方向を逆にすると変化する可能性があります。ほとんどのインターネットデバイスは ICMP ベースのトレース要求の優先順位を下げるため、ICMP の代わりに (アプリケーションポート) TCP ベースのトレースを使用してください。

ICMP ベースのトレースルート:

sudo traceroute -I PUBLIC_IP

TCP ベースのトレースルート:

sudo traceroute -n -T -p 22 PUBLIC_IP

引数 -T -p 22 -n は、ポート 22 で TCP ベースのトレースを実行します。

**注:**テストにはアプリケーション固有のポートを使用できます。特定のポートを使用して、アプリケーショントラフィックをドロップしているパスに中間デバイスがあるかどうかを確認します。

hping3 を使用してパフォーマンスをテストする

Hping3 は、TCP/IP パケットのアセンブリおよび分析を行うコマンドラインツールで、TCP 接続を介したエンドツーエンドのパケットロスと遅延を測定します。Die.net のサイトから hping3 をダウンロードしてください。

ICMP エコーリクエストに加えて、hping3 は TCP、UDP、および RAW-IP プロトコルをサポートしています。また、hping3 には traceroute モードが含まれており、隠れたチャネルを介してファイルを送信することも可能です。Hping3 は、ホストのスキャン、侵入テストの支援、侵入検知システムのテスト、およびホスト間のファイル送信を行うことができます。

MTR と traceroute はホップごとのレイテンシーをキャプチャします。ただし、パケット損失に加えて、hping3 の結果では TCP 経由のエンドツーエンドの最小/平均/最大レイテンシーが示されています。

次のコマンドを実行して hping3 をインストールします。

Amazon Linux 2 の場合:

RHEL 7 用の EPEL リリースパッケージをインストールし、その後 EPEL リポジトリを有効化します。

sudo amazon-linux-extras install epel -y

Amazon Linux 2 の場合:

sudo yum --enablerepo=epel install hping3

Ubuntu の場合:

sudo apt-get install hping3

次のコマンドは、ポート 0 を介して 50 個の TCP SYN パケットを送信します。デフォルトでは、hping3 はウィンドウサイズ 64 で、TCP フラグなしの TCP ヘッダーをターゲットホストのポート 0 に送信します。

sudo hping3 -S -c 50 -V PUBLIC_IP

次のコマンドは、ポート 22 を介して 50 個の TCP SYN パケットを送信します。

sudo hping3 -S -c 50 -V PUBLIC_IP -p 22

**注:**ポート 22 またはテストしているポートが開いていることを確認してください。

tcpdump を使用してパケットキャプチャサンプルをテストする

パケットロスやレイテンシーの問題を診断するときは、EC2 インスタンスとオンプレミスホストで同時にパケットキャプチャを実行するのがベストプラクティスです。これらのキャプチャは、要求パケットと応答パケットを識別するのに役立ち、ネットワーク層とアプリケーション層で問題を切り分けることができます。また、最初にパケットキャプチャを開始してからトラフィックを開始することもベストプラクティスです。このアクション順序は、フローのすべてのパケットをキャプチャするのに役立ちます。

次のコマンドを実行して tcpdump をインストールします。

Amazon Linux の場合:

sudo yum install tcpdump

Ubuntu の場合:

sudo apt-get install tcpdump

tcpdump をインストールした後、以下のコマンドを実行して TCP ポート 22 のトラフィックをキャプチャし、その出力を pcap ファイルに保存します。

sudo tcpdump -i eth0 port 22 -s0 -w samplecapture.pcap

**注:**tcpdump フラグ **-i ** は、tcpdump がトラフィックをキャプチャするインスタンス上のインターフェイスを指定します。環境に応じて、インターフェースを eth0 から適切に構成されたインターフェイスに変更する必要がある場合があります。

Windows のパフォーマンストラブルシューティング

ECN 機能を確認

Explicit Congestion Notification (ECN) 機能が有効かどうかを確認するには、以下のコマンドを実行します。
```
netsh interface tcp show global
```

ECN 機能が有効になっている場合、無効にするには、次のコマンドを実行します。

- netsh interface tcp set global ecncapability=disabled

パフォーマンスが改善されない場合は、次のコマンドを実行して ECN 機能を再度有効にします。

netsh interface tcp set global ecncapability=enabled

ホップの確認と TCP ポート接続のトラブルシューティング
まず、MTR または tracert を使用してホップを確認します。

MTR メソッド:

WinMTR を SourceForge.net のウェブサイトからダウンロードしてインストールします。
[Host] セクションに宛先 IP アドレスを入力し、[Start] を選択します。
テストを 1 分間実行してから、[Stop] を選択します。
[Copy text to clipboard] を選択し、出力をテキストファイルに貼り付けます。
[%] 列のパケットロスが宛先に伝播されていないかを検索します。
**注:**No response from host メッセージが表示されるホップは無視してください。このメッセージは、特定のホップが ICMP プローブに応答していないことを示しています。
ボトムアップアプローチを使用して MTR レポートのホップを確認します。例えば、最後のホップまたは宛先でパケットロスがないか確認し、次に、その前のホップを確認します。

Tracert メソッド:
MTR をインストールしたくない場合、tracert コマンドユーティリティを使用します。

宛先の URL または IP アドレスに対して tracert を実行します。
ラウンドトリップ時間（RTT）が急激に急上昇しているホップを探します。RTT の急激な上昇は、ノードに高負荷がかかっていることを示している可能性があります。この負荷により、トラフィックに遅延やパケットドロップが発生する可能性があります。
注:-d オプションは IP アドレスをホスト名に変換しません。IP からホスト名への解決が必要な場合は、-d を削除してください。

tracert -d PUBLIC_IP
次に、TCP ポート接続を確認します。

注: WinMTR と tracert はどちらも ICMP ベースのため、TCP ポート接続のトラブルシューティングには tracetcp を使用できます。

NetworkHunt.com のウェブサイトから tracetcp ZIP ファイルをダウンロードします。
tracetcp ZIP ファイルを解凍します。
tracetcp.exe を C ドライブにコピーします。
WinPcap.org から WinPcap をダウンロードし、インストールします。
コマンドプロンプトを開き、C:\Users\username>cd コマンドを使用して WinPcap を C ドライブにルーティングします。
次のコマンドを実行して tracetcp を実行します。
tracetcp.exehostname:port
または、
tracetcp.exe ip:port

Windows タスクマネージャーを確認する

ソースインスタンスまたは宛先インスタンスにアクセスできる場合は、Windows タスクマネージャーを確認してください。CPU とメモリの使用率、または負荷平均に関する問題を探します。

パケットキャプチャを行います。

**注:**パケットロスやレイテンシーの問題を診断する場合、EC2 インスタンスとオンプレミスホストで同時にパケットキャプチャを実行するのがベストプラクティスです。このアクションは、要求パケットと応答パケットを識別して、ネットワーク層とアプリケーション層の問題を特定するのに役立ちます。また、最初にパケットキャプチャを開始してからトラフィックを開始することもベストプラクティスです。これらのアクションは、フローのすべてのパケットをキャプチャするのに役立ちます。

Wireshark.org から Wireshark をダウンロードし、インストールしてください。その後、パケットキャプチャを実行します。次に、パケットキャプチャを行います。
以下のフィルタを使用して、特定の送信元間のトラフィックをパケットキャプチャ内で抽出します。(ip.addr eq source_IP) &&(tcp.flags.syn == 1)
この出力では、その送信元 IP から開始されたすべての TCP ストリームが表示されます。
関連する送信元 IP と宛先 IP を含む行を選択します。
該当する送信元 IP と宛先 IP を含む行を選択し、コンテキスト (右クリック) メニューから Follow → TCP Stream を選択します。このアクションにより、調査対象の送信元 IP と宛先 IP の間の TCP フローが発生します。
再送信、重複パケット、または TCP window full や Window size zero などの TCP ウィンドウサイズ通知がないか確認します。これらの通知は、TCP バッファが容量不足になっている可能性を示すことがあります。