05 | 定位防火墙（一）：传输层的对比分析
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了通过结合传输层和应用层的分析推理来定位防火墙的方法。通过详细案例介绍了处理网络问题时的具体操作步骤，强调了双向抓包的重要性，并提出了在抓包过程中需要注意的关键点。作者介绍了在分析抓包文件时的具体步骤，包括查看Expert Information、重点关注乱序报文等。通过这些步骤，读者可以了解到在处理类似网络问题时，如何通过抓包和分析来定位问题，并且可以学习到一些实用的技术方法。文章内容详实，适合网络运维人员和对网络故障定位感兴趣的读者阅读学习。文章还介绍了通过TCP序列号来定位对应TCP流的技巧，以及在分析过程中发现的乱序报文问题，并最终发现问题出现在防火墙上。文章还提到了隧道引发的乱序问题以及对HTTPS事务的影响。整体内容涵盖了网络故障排查的实际操作和技术细节，对读者具有一定的启发意义。文章中还提到了在两个不同的抓包文件中如何定位到同个报文的方法，也就是使用裸序列号。在一侧的文件中找到某个报文的裸序列号，作为搜索条件，在另外一侧的报文中搜索得到同样这个报文。这正是利用了TCP裸序列号在网络中传输的一致性（不变性）。后面的课程中，作者还将介绍更多这种“寻找同样报文”的方法，基本思想也都是基于某些信息在网络传输的一致性。
《网络排查案例课》，新⼈⾸单¥59
全部留言(16)
- 最新
- 精选
那时刻要定位两侧的同个报文，还可以依据消息内容，frame contains进行过滤作者回复: 很棒！ 这个方式也很好，通过搜索特定消息内容（比如某个http事务的唯一uuid）的方式，找到两边抓包文件里同一个报文。这个消息越确定越唯一，匹配的范围就越小越精确。 在二层就是用frame contains 在三层就是用ip contains 在四层就是tcp contains 在七层就可能是http contains
2022-01-21323
江山如画首先根据时间戳大致确认报文范围，再从不同层入手。 数据链路层，使用 mac 地址区分。 网络层，使用源IP，目的IP，IPv4/IPv6版本。 传输层，使用源端口，目的端口，协议类型，裸序列号，裸确认号，校验和。 会话层和表示层，比如 TLS，可以先用 Content Type 字段区分报文类型，比如是握手报文还是数据传输的报文。如果是握手阶段的报文，可以用 sessionID 区分，如果是正式的数据传输报文，可以用 Encrypted Application Data 区分。 应用层，使用 URL 区分，数据没有加密使用内容区分。作者回复: 差不多，很全面了，给你点赞！ 你也可以参考另外一个同学的回答，就是在数据链路层，用frame contains "xxx"这个wireshark过滤器，在两个文件中找到同样的报文。当然前提是这个"xxx"应该足够唯一，否则是多个的话，得结合其他信息（比如ip，端口号，序列号等等）来综合判断。 一般来说，我个人用的比较多的就是两种： 1. 用裸序列号（也叫原始序列号） 2. 用应用载荷数据，比如frame contains, ip contains, tcp contains, http contains都可以
2022-01-21315
志强但从经验上看，乱序几率大概在百分之一以下到千分之一左右都属正常 ----请问老师 问题中的乱序是多少呢？ 这个百分比是谁除以谁得到的呢？作者回复: 就是指乱序报文的数量。比如有一个抓包文件里有1万个报文，其中10个是乱序报文（wireshark会提示的，在专家信息里可以看到），那么就是千分之一，是支持范围内，或者说不会明显影响到传输。 你可以这样得到百分比： 1. 计算全部报文数量：capinfos file.pcap | grep packets 2. 计算乱序报文数量：tshark -n -q -r file.pcap -z "io,stat,0,tcp.analysis.out_of_order" 3. 两者相除，或者肉眼也能看出来比例大概在什么数量级了
2022-01-2125
怀朔如果可以 希望老板把cap包发一下 大家一起分析看看作者回复: 嗯这个在计划中的，后续陆续对抓包文件做数据脱敏，然后整理出来，放到gitee上方便大家的学习
2022-01-2523- 我为什么这么菜老师，根据上面的乱序报文，它对应的 ACK 是否是这样的： 1. 客户端收到 [包4]，回复 ACK5 2. 客户端收到 [包1]，回复 ACK2 3. 客户端收到 [包2]，回复 ACK3 4. 客户端收到 [包3]，回复 ACK4 因为这几次 ACK 的值都不一样，所以不会引起快速重传。 但如果是下面这种乱序，应该就会引发快速重传吧？ 1. 客户端收到 [包1]，回复 ACK2 2. 客户端收到 [包3]，回复 ACK2 3. 客户端收到 [包4]，回复 ACK2 这时候服务端连续收到 3 个 ACK2，就会引发快速重传吧？
作者回复: 一方收到3个DupAck会启动快速重传，注意是3个DupAck，而加上原始Ack就是4个同确认号的Ack了，比你这里说的多一个：）
2022-05-092 
星星云服务端经过了haproxy和nginx，还能这样抓包吗作者回复: 经过了LB（包括这里的haproxy和nginx），那么LB前后的TCP连接是没有关系的，在TCP层面的信息毫无联系，所以就不能按这节课里的方法（对比两侧的抓包文件）来对比客户端抓包和服务端（在LB后面）抓包。不过我们还是可以在以下两种抓包场景里做比较： 1. 比较客户端抓包和LB抓包（LB的客户侧） 2. 比较LB抓包（LB的服务侧）和服务端抓包 但是因为1和2是不同的TCP连接，无法从TCP元数据（IP，port，序列号等等）上找到关联关系。不过，可以在应用层数据上找到这种关系。比如客户侧的某个请求有个特定的uuid，那么LB转发到服务侧后，这个uuid还是保留的，就可以通过它来找到两侧TCP的关系。 这个话题很大，在后续课程里会陆续提到的~
2022-05-0722
includestdio.h老师留的思考题没啥头绪，我就大概按照我的理解总结下本篇的知识点吧 - - 排查原则： “两端抓包”，听完“A”的抱怨，也该问问“B”的解释，这样才公平 注意事项： 1.各端的抓包过滤条件一般以对端 IP 作为条件 2.两端的抓包应该差不多在同时开始和结束 3.边重现，边抓包（确保问题出现，再停止抓包） 排查步骤： 1.查看 expert information； 2.重点关注可疑报文（比如 Warining 级别），追踪其整个 TCP 流【TCP流追踪方法：Follow -> TCP Stream】； 3.深入分析这个可疑 TCP 流的第二到四层的报文，再结合应用层表象，综合分析其根因； 4.结合两侧的抓包文件，找到属于同一个 TCP 流的数据包，对比分析，得出结论【通过TCP裸序号，找到对端同个TCP流】； 另外有个小建议，老师后续能不能在下篇专栏内容开头公布下思考题答案作者回复: 你的总结太好了，学习委员就是你了：） 这个排查分析的思路虽然不包含具体的操作，但对我的排查工作的开展非常有指导意义，希望对你也有帮助
2022-01-212
bingo请问老师，客户端和服务端同一个包显示的时间不一样，这是什么原因呢？作者回复: 你好，你具体指的是客户端或者服务端的哪个报文，或者是对哪个图有困惑呢？
2022-03-052
晴天了在 客户端a 和 服务器端b分别用tcpdump抓包. 然后用wireshark 展开分析 . 发现a 第一次握手发送的序号是 3758130604 , 而在b抓到包内容展示的第一次握手的序号是1594004265, 问下老师是什么问题?作者回复: 比较奇怪，一般发生序列号改变的话，是经过了LB的，你是这种场景吗
2022-02-253
追风筝的人在两个不同的抓包文件中如何定位到同个报文的方法，也就是使用裸序列号SN。作者回复: 恩，如果我们在通信两端都做了抓包，那么同一个报文就会在两个文件中都出现（假设没有丢包），通过这种方法，找到同一个tcp流
2022-02-21
