在Internet的IPVPN中1个60K左右的数据将被拆分为多个min(MTU/MSS)的报文然后发送。
一 首先分清楚分片和分段的区别？
分片是IP层的概念。检查IP分片的标志是检查IP层头部的Flag字段里的df bit和more fragment位。检查是否分片和有否后续的分片报文。
同时在IP层包头的最后有个字段为ip fragments会详细写明分片的帧数及长度。（由此可以判断我们发送出去没有进行IP分片）
分段是TCP层的概念。此时将会用到MSS。在本例中，我们选用1460做为MSS。根据协商的结果动态产生。现象就是在每个（除第一个）SMTP
消息的Body报文中，都会看到每一个的TCP净载数据大小为1460。通过发给对方的第一个TCP的SYN报文里的option字段会携带MMS字段通知对方自己所使用的MSS。而对方会在对SYN的回应中返回自己的MMS字段。这样，双方协商成功。发送方根据收到的ACK里含有的对方MMS大小与本机比较选取较小值进行MMS进行分段。
由于此时我们的MSS小于接口的MTU。所以我们选用1460做为TCP负载的分片大小。加上20字节的IP包头和20字节的TCP头部。总共为1500字节。如果此时，超过接口MTU 1500的话，仍然将进行分片。但此时没超。刚好等于。所以我们没有进行分片。
二 为什么在思科路由器上GRE接口的默认MTU为1476？
因为GRE会重新封装一个IP包头，以及加上GRE的4字节头部，一共是24个字节。这样总的IP包的长度为1500。在Internet上传递的时候不会因为中间的某一台设备不支持分片而将此报文丢弃。同样的道理，在PPPOE的环境下，我们通常设置MTU为1492。因为PPPOE的头部是8个字节。
在sun的server上默认的mss值为64595（2的16次方-1)。MTU为1500。
在发送的时候，会比较MSS和MTU的最小值进行分片。此例还将选取1500进行分片。但在TCP协商的时候，两端的server会协商选举一个最小的MSS来进行TCP层的分片。在此例中，察看capture.cap报文可以看到我们是在用1460大小的字节在TCP层进行分片。因为我们和对方协商后选用了1460字节。由于TCP的数据净载是1460，再加上20字节的IP头，再加上20字节的TCP头部。（察看capture.cap文件的IP和TCP的header lenth部分）。所以总共的长度为1500字节。虽然我们已经将df位设置为0。可以进行分片。但是由于没有超过MTU长度所以没有分。
在经过IPSEC加密时，由于IPSEC的最大长度为58个字节。因此经过internet到达对方的checkpoint防火墙时就是1558字节。checkpoint在检查时就会将包进行分片。分片后再传给后面的CSS。但经过比较发现，在CSS上的抓包，显示有部分分段丢失。而且CSS上老是没有手收到关于这个包的前几段消息，而且始终在重发ack消息。而在我们的server上可以看到，我们也收到了对方的ack。但仍在重传。最后超时。最后发现，此现象是由于对方的checkpoint上的一个安全特性所导致的。当在checkpoint上老是收到重传的tcp fragment报文时，就会认为这是一次攻击，并将这些报文扔掉。可以在sun上通过修改最小重传时间来解决。但需要重启设备。
因此，以上问题有3种解决方案。
1 在server上用ndd /dev/tcp_max_mss_ipv4命令修改最大的MSS为1442，问题解决。
2 在server上用ifconfig 命令修改接口mtu为1442，问题解决。改为1442后，可以保证在server就已经将包分片成为每个包是1422字节大小的IP包长度。在internet上和对方checkpoint上不分片。
3 在server上修改重传时间。现有为400ms。（需重启）。
4 在internet上所有设备启用mtu自动发现功能。（但不现实，而且公网上很多设备拒绝了icmp的报文。使得PMTUD失效).
5 在internet上的这些中间设备上修改接口的mtu为至少大于1558。（但不现实）
6 不使用ipsec。使用peering连接。这样可以避免ipsec的头部。
小技巧：
通过发现对方的抓包的mac地址的前6位，可以发现对方使用的设备的厂家。
阅读(4576) | 评论(0) | 转发(0) |
