大家好，我是TT。
在前面《传输层和应用层的对比分析》中，我用两侧抓包并对比分析的方法，首先定位到了引发长耗时的数据包，然后对比两侧抓包文件，定位到了包乱序的现象及其原因。最后，我们综合这些有利证据，跟安全部门沟通后，拿到了真正的根因，并彻底解决了问题。
在那个案例中，大量的分析技术是位于传输层，而且要结合应用层（超时的问题）做综合分析。总的来说，难度还是不小的。而且还有一个不可回避的问题：包乱序难道只有防火墙才会引发吗？
其实不是的。包乱序是一种相对来说比较普遍的现象，除了防火墙，还有网络设备、主机本身都可能引起乱序。所以，单纯根据包乱序就断定是防火墙在中间捣鬼，就有点以偏概全了。
那么有没有一种方法，不需要借助那么多的传输层的复杂知识，就可以让我们更加明确地判断出，问题是在防火墙呢？
这篇文章里，我就给你介绍这种方法，即聚焦在网络层的精确打击。这是一种更加直接、更加高效的办法。
你可能又会疑惑了：难道说我们上节课学的东西，其实是多余的吗？那倒不是。这两节讲防火墙的课程，各自有不同的侧重点和不同的适用场景。这次我们介绍的方法，在上节课的案例里就不会起到作用；反过来也是如此。技术上没有“一招鲜”，只是这次课讲的内容相对上节课来说，确实更加直接，这也是它的一大特点。
好了，废话不多说，咱们来看案例吧。
案例1：Wb站点访问被rst
几年前我在公有云公司就职，当时公司乔迁入住了新的办公大楼，没过半天，不少同事陆续报告，他们无法访问某个内部Wb工具。而且报告的人都有个共同点：他们使用的是二楼的有线网络。
我们这个内部工具是以Wb网站形式运行的，报错页面就是类似下面这种（不同浏览器会有不同的错误页面）：
我们让二楼同事连接到有线网络并做了抓包，然后传给我们做分析。因为抓包的同事没有做过滤，所以抓上来的包比较大，包含了各种其他无关的数据包。不过没关系，我们可以按下面的顺序来。
第一步：过滤IP
在这个案例里面，我们就可以把Wb站点的IP作为过滤条件。Wb站点的IP是25.61.29.10，所以我们的过滤器就是：
ip.addr==25.61.29.10
补充：因为信息安全的原因，这里的报文信息我做过脱敏了（也就是修改或者删除了敏感信息），所以IP和载荷等都已经不是原始信息了。
我们得到下面的过滤结果：
第二步：选中可能有问题的数据包，然后过滤出整个TCP流
从上图中已经能看到RST报文了。当然，在前面文章里，我说了如何在Wirshark里面，用过滤器来找到TCPRST报文。那么这个案例里面，我们同样可以这么做。在过滤输入框里输入：
ip.addrq25.61.29.10andtcp.flags.rstq1
我们觉得某个RST包比较可疑，那么还是用Follow-TCPStram的方法，找到对应的TCP流：
第三步：在过滤出来的TCP流中进一步分析
在我们点击TCPStram的时候，Wirshark会弹出一个窗口，显示解读好的应用层信息。如果是HTTP明文（非HTTPS加密），那就可以直接看到里面的内容了。
回到主窗口，此时过滤生效，所以只有属于这个TCP流的包才被显示，其他无关的数据包都已经被隐藏了。
可见，TCP三次握手后，客户端发起了一个HTTP请求，即GET/ovrviwHTTP/1.1，但服务端回复的是TCPRST，怪不得访问失败了。我画了下面这张示意图供你参考：
握手能成功，看起来网络连通性没有问题，然后发送HTTP请求后收到RST，感觉服务端的嫌疑很大。
我们找到了负责服务端的同事，不过，他们说完全没有做RST这种设置，而且反问：“不是说Wi-Fi就都正常吗？二楼以外的其他楼层也都可以，不是可以排除服务端原因了吗？”
客户端没问题，服务端也没问题，是不是就要怀疑是防火墙了？但还是那个困境：我们并没有防护墙的权限，无法证实这件事。
那我们还是回到网络本身来查看，静下心来思考一下。
其实，虽然抓包分析是一个很好的排错方法，但是一般在中间设备（交换机、防火墙等）上不方便抓包，所以主要途径还是在客户端或者服务端的抓包文件里寻找端倪。当然，我们也可以争取条件到服务器上抓个包，然后再结合两侧抓包文件，进行对比分析，会更容易得出结论，这也是上节课我介绍过的方法。
不过，有没有办法只根据客户端的抓包，就能确定这次问题的根因呢？这个比较悬。但是，对于当前这种场景，如果能掌握到一个关键信息，我们就可以直接得出结论。
它就是TTL（TimToLiv）。你可能会觉得，这个知识点简直太简单了，真的能解决我们的问题吗？且听我慢慢说。
TTL详解
TTL是IP包（网络层）的一个属性，字面上就差不多是生命长度的意思，每一个三层设备都会把路过的IP包的TTL值减去1。而IP包的归宿，无非以下几种：
网络包最终达到目的地；
进入路由黑洞并被丢弃；
因为网络设备问题被中途丢弃；
持续被路由转发并TTL减1，直到TTL为0而被丢弃。
在RFC中规定了TTL值为8位，所以取值范围是0~。
因为TTL是从出发后就开始递减的，那么必然，网络上我们能抓到的包，它的当前TTL一定比出发时的值要小。而且，我们可能也早就知道，TTL从初始值到当前值的差值，就是经过的三层设备的数量。
不同的操作系统其初始TTL值不同，一般来说Windows是，Linux是64。由此，我们就可以做一些快速的判断了。比如我自己测试ping