IP分片

【写在前面】：

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)浏览(850)

IP分片(IP Fragment)

作者：易隐者 发布于：2012-9-3 22:22 Monday 分类：网络分析

为什么要分片

       不同的链路类型能够支持的最大传输单元值（MTU: Maxitum Transmission Unit）主要是由相关RFC文档规定的，常见的以太网链路的MTU值为1500，如果需要转发的IP报文超出其转发接口的MTU值，则在转发该报文之前，需要将其分片，分为多个适合于该链路类型传输的报文，这些分片报文在到达接收方的时候，由接收方完成重组。

       各种常见链路类型的MTU值如下图所示：

报文的分片和重组

       我们先来看一下分片的过程，为了简单起见，我就用《TCPIP详解卷一》第11章《UDP：用户数据报协议》中关于IP分片的案例，应用进程将1473字节应用字段交给UDP处理，UDP加上8字节的UDP报头之后，交给IP层处理，IP层在转发之前，发现该报文长度超出转发接口的MTU，因此需要分片，分为两个IP分组，如下图所示：

       从上图可以看出原始的IP报文经过分片后，只有第一个分片报文是带有四层信息的，后续报文均不带四层信息，为做直观展示，我找了一个实际环境下抓取的分片报文，如下图所示：

       这是分片的第一个报文，我们可以看到该报文IP层封装的上层协议为ICMP协议，这是一个ping报文（上层协议信息），我们再来看一下后续分片报文的解码：

       这是分片后续报文，我们能看到封装的是ICMP协议，但是封装的上层协议的具体信息就无法看到了。

       IP数据报被分片之后，所有分片报文的IP报头中的源IP、目的IP、IP标识、上层协议等信息都是一样的（TTL不一定是一样的，因为不同的分片报文可能会经过不同的路由路径达到目的端），不同的地方在于分片标志位和分片偏移量，而接收方正是根据接收到的分片报文的源IP、目的IP、 IP标识、分片标志位、分片偏移量来对接收到的分片报文进行重组。

       接收方根据报文的源IP、目的IP、IP标识将接收到的分片报文归为不同原始IP数据报的分片分组；分片标志中的MF位（More Fragment）标识了是否是最后一个分片报文，如果是最后一个分片报文，则根据分片偏移量计算出各个分片报文在原始IP数据报中的位置，重组为分片前的原始IP报文。如果不是最后一个分片报文，则等待最后一个分片报文达到后完成重组。

分片带来的问题

1， 分片带来的性能消耗

       分片和重组会消耗发送方、接收方一定的CPU等资源，如果存在大量的分片报文的话，可能会造成较为严重的资源消耗；
       分片对接收方内存资源的消耗较多，因为接收方要为接收到的每个分片报文分配内存空间，以便于最后一个分片报文到达后完成重组。

2，分片丢包导致的重传问题

       如果某个分片报文在网络传输过程中丢失，那么接收方将无法完成重组，如果应用进程要求重传的话，发送方必须重传所有分片报文而不是仅重传被丢弃的那个分片报文，这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。

3， 分片攻击

       黑客构造的分片报文，但是不向接收方发送最后一个分片报文，导致接收方要为所有的分片报文分配内存空间，可由于最后一个分片报文永远不会达到，接收方的内存得不到及时的释放（接收方会启动一个分片重组的定时器，在一定时间内如果无法完成重组，将向发送方发送ICMP重组超时差错报文，请大家参考本博客《ICMP重组超时》一文），只要这种攻击的分片报文发送的足够多、足够快，很容易占满接收方内存，让接收方无内存资源处理正常的业务，从而达到DOS的攻击效果。

4， 安全隐患

       由于分片只有第一个分片报文具有四层信息而其他分片没有，这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。
       如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文，则有可能给接收方带来安全隐患和威胁，因为黑客可以利用这个特性，绕过路由器、防火墙的安全策略检查对接收方实施攻击；
       如果路由器、防火墙等中间设备对这些分片报文进行重组后在匹配其安全策略，那么又会对这些中间设备的资源带来极大的消耗，特别是在遇到分片攻击的时候，这些中间设备会在第一时间内消耗完其所有内存资源，从而导致全网中断的严重后果。

       基于以上原因，很多应用程序都尽量避免分片的产生，其通过将IP报文的分片标志中的DF位（Don’t Fragment）置一来实现，而这可能给应用带来一些难以预料的麻烦。下一篇我将介绍端系统如何处理这种状况，请大家关注。

分片补充

1，分片既有可能发生在端系统（发送主机）上，也可能发生在转发报文的路由器、防火墙等中间系统上。
2，分片只发生在转发出接口上。

跟分片有关的案例

        后续我会在本博客里添加一些跟分片有关的案例，有兴趣的同学可关注。

阅读全文>>

标签: ip分片 重组超时 IP标识 icmp差错 分片 ip fragment IPID UDP 分片攻击 分片偏移量 DF位 MF位 MTU 重组 fragment ICMP

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

大包传输丢包故障

作者：易隐者 发布于：2012-4-28 23:35 Saturday 分类：网络分析

故障环境

某公司与集团城域网的连接拓扑大体如下图所示：

说明：

1、办公机器都属于10.12.128.0/24网段；

2、办公机器通过一个二层的  接入交换机、光电转换器接入集团核心交换机。

故障现象

1、网络中办公机器传输大包时有丢包，主要通过在测试机器10.12.128.66上使用如下命令进行测试：ping 10.1.10.9 –l 10000 –t ，即向集团DNS服务器10.1.10.9发送长度为10000字节的数据包，我们发现丢包现象非常严重；

2、网络中小包传输都正常，没有丢包；

3、前期已经使用单机ping大包测试过，没有发现丢包问题。