本文已参与「新人创作礼」活动，一起开启掘金创作之路。
起因是阿里云跨境链路（美国ECS与北京ECS）有一个实例突然调用不通问题，最终没有给出明确的结果，重新起了个实例好了。 虽然没有定位到问题，但也学到了一些网络链路测试和分析的一些知识，特此分享。
mtr链路测试和分析
mtr（My traceroute）几乎是所有Linux发行版本预装的网络测试工具。其将ping和traceroute的功能合并，所以功能更强大。mtr默认发送ICMP数据包进行链路探测。您也可以通过-u参数来指定使用UDP数据包进行探测。相对于traceroute只会做一次链路跟踪测试，mtr会对链路上的相关节点做持续探测并给出相应的统计信息。所以，mtr能避免节点波动对测试结果的影响，所以其测试结果更正确，建议优先使用。
请用mtr测试，把结果发给我们帮您分析。
具体的请参考以下链接：
Windows下的mtr工具使用方法您参考：help.aliyun.com/knowledge_d… 工具（建议优先使用）
Linux下的mtr工具使用方法您参考：help.aliyun.com/knowledge_d… 命令行工具（建议优先使用）
请用mtr -r 加访问域名测试
# 1. 获取本地网络对应的公网IP
# 2. 正向链路测试（ping和mtr）
# 3. 反向链路测试（ping和mtr）
# 4. 测试结果分析
另外还有一个工具，traceroute也是几乎所有Linux发行版本预装的网络测试工具，用于跟踪Internet协议（IP）数据包传送到目标地址时经过的路径。
tracetcp端口可用性探测
请用tracetcp来测试一下看在那个设备有端口过滤，可以参考：help.aliyun.com/knowledge_d…
# 1. 实例安全组检查
# 2. 端口相关服务检查
netstat -ntpl|grep [$Port]
# 3. 检查目标服务器的防火墙配置
iptables -nL
# 4. 通过探测工具进行检查
traceroute [-n] -T -p [$Port] [$Host]
traceroute -n -T -p 22 223.5.5.5
探测结果如下，目标端口在第11跳之后就没有数据返回。
[root@mycentos ~]# traceroute -T -p 135 www.baidu.com
traceroute to www.baidu.com (111.13.100.92), 30 hops max, 60 byte packets
1 * * *
2 1X.X.X.X (1X.X.X.X) 4.115 ms 4.397 ms 4.679 ms
3 2X.X.X.X (2X.X.X.X) 901.921 ms 902.762 ms 902.338 ms
4 3X.X.X.X (3X.X.X.X) 2.187 ms 1.392 ms 2.266 ms
5 * * *
6 5X.X.X.X (5X.X.X.X) 1.688 ms 1.465 ms 1.475 ms
7 6X.X.X.X (6X.X.X.X) 27.729 ms 27.708 ms 27.636 ms
8 * * *
9 * * *
10 111.13.98.249 (111.13.98.249) 28.922 ms 111.13.98.253 (111.13.98.253) 29.030 ms 28.916 ms
11 111.13.108.22 (111.13.108.22) 29.169 ms 28.893 ms 111.13.108.33 (111.13.108.33) 30.986 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
tcpdump抓包
在故障复现的时候抓包，可以使用下面的方法抓包看一下。能帮助您查找问题
Windows：
- 在Wireshark 界面中，选择 Capture -》 Interface ，选择对应连接的内网网卡后 -》 Option -》 在 File 输入框中输入要保存的文件 1.cap，然后点击 start 开始抓包。
- 复现问题。
- 问题复现后，停止抓包。
- 将1.cap 压缩为zip格式提供给我们
Linux:
- 打开一个到ECS的ssh连接，并以root身份登录。 在该窗口运行下列命令 tcpdump host 服务器的域名或地址 -w /var/tmp/1.cap
- 复现问题。
- 使用 ctrl + c 终止窗口1 的 tcpdump 命令。
- 下载 /var/tmp/1.cap 并压缩成zip格式上传到工单中。 请参考：help.aliyun.com/knowledge_d…
# 执行以下命令，抓取eth0网卡22端口的交互数据
tcpdump -s 0 -i eth0 port 22
# 抓取eth1网卡发送给22端口的交互数据，并在控制台输出详细交互信息
tcpdump -s 0 -i eth1 -vvv port 22
# 抓取eth1网卡发送至指定IP地址的PING交互数据，并输出详细交互数据
tcpdump -s 0 -i eth1 -vvv dst 223.xx.xx.5 and icmp
# 抓取系统内所有接口数据并保存到指定文件
tcpdump -i any -s 0 -w test.cap
总结
出问题是先用tcpdump打开两端抓包，再用mtr和tracetcp测试，再复现问题，最后用ctrl + c 终止窗口，把信息发给我们。
您好，通过您发来的包分析，目前是中间设备拦截导致的。
1、 问题复现的时候 ：IP_A访问IP_B的8080端口，出现rst的情况。
根据抓包看： 当IP_B收到这个rst报文，对方并没有始发该报文。
并且通过该rst报文的 ttl 和 ip序列号， 更证明了该报文不是阿里云发出的。 是中间公网运营商设备伪造发送的rst报文。
2、由于公网运营商网络，尤其您这个是跨境网络的情况下， 怀疑是运营商公网出口进行了rst报文的构造发送。
