《错误的网络访问控制策略导致PMTUD》由会员分享，可在线阅读，更多相关《错误的网络访问控制策略导致PMTUD（7页珍藏版）》请在金锄头文库上搜索。
1、错误的网络访问控制策略导致PMTUD,实 现故障一例, 基于网络环境安全的可信 访问控制策略错误的网络访问控制策略导致 PMTUD 实现故障一例Jun 27,2004作者：Yiming Gong声明:任何形式的摘抄必须保留上述作者和 http 地址 前一阵子处理了公司转过来的一个关于 PMTUD 实现的故障，在处理的过程中感觉 这是一个国内大网内比较广泛存在的关于安全方面的访问控制列错误配置问题， 而且很多技术人员对 PTMUD 实现几乎没有概念，因此周末花点时间来记录一笔。转过来的邮件部分内容是这样的“xx省服务器无法下载大文件的问题已经很久 了，故障早已经升级到专家组处理，但一直没有解决。
2、由于其他省市（如 xx， xx）也遇到了类似的情况“还是应该介绍下什么是 PMTUD： 首先我们知道各种网络链路介质对走在自身的最大数据帧长度都是有要求的，比 如以太网就是1500byte,这个值称为MTU。其次我们知道TCP为了性能考虑，在传输数据包的时候，会尽可能的发送大的分 组段，在三次握手时刻，双方要各自通告自己的MSS （最大传输段），告知对方 自己能收到的最大报文段长度（注意 MSS 仅仅是 TCP 的 payload）。 而每端的这 个MSS又是通过比较out going端口的MTU和自身buffer，取最小值而来的再减 去ip头和TCP头长度而来的，由于大多数主机的buffer
3、都很大，应此一般来讲， 以太网介质上的主机常常声明的 MSS 都是 1500byte-20byte IP 头-20 byte TCP 头=1460 byte。 补充一句，突然觉得恐怕有人要打岔：“错误！也不是分组越 大越好的确，记得Richard st evens在他的文档里面提到过这个问题，结论 是分组不是一定越大越好。有兴趣的可以去翻，不过一般来讲， TCP 双方还是尽 可能的使用大的分组的。需要注意的时，即使双方MTU均为1500，也不是万事大吉，因为传输两端主机 的中间“可能“会走过不同的网络介质，这些网络介质的MTU可能会小于1500， 那么使用1460 byte作为传输分组段大小的
4、主机在经过这些介质时就会出现问题, 导致数据包无法通过。IP层的分片方法可以解决这个问题：P层会比较自身MTU和收到数据包的大小， 如果收到的IP数据报长度大于自身MTU，那么就需要讲数据报文分片一一IP层 可以打散收到的数据包设想一下你的女友吃一个大苹果，囫囵吞下去难度太大, 必须一口口分解那个苹果。不过在TCP/ip实现的过程中，还是尽量避免分片的，这是因为IP是无连接的， 缺乏对分片的确认和重传机制，哪怕只有一个分片在传输的过程中被丢弃或超时 那么整个数据报都要重传。其次，由于数据报分片的重组是在最终的目的主机上 完成的，那么分片开始后即使后续路径上所有的MTU都非常大，也只能使用此小
5、分片，这就极大的降低了传输效率。因此，TCP在通讯过程中，总是尽可能的选取尽可能大但又不会被中间路径任意 一跳设备打散的数据包大小。这个数据报大小就可以被称为PMTU，它等于路径 中所有网络设备中最小的那个MTU值。那么避免分片又是如何实现的呢？就是IP包头的DF位标志，IP可以通过为数 据报设置DF (Don t frag)标志，禁止对数据报分片，来探测路径中MTU小于 目前使用MTU的设备，这就是PMTUD。当IP层收到带DF位标志的数据报时，如 果MTU大小允许通过，那么一切照旧；如果分组段+包头大小大于自身MTU允许 值，那么将不再采取自动打散数据报的方式，而是给源主机发送ICMP T
6、YPE 3 CODE 4 (fragmen tat ion needed and DF set)报文，源主机收到这个ICMP错误反馈 后，会减小自己的分组段大小来适应路径中MTU小于目前使用分组段+包头大小 的设备，然后重传数据报。(好长，总算一口气写完了大致原理八) 看到邮件后，下意识的感觉就是router上错误的配置了针对ICMP的访问控制列, 从我以往的经验来看，目前国内很多大的ISP的路由/交换维护人员在配置ACL 的时候，往往错误的毙掉所有的ICMP数据包。我们的这个客户网络分布于国内 各个省，同时中间还使用到多家ISP的物理链路，那么就很大的可能在中间某一 跳的router上错误的
7、配置了 ICMP的ACL，从而使路由/交换设备发出的ICMP TYPE 3 CODE 4 无法顺利到达故障两端的主机，主机无法接收到 icmp 3/4， so 认为 PMTUD实现中目前采用的MSS不存在问题，从而永远尝试用目前实际上已经大于 网络中某一跳MTU值的MSS传输，so永远无法顺利传输。在rfc 2923 ( TCP Problems with Path MTU Discovery) 里面对这种故障非常明确的进行了解释， 有兴趣的可以自去翻阅。根子上的问题是这样的，那么如何解决呢？个人总结了下，一般而言，对PMTUD 实现故障的解决方法大概有如下几种：1：检查传输过程中每一跳的ic
8、mp访问控制配置，从而使PMTUD得以正常实现, 这是彻底的解决方法。2：修改路径中小于故障两端的主机MSS值的网络设备的MTU，从而使故障两端 的主机的数据包能够顺利通过，不过这个的慢慢找。3：修改故障两端的主机配置，禁止实现PMTUD，永远以小包方式传输，这是个 笨办法，效率太差。4：目前cisco设备还支持使用ip TCP adjust-MSS命令强制调整MSS值，或使 用策略路由中的强制清除df标识位命令，等于变通的调整了 PMTUD的实现。按照个人的想法:此时首先应该寻找一个快速的方法定位MTU小于1500的网络， 第一个想法就是使用PING命令，通过-f指定强制增加DF标志和-l指
9、定数据报 payload大小来找出存在问题的那一跳router,不过马上想起ICMP被毙了，ping 根本不可能，这个法子行不通；再来，想到hping,（哈，这个软件终于出新版 的了，作者晃点了半年），这个倒是可以以非icmp方式来指定数据报payload 和强制增加DF标志位一路trace过去来找出存在问题的那一跳router。可惜让 没有经验的客户去编译和使用会%$#!。So,不管那么多，干脆使用上面的方法3先来让客户的网络通了再说，具体出问 题的点可以让同事慢慢的查， ：） 我们了解到的目前有问题的两台主机使用的 操作系统是 HP unix 和 windows 2000准备在 PMTUD
10、 上开始做些工作了，hpunix不熟悉，不过没关系，goolge下，键入关键字PMTU hp unix，第一个页 面就有非常好的东东，cisco的文档，Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun System，好东西！正好是我们要得内容，里面对多种操 作系统的涉及PMTUD的调整进行了说明，题外话：cisco的文档系统做的真是棒 啊！下了文档，跳过前面的概念，直接找到hpunix部分，如下：HPUX 11 supports PMTU discovery and enables it by default. This is co
11、ntrolled through the ndd settingip_pmtu_strategy command.# ndd h ip_pmtu_strategy 0Set the Path MTU Discovery strategy: 0 disables Path MTU Discovery; 1 enables Strategy 1; 2 enablesStrategy 2. For further information, use the ndd h command on an HPUX 11 system.找了台 hpunix， ndd -h ip_pmtu_strategy 下，
12、Set the Path MTU Discovery strategy: 0 disables Path MTUDiscovery; 1 enables Strategy 1; 2 enables Strategy 2. Because of problems encountered with some firewalls, hosts, and low-end routers, IP provides for selection of either of two discovery strategies, or for completely disabling the algorithm.
13、The tunable parameter ip_pmtu_strategy controls the selection.Strategy 1: All outbound datagrams have the Dont Fragment bit set. This should result in notification from any intervening gateway that needs to forward a datagram down a path that would require additional fragmentation. When the ICMP Fra
14、gmentation Needed message is received, IP updates its MTU for the remote host. If the responding gateway implements the recommendations for gateways in RFC?191, then the next hop MTU will be included in the Fragmentation Needed message, and IP will use it.If the gateway does not provide next hop inf
15、ormation, then IP will reduce the MTU to the next lower value taken from a table of popular media MTUs.Strategy 2: When a new routing table entry is created for a destination on a locally connected subnet, the Dont Fragment bit is never turned on. When a new routing table entry for a non-local desti
16、nation is created, the Dont Fragment bit is not immediately turned on. Instead, oAn ICMP Echo Request of full MTU size is generated and sent out with the Dont Fragment bit on.oThe datagram that initiated creation of the routing table entry is sent out immediately, without the Dont Fragment bit. Traffic is not held up waiting for a response to the Echo Request.oIf no response to the Echo R
