06 | 定位防火墙（二）：网络层的精确打击
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了利用TTL值定位网络层问题的方法，以解决防火墙引发的连接问题。作者首先指出包乱序可能由多种因素引起，而非仅仅是防火墙的问题。随后，作者详细介绍了利用抓包分析和TTL来定位问题的方法，并通过案例分析展示了如何利用TTL值反映网络路径跳数以及内网连接中TTL值的稳定性。文章还提到了借助Wireshark的自定义列来更有效地分析TTL值的方法。最后，通过一个案例，作者展示了如何利用TTL值定位防火墙引发的问题，并修正防火墙策略解决了连接问题。文章还介绍了如何通过iptables规则来丢弃有害的RST报文，以及如何模拟防火墙行为进行实践。整体而言，本文为读者提供了全面的网络层问题排查和解决方法，对于网络技术人员具有重要的参考价值。文章内容技术性强，适合对网络层问题感兴趣的读者阅读。
《网络排查案例课》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
includestdio.h老师我这里有个小问题，既然是被防火墙RST了，为啥客户端抓包看到的SRC IP不是防火墙IP，而仍然是服务端IP，能理解为什么要这样做，但是不太了解这是怎么实现的，有啥说法吗作者回复: 那你要回头复习一下预习篇的网络分层了，这个还是TCP流的关系，五元组是跟连接一一对应的。如果防火墙用自己IP作为SRC IP，那么这个RST报文就被视为独立的一个报文而被丢弃，或者也被RST，但不影响防火墙意图要干扰的那个连接。
2022-01-2413
webminMAC地址中的组织唯一标识符 （OUI）由，IEEE（电气和电子工程师协会）分配给厂商，那么通过MAC地址可以辨别出厂商，防火墙的主要厂商也不多，从这块信息大约能判断出回包的是不是防火墙，因为是通过二层信息判断，所以这个方法是有局限性的。作者回复: 在这个小范围内确实也是一个可行的办法~
2022-01-2436- ThinkerWalker思考题：traceroute查看数据包经过的路径？
作者回复: traceroute是可以看到路径上所有的三层设备的，这里强调“三层”，是因为只有工作在IP层的路由性质的设备（包括三层交换机）才会回复ICMP消息。如果是纯二层设备，不会回复ICMP消息，也就在traceroute输出里看不到它。 防火墙也经常出现在traceroute输出里，不过一般它的ip也不特殊，名称上（如果有反向解析记录的话）也未必说自己是防火墙。当然，事实上很多时候防火墙是没有反向解析记录的，也就是traceroute不加-n，那么别的节点可能显示为名称，但防火墙只是显示为ip，虽然准确率不太高，不过倒是可以用来参考：） 用TTL来判断是非常准的，几乎不会“失手”。但是题目不能用TTL了，那么IP层还有什么可以借用的吗？比如IP ID，因为ID号是通信两端自己各自生成的连续号码，防火墙插入报文的话，一般来说IP ID就不同了。你如果也有被防火墙干扰的抓包文件，可以观察IP ID在RST报文里跟其他正常报文是否不同：）
2022-01-3035 
WalkRun老师 弱弱的问一句 如果想让vm1访问百度通过vm2那么把vm1的网关设置成vm2的IP不就可以了吗？作者回复: 是的，但是这有前提条件，也就是vm1和vm2必须在同一个广播域。如果是跨越了广播域（也就是仅仅三层可达，而不是二层可达），那么就无法设置对方为自己的网关。 通过隧道技术，无论是否在同一个广播域，你都可以把隧道IP作为网关，通用性更好一些：）
2022-05-1724
潘政宇老师，有2个问题请教一下： 1. iptables作用点是在tcp IP协议栈之前吗？ 2. iptables drop后的包，tcpdump还能抓到吗作者回复: 关于第一个问题，这要具体看在iptables的哪条链上： 1. 如果是在进来的PREROUTING和INPUT链上，那么iptables规则先生效，然后报文进入内核TCP/IP协议栈 2. 如果是在出去的OUTPUT或POSTROUTING链上，那么报文是先在内核处理后才到这两条链上的，所以这两条链上的iptables是后生效的 3. 如果是在转发链FORWARD上的规则，报文不进入本地处理 关于第二个问题： iptables drop的报文，tcpdump还是可以抓取到的，课程里面的试验3，就是这样的例子~
2022-02-0334
那时刻我在Mac里通过docker 模拟两台虚机动手实践rst消息的例子，但是遇到问题 1. 在docker container里 执行 `nc -v www.baidu.com 443` 得到错误 `nc: getaddrinfo: Try again` 2. 如果在docker container里执行 nc -v 180.101.49.12 443 ，同时在另外一个docker里执行 tcpdump抓包， ``` 03:55:04.573358 IP 100.64.0.1.41036 > 180.101.49.12.443: Flags [S], seq 1595471296, win 64620, options [mss 1436,sackOK,TS val 1040158415 ecr 0,nop,wscale 7], length 0 03:55:04.573392 IP 100.64.0.2.41036 > 180.101.49.12.443: Flags [S], seq 1595471296, win 64620, options [mss 1436,sackOK,TS val 1040158415 ecr 0,nop,wscale 7], length 0 03:55:04.573455 IP 100.64.0.1 > 100.64.0.2: ICMP redirect 180.101.49.12 to host 180.101.49.12, length 68 03:55:04.573466 IP 100.64.0.2.41036 > 180.101.49.12.443: Flags [S], seq 1595471296, win 64620, options [mss 1436,sackOK,TS val 1040158415 ecr 0,nop,wscale 7], length 0 03:55:05.571442 IP 100.64.0.1.41036 > 180.101.49.12.443: Flags [S], seq 1595471296, win 64620, options [mss 1436,sackOK,TS val 1040159448 ecr 0,nop,wscale 7], length 0 03:55:05.571486 IP 100.64.0.2.41036 > 180.101.49.12.443: Flags [S], seq 1595471296, win 64620, options [mss 1436,sackOK,TS val 1040159448 ecr 0,nop,wscale 7], length 0 ``` 只有sync 包，即使加上 nat 也是如此。 具体的信息，请参见 https://gist.github.com/richzw/2948a9bc2de8dca1811b69c42796a576。麻烦老师抽空帮忙看看作者回复: 嗯，我看了你的github的内容，里面有点小问题： 1. 容器1设置route的时候，指定的网关ip应该是容器2的tunnel ip，而不是容器1自己的tunnel ip。所以这条命令： # ip route add 180.101.49.0/24 via 100.64.0.1 dev tun0 应该改成： # ip route add 180.101.49.0/24 via 100.64.0.2 dev tun0 2. 容器2不要添加route 改完这两个地方就可以通了：）
2022-03-093
JianXu我司现在碰到的问题是，当源到目的不通或者间歇性不通的情况下，源端应用的负责人就会找到基础架构问为什么。而我们现在并没有一个很好的办法可以得到答案。然后就变成应用，基础架构和数据中心物理网络把自己的三板斧当成免责，公司的应急反应中心最后就把所有人拉在一起。到了分布式后这个问题越来越严重 查起来也越来越繁琐了。现在有一种趋势就是应用，分布式防火墙，软件负载均衡都说要把日志送到监控部门手上，然后监控部门和网站可用性的副总说有谁对怎么用这些数据负责任吗？我给领导汇报说我觉得流量运维部门是定位这类问题的希望。作者回复: 嗯这是一个很大的话题，对于不同规模的公司： 1. 中小公司，直接做网络层分析（mtr等）和抓包分析（tcp行为），应该能解决大部分问题 2. 大型公司，需要先从错综复杂的环境里的各个环节里收集数据，第一步需要把问题初步定位到某几个子环节，然后再运用上面说的方法。另外一种思路是干脆不做抓包分析（或者尽量少依赖抓包分析），尽量用tracing的方式，这里又包括两种tracing： a. 网络中每一跳的tracing b. 主机/pod上的网卡到内核函数路径上的tracing 任重而道远：）
2022-03-192
江山如画拓展思考，丢弃有害 RST 的办法: 方法1: 如果防火墙策略是基于 ipv4 的，并且服务器支持 ipv6 访问，可以使用 ipv6 地址绕过防火墙策略 方法2: 如果防火墙策略是通过源地址限制访问，可以通过自己搭建一台跳板机，先访问跳板机，通过跳板机再访问防火墙 思考题，识别防火墙的方法： 方法1: 我想在通信报文里设置一些特殊的标记来标识双方，只要是客户端和服务端通信都需要设置这个标记，如果是防火墙代发则没有这个标记。在 tcp flags 中有保留位可以用于设置，或者是在 tcp payload 中设置一些用于标记的字符串。作者回复: 你的3个回答都挺棒的，给你点👍 方法2是指SSH tunnel吧，这个方法也可以，不过要注意跳板机一般也会被安全部门管理，不过这个确实也技术上可以绕过防火墙了。另外，客户端也需要做一些额外配置。 关于设置特殊标记的方法，我觉得也很开“脑洞”：） 因为是保留位，也就是目前没有被标准定下来如何使用，那么可能还是需要对linux内核进行定制，并配合用户空间程序，然后让这种“识别”启用起来，然后就可以鉴别出防火墙了~
2022-01-2422
N0mansky这种绕过还是只能针对单向rst吧，如果双向rst就没法绕过了作者回复: 是的，双向的话，除非可以在靠两端的位置都各有一个这种的装置来丢弃RST报文，否则只要有一端收到RST，依然要断开的~
2022-11-15归属地：上海1
霍格沃兹小学徒ip addr add 100.64.0.2 peer 100.64.0.1 dev tun0 想知道这条命令里面的 ip地址是怎么确定的作者回复: 只是这个网段常用来给隧道用而已：）
2022-04-1221
