Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
如何对 VPN 连接上的数据包丢失问题进行故障排除?
我的 VPN 连接出现持续或间歇性的数据包丢失和高延迟问题。
解决方法
检查资源利用率
CPU、内存或网络带宽使用率高会导致数据包丢失。监控 CPUUtilization、NetworkIn、NetworkOut、NetworkPacketsIn 和 NetworkPacketsOut Amazon CloudWatch 指标。检查源主机和目标主机上的资源利用率。
检查是否存在网络问题
要检查是否存在 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,请使用 tracert 工具而不是 traceroute。默认情况下,所有 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,请使用 Wireshark 而不是 **tcpdump **。要下载该工具,请参阅 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
相关信息

相关内容
- 已提问 2 年前lg...
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 2 年前