VPN链路中的MTU传输问题(GRE tunnel)

问题概述：

我们的实际组网中经常遇到此类问题：
1. 某些网站浏览没有问题，而某些网站浏览非常慢甚至无法浏览。QQ等正常没有任何问题。
2. 无法下载大的文件。
3. EMAIL无法发大附件。

问题分析：

一般来说是由于路径MTU不匹配的缘故，特别是在经过了VPN链路的时候，譬如ADSL PPPOE拨号，L2TP,PPTP,IPSEC,GRE隧道等情况。下面就以GRE隧道为例来说明MTU的问题，其他隧道协议类似只是头部字节不同而已。

拓扑结构

VPN网关1和2之间建立了一条GRE隧道，VPN1 VPN2的外网口均为以太网口，MTU为1500。PC与SERVER通过该GRE隧道互访。

分析过程

• PC在ping –f –l 1448 SERVER 的时候可以ping 通，而ping –f –l 1449 SERVER的时候却收到报文不可分片错误。PC出来的IP报文长度为1448＋8（ICMP）＋20（IP），到达VPN网关1，VPN网关1发到GRE隧道口，封装GRE头（4），再加上外层IP头，到达VPN网关外层以太口，这时IP报文的长度已经变为：1448＋8＋20＋4＋20＝1500字节，刚好等于以太口的MTU，于是被顺利传送。而ping 1449时，到达外层以太口为1501字节，超出了1500的MTU，又因为报文DF位被设置，于是就只能丢弃改报文，并返回DF错误。
• 上述实验中出现此结果是因为DF被置位，导致无法分片。但是如果DF没有置位则可以正常的通过但是会出现分片的现象。不过现在很多服务器譬如WEB为了提高效率以及安全问题等所发出的包是不允许分片的。并且大多防火墙、IPS等设备，这些设备通常也是不允许分片通过的。因此就出现了有些网站无法浏览，大文件无法传输的情况。

解决方法

• 假设PC建立了到SERVER的HTTP连接，PC希望从SERVER下载一个大的网页。SERVER接收到PC的请求后开始发送大网页文件，其IP的DF位置1，不允许分片，IP报文长度为1500字节。到达VPN网关2的外网口（以太）后，VPN网关2发现其长度超过了1500个字节，于是将其丢弃，并给SERVER发回一个目的地址不可达的ICMP信息，同时指出“MTU of next hop: 1500”。PC接收到该消息后，又按照1500字节对外发送，又被丢弃，于是就形成了循环，无法通讯。
• 根据上述的分析，很容易得到如下解决方式，在VPN网关2的出接口设置MTU为1500－4－20＝1476，这样VPN网关2返回ICMP不可达消息时将给出”MTU of next hop: 1476”。SERVER将以1476作为自己的最大MTU对外发送，到达VPN网关1，封装GRE和外层IP头后就不会超过1500而顺利发到对端。这个是下载问题的解决，如果要解决上传的问题，在相应方向的接口修改MTU即可。当然也可以修改TCPMSS，不过这个是影响到TCP的windows从而减小了包的长度。另外修改操作系统的最大MTU值也是可行的，不过比较麻烦。