天融信 - 蚂蚁网-多维人生，三实而立！

欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

天融信防火墙报文处理流程

作者：易隐者发布于：2012-11-21 13:12 Wednesday 分类：参考资料

天融信作为国内知名的防火墙品牌，其拥有巨大的用户群体，因此天融信防火墙也是在实际工作环境中最为常见的防火墙之一，天融信防火墙的报文处理流程如下图所示：

阅读全文>>

标签: 天融信防火墙报文处理流程

评论(0) 引用(0) 浏览(7254)

【转】某加密机经天融信防火墙后应用异常故障案例

作者：易隐者发布于：2012-9-24 14:10 Monday 分类：案例讨论

【写在前面】：

1，该案例是一个特殊应用、特殊环境下的疑难故障案例，给我们的启示是在故障现场，我们需要充分了解清楚跟故障有关的应用特性，比如此案例中的加密机的工作机制；

2，该案例涉及到以下知识点：IP报头校验和、IP分片（请参考本博《IP分片》一文）、防火墙对分片报文的处理等；

3，此案例在整理文档时，应该简化了很多的分析测试过程，我按照我的理解做一些梳理：

（1），IP报头校验和只跟IP报头有关，跟IP封装的数据无关，因此，如果原文中的描述的“收到报文是否进行校验和检查”是指IP报头检验和的话，那么应该不会存在校验和错误而被防火墙丢弃的问题，如果是指TCP校验和或UDP检验和的话，那么，每个来自于加密机的报文其TCP或UDP校验和都是错误的（因为多了33字节），因此防火墙肯定会直接丢弃这个报文，根本不存在文档中描述的在防火墙转发接口抓到1460字节数据包的情况；

（2），防火墙不对收到的报文进行校验和计算，那么这个报文才会进入防火墙的内核处理流程，因为来自于加密机的报文是IP分片报文，因此防火墙会对此分片报文进行处理（选择直接转发分片报文还是重组后匹配策略再转发），如果防火墙直接转发，则没什么问题，如果是重组转发，这里就存在一个问题：防火墙能否完成这个报文的重组？因为IP分片的重组是根据IP报头中的相关信息来完成的，其中非常重要的一个参数就是分片偏离量，这个值决定了分片报文在原始报文中的位置，而在这个故障环境下，每个报文都被加密机在尾部添加了只有加密机能够识别的特征码，防火墙并不能识别，那么防火墙在重组这些报文的时候，如何处理正常分片报文跟前一分片报文尾部添加的33字节部分的重叠呢？这是值得思考的。如是覆盖33字节的尾部识别码，则到达对端加密机后，加密机会丢弃这个报文，并不是因为文中所说的“认为加密数据被篡改”，而是由于被覆盖了数个识别码导致接收端加密机无法正常识别加密报文（篡改的识别是通过校验和得到的，接收方根据报头信息可以计算出校验和，也就是说只要报头信息没错，校验和就不会错，而防火墙在重组完毕后转发前肯定会重新计算转发报文的报头校验和）。

4，各位读者兄弟根据自己的理解，自由参考我上面的分析和下面的案例原文，欢迎探讨和交流。

【原文全文】：

一、拓扑

二、环境描述

该拓扑使用的VPN链路是某公司的产品，该VPN在做加密处理时，TCP头和IP头都不做加密，只对数据区做加密，通过在加密机的抓包，发现加密机把所有MTU大于1300的数据包做了分片处理，并且在所有包的末尾加入自己的N字节加密识别码，这样从加密机发出的数据包MTU值最大1333，对于大于1333的报文（如1460）的数据包加密机都是分2个包进行传送，在没接防火墙时一切正常，接入防火墙后导致访问不正常；
拓扑中客户端172.16.1.22在访问服务器172.16.1.33时，服务器回应的MTU值1460数据包被服务器端加密机拆成2个包（第一个包1300），并在每个包的末尾加入33位，而防火墙在接收时将两个包合并转发，具体表现为防火墙接收口（接服务器端加密机）收到的报文数据长度是1333，而转发口（接客户端加密机）转发的报文数据长度是1460，这样客户端加密机就认为加密数据被篡改，导致VPN加密通讯错误；

三、分析过程与解决方式

1、由于加密机的特殊性，所以加密封包后的数据在通过防火墙时，会被认为是错误报文，
解决方法：将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消，如下图所示

2、加密机对大于1300的数据包做分片处理，到防火墙时，发现数据是分片包，防火墙又给重组后转发，导致对端加密机认为数据被篡改，不再对该数据包做解密处理；
解决方法：启用防火墙中的分片处理，将经过防火墙的数据都不做分片重组处理；
3、以上两点设置好后，TCP报文可以正常通讯，但UDP报文（如视频报文）由于数据量大的缘故在通过防火墙时，经常丢包；
解决方法：研发根据该问题给了一个特殊的补丁，专门解决UDP报文处理的，只要打上该补丁即可；

四、总结

1、将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消；
2、启用防火墙中的分片功能，将经过防火墙的数据都不做分片重组处理；
3、打上专用的补丁；

阅读全文>>

标签: ip分片天融信分片防火墙重组校验和 IP报头检验和

评论(0) 引用(0) 浏览(18208)

访问搜狐163时主页变为2008年某日主页面故障分析案例

作者：易隐者发布于：2012-8-13 22:26 Monday 分类：网络分析

1 故障环境

故障环境的拓扑结构示意图如下：

防火墙做NAT通过电信接入线路访问互联网，核心交换机上接入的设备和线路比较多，内部网络规模比较大。

2 故障现象

故障现象主要体现在以下几个方面：
1，用户在内网访问搜狐和163主页时，页面变为2008年某日的主页面，所有连接均为2008年的新闻连接，如下图所示：

其他网站页面访问均正常。
2，使用笔记本配置为公网地址直接访问搜狐和163正常；
3，在防火墙的一个空闲端口设置地址，通过防火墙NAT地址转换后访问搜狐163主页正常；

此故障已经持续了数周。

阅读全文>>

标签: 端口镜像交换机疑难故障 TCP 天融信 RST reset HTTP会话劫持会话劫持 TTL

评论(1) 引用(0) 浏览(9900)

天融信的debug功能

作者：易隐者发布于：2012-5-3 15:49 Thursday 分类：网络安全

1，debug说明：

在TOS 3.3.005以上版本下使用

通常遇到了防火墙的故障时一般是通过抓包的方式来查看进出的数据包，但是有些情况下设备不支持抓包（如：425平台）或者通过抓包无法分析出故障，那么这种情况下可以通过防火墙的DEBUG功能（005以上版本都可以支持，与硬件平台没关系）来进行故障的定位，这个功能可以观察数据包在防火墙不同的模块间数据转发的一个过程，可以很快定位数据故障的原因，下面介...

阅读全文>>

标签: 天融信 debug

评论(5) 引用(0) 浏览(6921)