本帖最后由 恭喜你遇到了一个超级可爱的女友 于 2021-3-12 20:39 编辑
一.问题背景 客户使用了我司的防火墙对接某亮平台和某视频采集系统,防火墙以路由模式部署,主要做了源和目的NAT,然后他们的某视频采集系统把视频推送到某亮平台的时候发现没有推送成功,于是找到我司的人员帮忙排查是否存在我司的问题。 二.拓扑图(简化图) 说明:监控平台地址为193.169.10.6,从eth6口进通过我司防火墙eth2口出去做了源NAT,源地址变成10.23.206.50访问10.23.235.27 三.排查 1.刚开始排查看了防火墙的应用控制策略为全放通(内网),则数据不通和应用控制策略没有关系,为了防止其他情况出现,依旧做了直通测试,数据没有通,然后就和看了一下地址转换策略,源NAT配置的也没有问题。 2.然后此时在eth6抓包发现数据已经发给某视频采集系统了,但是没有回包 3.于是怀疑是其他设备出现了问题,在某视频采集系统那边抓包发现那边收到了数据并且发送了回包,但是平台这边没有收集到数据包,刚开始怀疑没有回报路由,导致数据回不来。但是仔细观察了一下数据包发现平台发给视频采集系统的源地址没有进行转换,源依旧是193.169.10.6,也就是我们的源NAT没有生效 4.回过头看我们的源地址策略发现没有任何问题,于是去知识库收集了一下案例,发现防火墙上的机制导致了这种问题的出现,“连接跟踪”会导致源NAT不生效,在会话排行里面也能查看 5.在防火墙把源地址193.169.10.6加入黑名单几分钟然后再拉回来,抓包测试,发现数据恢复正常,业务建立成功,视频也推送过来 抓包: 解释一下什么是连接跟踪: 1.报文过滤和连接跟踪可以说是Netfilter提供的两大基本功能。前者被大多数人熟知,因为我们对防火墙的第一印象就是可以阻止有害的报文伤害计算机;而后者就没这么有名了,很多人甚至不知道Netfilter有这项功能 2.连接跟踪是保存连接状态的一种机制。为什么要保存连接状态呢? 举个例子,当你通过浏览器访问一个网站(连接网站的80端口)时,预期会收到服务器发送的源端口为80的报文回应,防火墙自然应该放行这些回应报文。那是不是所有源端口为80端口的报文都应该放行呢?显然不是,我们只应该放行源IP为服务器地址,源端口为80的报文,而应该阻止源地址不符的报文,即使它的源端口也是80。总结一下这种情况就是,我们只应该让主动发起的连接产生的双向报文通过 我们可以使用iptables配置nat表进行地址或者端口转换的规则。如果每一个报文都去查询规则,这样效率太低了,因为同一个连接的转换方式是不变的!连接跟踪提供了一种缓存解决方案:当一条连接的第一个数据包通过时查询nat表时,连接跟踪将转换方法保存下来,后续的报文只需要根据连接跟踪里保存的转换方法就可以了 [size=1.5]总结 连接跟踪是Netfilter提供的一项基本功能,它可以保存连接的状态。用户可以为不同状态的连接的报文制定不同的策略; 连接跟踪在报文进入Netfilter的入口将信息记录在报文上,在出口进行confirm.确认后的连接信息可以影响之后的报文; 连接跟踪的信息主要包括基本的描述连接的tuple以及各协议的私有信息
附上连接: https://segmentfault.com/a/1190000019605260
|