(一) 新产品(看新款)生产服务器试点期间的一次运维疑难 问题说起
1-1. 前言背景
看新款服务是我司开发的一款面向ToB的鞋服行业客户开放的电子货单查询服务。该服务 采取了Java+微服务的架构方式开发。初步开发完毕后，产品开始进入客户试点前的运维部署 和迭代过程。某一日，当开发人员迭代了前端的功能代码，需要使用Jenkins推送进行自动化 部署的时候。碰⻅了一些问题:
-
(1)推送打包:前端程序是基于Vue开发的，发布的时候，也是基于一个node环境的基本的 nginx镜像，在Jenkins本地服务器上进行镜像打包的过程。由于之前使用的基础镜像的node 版本好像是16的，有点偏老。结果，在某一日打包前端程序的时候，某个用到的组件编译的 时候，提示依赖的版本过低需要升级。开发人员查了下，发现需要适当升级下node的环境版 本才行。就改变了基础镜像的node安装版本，改为了18。然后，接下来编译打包都顺利执行 了。
-
(2)故障突现:就当Jenkins打包推送镜像到私库这一段，都是正常的。然后Jenkins脚本， 开始执行ssh agent凭据免输入密码登录生产服务器，执行服务器上的部署更新脚本的时候， 突然卡住了。进度不在往前，这时开发人员查看，发现脚本执行停止容器/删除容器、删除原 有镜像，下载镜像都OK，可是，在构建新容器的时候，就卡住不动了。
-
(3)初步排除，定位故障:Jenkins的自动化任务最终超时失败后，运维人员第一时间想登录 主服务器去查看问题，突然发现SSH却无法登录，端口没有任何响应。进一步排查问题，才发 现生产服务器发布的服务的各个端口外网都无法访问了。究竟出啥问题了呢?难道服务器当 了?
短暂慌张后的应急诊断:
因为正值年前春节除夕临近，网络的小伙伴也在回家的路 上。公司值班的人员考虑片刻，采取通过生产环境下的另一台辅助服务器ssh登录的 方式，先进入生产环境的局域网里。然后在局域网里使用局域网地址，使用SSH尝试 登录主服务器。结果发现居然可以登录。登录进去后，发现各个服务都正常在跑。然 后，在生产环境的其他服务器上打开浏览器，使用局域网地址访问监控和各个系统的 登录界面，发现全部正常。现象呈现在面前，排查人员终于⻓舒一口气，原来是外网 不能访问，服务和服务器应该没啥大问题，还好还好。
那问题就比较简单直接了，现在的问题就是:出了什么问题了，造成外网无法访问应 用系统呢?
各位有经验的大佬看到这里，肯定不太感兴趣了。这个问题有啥难的，外网不能
访问，就那几种情况呗。你是不是心里也立刻列出了几种可能:
/* 外网不能访问服务器的原因可能是: */ 我这里突然想起chatGPT这个AI了，打开AI网站，立⻢把问题输入了进去。。。
不得不说，AI的思路还是挺正常的。可是当我按照这些思路拉上网络的小伙伴，断断 续续地查了一遍后，发现都是正常的。可外网还是无法访问主服务器，懵了~ ~。。。
1-2. 卡了2天的排查过程
我们部署的生产环境，硬件上有外网防火墙。软件上目前主要是单机服务器上多个docker-
compose的成组的部署各个微服务，前端程序也打包部署在nginx容器里。
首先，外网无法访问服务器，第一排查内外网的nat端口映射。硬件防火墙规则之前设置好 后，最近就没有动过。由于不放心，又让网络的小伙伴仔细看了一遍。然后，我把主服务器上 的centos自带的内网防火墙也关了，问题还是存在。
那是不是主服务器本身就上不了网呢?我随便ping了下百度、搜狐的，都是好好的。内部的 各个服务在局域网上也都正常。就是从外面访问服务器访问不了。
这。。。是不是服务器有什么异常，重启大法试试。重启完依旧;硬件防火墙的核心也是软
件系统，会不会防火墙抽⻛了?也重启下吧。重启完仍然不行。把规则删了重新添加，仍然问
题依旧。
还有啥招呢?我要不先把所有的容器服务都停掉。先看看SSH外网是否能访问?
systemctl stop docker.socket
systemctl stop docker
还是不行!
1-3. 抓包大法
也许有人会说:为啥不把外网防火墙关一下，看看和防火墙是不是有关系呢?这个真的做
不到，因为这个外网防火墙除了防护，主要的作用是接入管理网络访问的⻆色，关了服务器都
上不了网了。所以，无法这样定位问题。
在让网络小伙伴询问机房老相识的同时，我也想起好久没联系卖防火墙的老许。问题抛过 去人家也要消化下。等指点的同时也询问开发群里的万能群友。也一下子都没有特别好的排查 方法。我在网上搜索的时候，突然想起也许可以抓包分析下，外网进来访问服务的时候，究竟 底层发生了什么?
说起抓包工具，各种操作系统环境都有自己的抓包工具，小伙伴们可以看看，你用过哪
些?
由于服务器是linux的，所以首选Tcpdump命令了，我以前开发移动端app的时候，用过 Charles(在苹果系统下)，Fiddler也在windows下用过几次。tcpdump还是第一次用。这个 命令centos上没有预先安装，需要装一下:yum install tcpdump执行下就行。我特别还找了 个视频，快速看了下，链接也发上来分享给大家:
Tcpdump抓包工具实战教程，让你知道一个抓包走天下! www.bilibili.com/video/av342…
抓包命令，几个常用的参数要知道:-i 是指定网卡，网卡可以用ip a命令查，判断清楚要监听哪个网卡，我这里截了个图:
包的消息比较多，肯定需要过滤，可以用host ，协议用tcp等方式进一步过滤，条件还可以 and或者or，自己摸索。
经过一番操作，我终于发现外网访问服务器的时候，监听到的包的标志位全部都是[S]的标 志，[S]是啥意思，我们看看Tcp包的介绍就知道了，如图:
如图:监听到的包，标志[S]代表全部是要求建立Tcp连接的包，我们知道Tcp建立连接需要三 次握手，端口需要四次挥手。只有第一次，那Tcp连接肯定建立不起来啊。所以问题就是出 在:为啥后面类型的包没有产生呢?
我并且在监听的同时，使用内网模拟访问，观察收到的包的情况，如图:
可⻅内网收到的包，Tcp是建立了起来，正常发送着数据的。
1-4. 抓包发现的端倪给了排查方向
有了方向，接下来的事情就比较好办了。用了几条命令查询了一下，如图:
这里192.168.100.1是外网防火墙的内网地址。我突然发现主服务器到内网防火墙是不通的。 然后我又用了traceroute 192.168.100.1去测试路由跳转的情况，结果发现也找不到外网防火 墙。问题的原因终于开始显现了。相当于进来的Tcp包生成回去的包的时候，传递不到外网防 火墙上，自然就转发不到外网的访问者了啊。
那为啥主服务器会找不到外网防火墙呢?我查询centos的路由表发现了原因:
原因就是这条路由造成的，由于多了这条路由，本来到外网防火墙的路由走默认的网关交换机 172.16.0.254就能出去。结果却被路由到了255.255.96.1上去了。这当然就转不出来了啊。想 到这，我先不管这条路由哪里来的，先手动加上一条指向更明确的路由上去。如图:
果然，药到病除。路由可以出去了，外网立⻢就可以访问。解决了!!
1-5. 路由异常的原因
问题虽然解决了，可总要探讨下这条路由是怎么来的?在拿着查出结果的截图再次请教运维群 里的大佬。大佬显然感兴趣了起来，他帮我分析了一通，还顺便教我了几条命令，我们发现应 该是在前端容器推送的时候，不知道什么原因，docker-compose自动创建的网桥使用的ip和 自动添加的路由的网段没有顺延172这样的网段，而是一下子变成了192.168.96的网段去了。 所以，就出现了这条路由影响了所以服务都出不去的尴尬境地。
我这里也截图记录了下，探讨的过程:
我尝试把前端的容器删除掉(docker-compose down)，然后重新拉起来，发现没再出现96的路 由，一切正常了。
查了下历史，也没看出什么原因，96网段的路由就像一个⻛一样的男子，悄悄的来，又悄悄 的走了。可却把我们搞得一地鸡毛!好在一切又回归正常了。
(二) 总结
这次网络排查的经验，真是对网络水平的一次提升，隐隐感觉功力涨了一成。所
以，我特意抽了一下午的时间复盘回顾了一下整个的排查过程，写下了这篇文章。主
要是两个目的:
(1)方便自己日后备查
(2)希望能帮助其他人，能提供一些服务器运维异常的排查思路。我们可以负责任 的说，抓包是一个非常有效的排查手段。用好了，可以快速诊断问题。当然，话说回 来，计算机是一⻔实践的科学，网络更是实践的典型。有时候经验还是非常重要的， 所以我坚决反对35岁不中用的错误论调。当然，如果能学点白帽黑客的手段，肯定能更有解决问题的手段了啊。
在此，感谢万能的群友，运维开发的好朋友们。帮我成⻓。谢谢你们，谢谢 CCTV!
同样，感谢您能坚持到最后，看完本篇文章，如果觉得对你有用，请不吝点赞转
发。谢谢。
我的邮箱:9200118@qq.com 大家也可以交个朋友。
(2023-01-31 菲哥在银湖科技园 亲测总结)
