网络不通排查之路

背景描述

和业务方对接，发现网络不通

1. 问题发现

ping丢包
通过ping域名，网络基本丢包

image.png

2. 问题定位

2.1 源目的IP

查IP(www.cip.cc)网站, 提供免费的IP查询服务,命令行查询IP, 并且支持'PC网站, 手机网站, 命令行(Windows/UNIX/Linux)' 三大平台, 是个多平台的IP查询网站
通过 curl cip.cc 拿到出口IP

curl cip.cc 可以拿到本机的出口IP
IP  : 203.119.241.118
地址  : 中国  北京
运营商  : 阿里云/电信/联通/移动/铁通/教育网

2.2 分析路由追踪

启动 mtr 时，它将调查运行 mtr 的主机与指定的目标主机之间的网络连接。确定机器之间每个网络跃点的地址后，它将向每个发送 ICMP ECHO 请求序列，以确定到每个机器的链路质量。这样，它将打印有关每台计算机的运行统计信息。
mtr -r 33.7.74.68
发现最后一跳"211.138.131.2"(中国移动) 把请求拒绝掉了

mtr -r  33.7.74.68
HOST: ai-user-center033007074068. Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- 11.57.50.193               0.0%    10    1.4   1.4   1.2   1.7   0.0
  3.|-- 11.57.48.234              10.0%    10    2.8   4.3   2.5   9.6   2.5
  4.|-- 11.54.242.5                0.0%    10    1.5   1.9   1.4   5.5   1.2
  5.|-- 10.102.255.209             0.0%    10    1.5   2.2   1.0  11.3   3.1
  6.|-- 117.49.50.142              0.0%    10    6.1   6.3   6.0   6.8   0.0
  7.|-- 10.102.34.233              0.0%    10    5.7   5.8   5.7   6.0   0.0
  8.|-- 111.13.124.38             10.0%    10    8.0   8.3   8.0   9.7   0.4
  9.|-- 218.206.88.26              0.0%    10    8.9   9.1   8.7  10.5   0.3
 10.|-- 221.183.53.177             0.0%    10    9.9   9.9   9.7  10.0   0.0
 11.|-- 221.183.37.162             0.0%    10   31.7  32.0  31.5  34.7   0.8
 12.|-- 221.183.47.166             0.0%    10   30.5  30.5  30.2  30.7   0.0
 13.|-- 211.138.131.2              0.0%    10   33.3  33.3  33.2  33.5   0.0
 14.|-- ???

也可以用traceRoute进行路由跟踪

traceroute to wap.cmread.com (211.140.17.81), 30 hops max, 60 byte packets
 1  * * *
 2  11.57.49.193 (11.57.49.193)  1.704 ms 11.57.49.149 (11.57.49.149)  1.400 ms 11.57.50.89 (11.57.50.89)  1.391 ms
 3  11.57.48.114 (11.57.48.114)  1.383 ms * 11.57.49.26 (11.57.49.26)  1.458 ms
 4  11.93.196.198 (11.93.196.198)  1.557 ms 11.54.242.133 (11.54.242.133)  1.544 ms 11.54.242.141 (11.54.242.141)  1.596 ms
 5  10.102.255.237 (10.102.255.237)  1.927 ms 10.102.255.181 (10.102.255.181)  1.126 ms 10.54.219.230 (10.54.219.230)  1.476 ms
 6  10.54.220.221 (10.54.220.221)  6.214 ms 116.251.127.190 (116.251.127.190)  6.522 ms 117.49.50.146 (117.49.50.146)  6.442 ms
 7  103.41.141.177 (103.41.141.177)  6.296 ms 116.251.112.185 (116.251.112.185)  5.447 ms 123.56.34.5 (123.56.34.5)  5.653 ms
 8  * 39.156.9.246 (39.156.9.246)  6.298 ms 39.156.7.170 (39.156.7.170)  6.839 ms
 9  39.156.0.38 (39.156.0.38)  13.199 ms 218.206.88.22 (218.206.88.22)  9.707 ms 218.206.88.26 (218.206.88.26)  9.231 ms
10  221.183.49.129 (221.183.49.129)  8.097 ms 221.183.49.141 (221.183.49.141)  10.031 ms 221.183.53.177 (221.183.53.177)  10.595 ms
11  221.183.37.162 (221.183.37.162)  31.080 ms 221.183.37.246 (221.183.37.246)  33.221 ms  41.869 ms
12  221.183.47.174 (221.183.47.174)  32.533 ms *  37.649 ms
13  218.205.59.30 (218.205.59.30)  32.961 ms 218.205.50.58 (218.205.50.58)  33.007 ms 218.205.59.18 (218.205.59.18)  35.300 ms
14  * * *
15  * * *
16  * * *
17  * * *

2.3 运营商追踪

提工单给移动运营商之后，又过去了几天。
工程师反馈结果是业务方的问题 （坑爹，业务方一口咬定不是自己的问题）

您好！工程师反馈处理结果为：经排查，从源地址张北阿里203.119.241.102
到浙江省公司CMNET可见范围内的MX960设备访问一切正常，
MX960设备后面接的为xxxx的业务设备，推测故障点位于xxxx，目前已邮件通知xxxx。

2.4 业务方接锅

业务也无法反驳，拉网络运维团队确认后，是因为防火墙配置了拦截规则。兜了这么一大圈，最后还是要"少侠自己接锅"。
你以为这就结束了吗？ too young

2.5 固定出口IP

1. 业务方配置了防火墙，那就把网段加上吧，所以我们提供了我们出口IP的网段。但是业务方防火墙不能配置特别大的网段(配置网段太大了，那就相当于没有防火墙了，此方法不通)
2. 业务方可以配置固定IP，把我们的服务器的IP都枚举配置进去。这就难为我们了呀，我们是云端的服务器，IP是随机分配的。另外 遇到扩容、缩容是那IP是不断变化的。这方式无疑后面是无法长期维护的，成本太高
3. 经过和运维同学沟通，可以固定应用的出口ip，但是有繁琐的审批流程，最后也作罢
4. 业务方关闭防火墙，对接口进行加密等方式保证安全。但是防火墙的预防DDOS攻击等能力也就失效了

总结

1. 网络问题不好排查，但是也能相信业务方一定是无辜的，保持怀疑
2. 网络分析工具要灵活使用，定位到具体的问题点。其实很早就可以怀疑是对端网络的问题

!!! 如有理解不正确，欢迎指正交流