关于VPN链路中的MTU传输问题

　　二、问题分析：

　　一般所来是由于路径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值也是可行的，不过比较麻烦。