作者回复: 那你要回头复习一下预习篇的网络分层了,这个还是TCP流的关系,五元组是跟连接一一对应的。如果防火墙用自己IP作为SRC IP,那么这个RST报文就被视为独立的一个报文而被丢弃,或者也被RST,但不影响防火墙意图要干扰的那个连接。
作者回复: 在这个小范围内确实也是一个可行的办法~
作者回复: traceroute是可以看到路径上所有的三层设备的,这里强调“三层”,是因为只有工作在IP层的路由性质的设备(包括三层交换机)才会回复ICMP消息。如果是纯二层设备,不会回复ICMP消息,也就在traceroute输出里看不到它。 防火墙也经常出现在traceroute输出里,不过一般它的ip也不特殊,名称上(如果有反向解析记录的话)也未必说自己是防火墙。当然,事实上很多时候防火墙是没有反向解析记录的,也就是traceroute不加-n,那么别的节点可能显示为名称,但防火墙只是显示为ip,虽然准确率不太高,不过倒是可以用来参考:) 用TTL来判断是非常准的,几乎不会“失手”。但是题目不能用TTL了,那么IP层还有什么可以借用的吗?比如IP ID,因为ID号是通信两端自己各自生成的连续号码,防火墙插入报文的话,一般来说IP ID就不同了。你如果也有被防火墙干扰的抓包文件,可以观察IP ID在RST报文里跟其他正常报文是否不同:)
作者回复: 关于第一个问题,这要具体看在iptables的哪条链上: 1. 如果是在进来的PREROUTING和INPUT链上,那么iptables规则先生效,然后报文进入内核TCP/IP协议栈 2. 如果是在出去的OUTPUT或POSTROUTING链上,那么报文是先在内核处理后才到这两条链上的,所以这两条链上的iptables是后生效的 3. 如果是在转发链FORWARD上的规则,报文不进入本地处理 关于第二个问题: iptables drop的报文,tcpdump还是可以抓取到的,课程里面的试验3,就是这样的例子~
作者回复: 嗯,我看了你的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 改完这两个地方就可以通了:)
作者回复: 是的,但是这有前提条件,也就是vm1和vm2必须在同一个广播域。如果是跨越了广播域(也就是仅仅三层可达,而不是二层可达),那么就无法设置对方为自己的网关。 通过隧道技术,无论是否在同一个广播域,你都可以把隧道IP作为网关,通用性更好一些:)
作者回复: 嗯这是一个很大的话题,对于不同规模的公司: 1. 中小公司,直接做网络层分析(mtr等)和抓包分析(tcp行为),应该能解决大部分问题 2. 大型公司,需要先从错综复杂的环境里的各个环节里收集数据,第一步需要把问题初步定位到某几个子环节,然后再运用上面说的方法。另外一种思路是干脆不做抓包分析(或者尽量少依赖抓包分析),尽量用tracing的方式,这里又包括两种tracing: a. 网络中每一跳的tracing b. 主机/pod上的网卡到内核函数路径上的tracing 任重而道远:)
作者回复: 你的3个回答都挺棒的,给你点👍 方法2是指SSH tunnel吧,这个方法也可以,不过要注意跳板机一般也会被安全部门管理,不过这个确实也技术上可以绕过防火墙了。另外,客户端也需要做一些额外配置。 关于设置特殊标记的方法,我觉得也很开“脑洞”:) 因为是保留位,也就是目前没有被标准定下来如何使用,那么可能还是需要对linux内核进行定制,并配合用户空间程序,然后让这种“识别”启用起来,然后就可以鉴别出防火墙了~
作者回复: 是的,双向的话,除非可以在靠两端的位置都各有一个这种的装置来丢弃RST报文,否则只要有一端收到RST,依然要断开的~
作者回复: 只是这个网段常用来给隧道用而已:)