VPN 接続でのパケット損失のトラブルシューティング方法を教えてください。
VPN 接続で、連続的または断続的なパケット損失が起こったり、遅延が長くなったりしています。
解決策
リソース使用率を確認する
CPU、メモリ、またはネットワーク帯域幅の使用率が高いと、パケット損失の原因となります。Amazon CloudWatch メトリクス CPUUtilization、NetworkIn、NetworkOut、NetworkPacketsIn、NetworkPacketsOut を監視します。ソースホストおよびターゲットホストのリソース使用率を確認します。
ネットワークの問題を確認する
ICMP または TCP パケットの損失または遅延を確認するには、mtr ネットワークツールをローカルのオンプレミスマシンにインストールします。Amazon Elastic Compute Cloud (Amazon EC2) にも mtr をインストールします。
Amazon Linux では、次のコマンドを実行します。
sudo yum install mtr
Ubuntu では、次のコマンドを実行します。
sudo apt-get install mtr
Windows の場合は、SourceForge の WinMTR を使用してください。
注: WinMTR は TCP ベースの MTR をサポートしていません。
AWS VPN トンネル内でパケットロスが発生していないかどうかを確認します。トンネルを使用しているオンプレミスホストから Amazon EC2 インスタンスのプライベート IP アドレスへの接続をテストします。さらに、オンプレミスのカスタマーゲートウェイから各トンネルのパブリック IP アドレスへの接続をテストします。カスタマーゲートウェイデバイスで mtr を使用できない場合は、カスタマーゲートウェイデバイスと同じインターネット接続を使用しているホストを使用します。
重要: 両方向の mtr 結果を取得します。TCP と IP アドレスネットワーク上のノード間のパスは、方向を逆にすると変化する可能性があります。
ICMP を使用してプライベート IP アドレスで次のテストを実行します。
mtr -b -c 50 -rw Host_Instance_Private_IP
TCP を使用してプライベート IP アドレスで次のテストを実行します。
mtr -b -c 50 -rw -T -P 443 Host_Instance_Private_IP
注: 上記のコマンドで、Host_instance_private_IP はお使いの EC2 インスタンスまたはオンプレミスホストのプライベート IP アドレスに、443 は実際のポートに置き換えます。
ICMP を使用してパブリック IP アドレスで次のテストを実行します。
mtr -b -c 50 -rw AWS_Tunnel_Public_IP
UDP を使用してパブリック IP アドレスで次のテストを実行します。
mtr -b -c 50 -rw -u -P 500 AWS_Tunnel_Public_IP
mtr -b -c 50 -rw -u -P 4500 AWS_Tunnel_Public_IP
注: 上記のコマンドで、AWS_Tunnel_Public_IP はトンネルのパブリック IP アドレスに、500 および 4500 は実際の UDP ポートに置き換えます。
シングルホップでは、パケット損失とラウンドトリップ時間 (RTT) の増加が想定されます。パケットロスと RTT の増加が問題になるのは、すべてのホップで確認される場合のみです。次の出力例は、ホップ 3 から始まり、最終ホップまで続く一貫した損失を示しています。
HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9 6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
次の例は、UDP ポート 500 を使用するトンネルのパブリック IP アドレスのテストを示しています。ホップ 1 と 4 の間の [Loss%] 列は損失率を示しています。ただし、ホップ 5 と 13 の間ではパケット損失は発生しないため、この損失は重大なパケット損失とは見なされません。ホップ 14 と最終ホップの間の損失は、100% の損失で終わる持続的な損失であるため、パケット損失が有意であることを示しています。この例では、問題はホップ 14 で発生します。
sudo mtr -b -c 30 -rw -u -P 500 185.156.137.215 Start: 2024-08-28T18:59:49+0000 HOST: ip-10-100-20-25 Loss% Snt Last Avg Best Wrst StDev 1. |-- ??? 100.0 30 0.0 0.0 0.0 0.0 0.0 2. |-- 240.1.84.6 73.3% 30 0.5 0.5 0.5 0.5 0.0 3. |-- 242.3.160.33 63.3% 30 1.4 1.0 0.6 1.4 0.3 4. |-- 241.0.6.67 63.3% 30 0.5 6.7 0.5 12.4 5.9 5. |-- 100.100.6.39 0.0% 30 0.5 3.1 0.5 27.7 6.2 6. |-- 100.100.72.6 0.0% 30 1.1 9.9 0.5 96.0 17.6 7. |-- 100.91.209.81 0.0% 30 11.5 20.6 11.1 127.3 24.3 8. |-- 100.100.6.107 0.0% 30 12.8 19.9 11.6 127.8 22.6 9. |-- 99.83.70.223 0.0% 30 12.3 18.1 11.7 117.0 19.2 10.|-- 100.100.92.209 0.0% 30 11.9 13.7 11.6 50.6 7.0 11.|-- 100.100.16.88 0.0% 30 13.2 14.0 11.9 33.1 3.8 12.|-- gw-as249.retn.net (87.245.240.41) 0.0% 30 13.2 13.2 11.8 19.9 1.5 13.|-- thw.sw01.loudltd.net (185.156.136.14) 0.0% 30 11.4 12.5 11.4 14.2 1.0 14.|-- no-ptr.pckear.com (185.116.108.124) 20.0% 30 14.8 13.2 12.5 14.8 0.5 15.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 14.1 13.6 12.5 15.5 0.8 16.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 16.5 14.5 13.3 16.5 0.8 17.|-- ??? 100.0% 30 0.0 0.0 0.0 0.0 0.0
遅延とルーティングの問題を確認する
traceroute ツールは、データがネットワーク上でたどる経路を表示します。この情報を使用して、遅延が発生する場所を特定します。
Amazon Linux に traceroute をインストールするには、次のコマンドを実行します。
sudo yum install traceroute
Ubuntu に traceroute をインストールするには、次のコマンドを実行します。
sudo apt-get install traceroute
Windows の場合は、traceroute ではなく、tracert ツールを使用します。このツールは、デフォルトですべての Windows マシンにインストールされています。tracert は、TCP トレースを許可しないことに注意してください。tracetcp ツールをインストールすると、すべての機能を活用できます。
Amazon EC2 インスタンスのプライベートおよびパブリック IP アドレスと、オンプレミスホストの間で次のテストを実行します。
重要: 両方向で結果を取得します。TCP と IP アドレスネットワーク上のノード間のパスは、方向を逆にすると変化する可能性があります。
Linux の場合は、次のコマンドを実行します。
sudo traceroute -T -p 80 Host_IP
注: Host_IP はお使いの EC2 インスタンスまたはオンプレミスホストのプライベート IP アドレスに、80 は実際のポートに置き換えます。精度を高めるため、上記の例では TCP ベースのトレース (T) を使用してトンネル内のトラフィックのパスをテストしています。インターネット経由のトラフィックのパスをテストするには、**Host_IP ** をトンネルのパブリック IP アドレスに置き換えます。
次の例のような出力が表示されます。
traceroute -T -p 443 aws.com traceroute to aws.com (3.161.213.43), 30 hops max, 60 byte packets 1 SEA-1801842641.mshome.net (172.28.96.1) 0.363 ms 0.346 ms 0.362 ms 2 192.168.50.1 (192.168.50.1) 5.514 ms 5.508 ms 5.501 ms 3 172.27.232.1 (172.27.232.1) 45.179 ms 52.879 ms 52.871 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 server.yul62.r.ct.net (3.161.213.43) 57.452 ms 57.741 ms 62.604 ms
この出力例は、応答が発生しない中間ホップを示しています。デバイスは要求された 443 ポートで応答しませんでしたが、宛先が期待どおりに応答するため、問題とはなりません。
Windows の場合は、tracert を実行します。または、tracetcp をインストール済みの場合は、次の PowerShell コマンドを実行します。
tracetcp.exe Host_IP:80
注: Host_IP はお使いの EC2 インスタンスまたはオンプレミスホストのプライベート IP アドレスに、80 は実際のポートに置き換えます。精度を高めるため、上記の例では TCP ベースのトレース (T) を使用してトンネル内のトラフィックのパスをテストしています。インターネット経由のトラフィックのパスをテストするには、**Host_IP ** をトンネルのパブリック IP アドレスに置き換えます。
次の例のような出力が表示されます。
PS C:\Users\UserA> tracetcp.exe aws.com:443 Tracing route to 18.239.168.29 [server-18-239-168-29.bos50.r.cloudfront.net] on port 443 Over a maximum of 30 hops. 1 5 ms 7 ms 6 ms 192.168.50.1 2 41 ms 42 ms 44 ms 172.27.232.1 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 51 ms 43 ms 45 ms 241.0.11.143 7 62 ms 54 ms 43 ms 241.0.11.135 8 53 ms 53 ms 55 ms 240.4.8.24 9 52 ms 56 ms 53 ms 240.4.8.17 10 56 ms 59 ms 62 ms 240.64.239.162 11 57 ms 56 ms 61 ms 240.64.239.162 12 57 ms 55 ms 57 ms 240.64.239.162 13 58 ms Destination Reached in 54 ms. Connection established to 18.239.168.29 Trace Complete.
エンドツーエンドの TCP パフォーマンスをテストする
hping3 を使用して、エンドツーエンドの TCP パケット損失と遅延をテストします。このツールを使用すると、ホスト間の TCP パフォーマンスを直接評価できます。
Amazon Linux に hping3 を インストールするには、次のコマンドを実行します。
sudo yum --enablerepo=epel install hping3
Ubuntu に hping3 をインストールするには、次のコマンドを実行します。
sudo apt-get install hping3
hping3 を実行するには、次のコマンドを実行します。
hping3 -S -c 50 -V Host_IP
注: Host_IP は、お使いの EC2 インスタンスまたはオンプレミスホストのプライベート IP アドレス、またはトンネルのパブリック IP アドレスに置き換えます。
次の出力例は、ポート TCP 8443 を使用する VPN エンドポイントのパブリック IP アドレスに対するテストを示しています。
sudo hping3 -S -c 3 -p 8443 -V 34.233.155.9 using eth0, addr: 172.28.100.111, MTU: 1500 HPING 34.233.155.9 (eth0 34.233.155.9): S set, 40 headers + 0 data bytes len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=0 win=26883 rtt=49.6 ms seq=2996814187 ack=1585541078 sum=22f7 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=1 win=26883 rtt=49.6 ms seq=3555645549 ack=1207738370 sum=29a5 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=2 win=26883 rtt=49.2 ms seq=4045561197 ack=742863285 sum=f78c urp=0
ネットワークまたはアプリケーションの問題を特定する
この問題が発生したときに、EC2 インスタンスおよびオンプレミスホストで同時にパケットをキャプチャできます。パケットキャプチャを使用して、ネットワークまたはアプリケーションの問題を特定します。
Linux インスタンスのパケットキャプチャを取得するには、tcpdump を使用します。
Amazon Linux に tcpdump をインストールするには、次のコマンドを実行します。
sudo yum install tcpdump
Ubuntu に tcpdump をインストールするには、次のコマンドを実行します。
sudo apt-get install tcpdump
Windows の場合は、tcpdump ではなく、Wireshark を使用してください。ツールのダウンロードについては、Wireshark のウェブサイトで「Wireshark のダウンロード」を参照してください。
パケットキャプチャは次の例のようになります。
tcpdump -i any -nnvv port 500 and port 4500 tcpdump: listening on any, link-type EN10MB (Ethernet), capture size 65535 bytes 18:12:54.944933 IP (tos 0x0, ttl 63, id 43082, offset 0, flags [DF], proto UDP (17), length 212) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=7080)(type=enc value=aes)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024)))) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) out slot1/tmm0 lis=$_ike_1061b_out_23.20.145.20 port=1.0 trunk= 18:12:54.946069 IP (tos 0x0, ttl 253, id 56278, offset 0, flags [none], proto UDP (17), length 152) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifedura tion value=7080)))) (vid: len=16) (vid: len=16) in slot1/tmm0 lis= port=1.0 trunk= 18:12:54.949988 IP (tos 0x0, ttl 63, id 43084, offset 0, flags [DF], proto UDP (17), length 256) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 I ident: (ke: key len=128) (nonce: n len=16 data=(e84ae917994501b5b4f4...1a547b3cf720e35995f5b0c69198c9f796b5d9f9)) (pay20) (pay20) out slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk= 18:12:54.951858 IP (tos 0x0, ttl 253, id 56279, offset 0, flags [none], proto UDP (17), length 272) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (ke: key len=128) (nonce: n len=32 data=(c5170686e88069e33323...4448aaf06cc37d4b32d67df97e275e5756a534d8)) (pay20) (pay20) in slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk=
(Windows のみ) ECN を無効にする
Windows インスタンスで明示的な輻輳通知 (ECN) が有効になっていると、パケットロスやパフォーマンスの問題が発生する可能性があります。
ECN が有効になっているかどうかを確認するには、次の PowerShell コマンドを実行します。
netsh interface tcp show global
ECN を無効にするには、次の PowerShell コマンドを実行します。
netsh interface tcp set global ecncapability=disabled
関連情報
Site-to-Site VPN を使用すると、アプリケーションの遅延やパフォーマンスの問題が発生する理由を知りたいです
関連するコンテンツ
- AWS公式更新しました 3年前
- AWS公式更新しました 2年前
- AWS公式更新しました 1年前
