The problem is that the linux platform uses pptp to build a vpn server. After dialing in to access the intranet ftp, downloading files is extremely slow; using it as a gateway to access the Internet, except for baidu, most websites have extremely slow access speeds and are almost inaccessible.
Solve adding to the *filter table of iptables of the linux service where pptp is located
-I FORWARD -p tcp --syn -i ppp+ -j TCPMSS --set-mss 1356
or run at the command prompt
/sbin/iptables -I FORWARD -p tcp --syn -i ppp+ -j TCPMSS --set-mss 1356
Cause Analysis
===== In case of disconnected vpn link:
Use ping -f -l XXXXXX 192.168.0.1 to test step by step under windowsXP (XXXXXXX is the MTU size, you can start from 1500 and gradually decrease until you know you can ping)
We can get the maximum MTU that can be pinged is 1426;
=====On the premise of connecting to vpn
Use ping -f -l XXXXXX 192.168.0.1 to test step by step under windowsXP (XXXXXXX is the MTU size, you can start from 1500 and gradually decrease until you know you can ping)
We can get the maximum MTU that can be pinged is 1372;
If it exceeds this number, it will not pass.
==== Dial through vpn, use netstat -i on the server to view the interface, get
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 102528561 0 0 0 0 0 Bru
Eth1 1500 0 519820535 954 11553 924 208798037 0 0
Bru LO 16436 0 151062 0 0 0 151062 0 0 0 LRU PPP0
1396 0 19 0 0 0 0 0 0 0 OPRU
It can be seen that the maximum mtu of ppp is 1396. Of course, the corresponding mss should be ( mtu - 20-byte IP header + 20-byte TCP header =) 1356
[Little knowledge 1] MSS in computer network:
MSS: Maximum Segment Size
The abbreviation of MSS maximum transmission size is a concept in the TCP protocol.
MSS is the maximum data segment that a TCP packet can transmit at a time. In order to achieve the best transmission performance, the TCP protocol usually negotiates the MSS value of both parties when establishing a connection. This value is often replaced by the MTU value when the TCP protocol is implemented (the size of the IP packet header needs to be subtracted. 20Bytes and TCP data The header of the segment is 20Bytes) so often the MSS is 1460. The communication parties will determine the maximum MSS value of this connection according to the minimum MSS value provided by both parties.
[Little knowledge 2] mtu is the largest packet transmitted by the network.
mss is the maximum value of data transmitted over the network.
mss plus header data is equal to mtu.
Simply take the TCP packet as an example.
If the message transmits 1400 bytes of data, then mss is 1400, plus 20 bytes of IP header and 20 bytes of tcp header, then mtu is 1400+20+20.
Of course, other protocols need to be added during transmission. The header is in the front, in short, mtu is the total size of the last message sent. mss is the size of the data you need to send.
[Tips 3] http://www.cnpaf.net/Class/TCPANDIP/200511/9898.html
Suppose the PC establishes an HTTP connection to the SERVER, and the PC wishes to download a large web page from the SERVER. After the SERVER receives the request from the PC, it starts to send the large web page file, the DF position of its IP is 1, fragmentation is not allowed, and the length of the IP message is 1500 bytes. After reaching the external network port (Ethernet) of VPN gateway 2, VPN gateway 2 finds that its length exceeds 1500 bytes, so it discards it, and sends back an ICMP message that the destination address is unreachable to SERVER, and points out "MTU of next hop: 1500”. After the PC receives the message, it sends it out according to 1500 bytes, and then it is discarded, thus forming a loop and unable to communicate.
According to the above analysis, it is easy to get the following solution. Set the MTU on the outbound interface of VPN gateway 2 to 1500-4-20=1476, so that when VPN gateway 2 returns the ICMP unreachable message, it will give "MTU of next hop: 1476" ". SERVER will send 1476 as its maximum MTU to the VPN gateway 1. After encapsulating GRE and outer IP header, it will not exceed 1500 and send it to the opposite end smoothly.
-I FORWARD -p tcp --syn -i ppp+ -j TCPMSS --set-mss 1356
因为mss是在TCP连接建立开始时，通过带有syn标志的IP数据包进行传输的，所以我们在iptables里面规定，在转发数据时，只要发现产生于ppt*的带有 syn标志数据包时，将其mss设定为1356字节，这样就与ppp0接口的路径MTU向匹配了，数据自然就可以畅通无阻啦。
（注，vpn拨入一个，则建立一个ppt*的虚拟设备，这个可以再linux上用ifcpnfig看到，第一个为ppp1，第二个为ppp2……）
参考：
1、http://fanqiang.chinaunix.net/app/other/2005-09-13/3655.shtml
2、http://technet.microsoft.com/zh-cn/library/cc768084(en-us).aspx
3、这是一个比较复杂的问题。首先，发现问题的过程是这样的：使用一台WinXP的电脑（简称主机A）连接公司的VPN成功后，访问内网的一个基于 B/S的CRM系统（简称主机B）时，发现首页可以显示（页面比较简单，包含的数据量较小），输入账号密码登陆后，发现只能显示页面顶部的一点点内容，而下面大部分内容无法显示。而换一台Win2000的电脑登陆，内容就可以完全显示出来。登陆到Linux VPN主机上，利用tcpdump对数据传输过程进行抓包分析，发现：每当B向A传输大于1396字节的数据时，VPN主机就会反馈B如下信息
注意：
10.87.0.200：VPN主机的内网网卡的IP地址
10.87.200.1：主机A的IP地址
10.87.200.6：主机B通过VPN获取的IP地址
21:54:21.953848 IP 10.87.0.200 > 10.100.0.100: icmp 556: 10.100.0.203 unreachable -
need to frag (mtu 1396)
可以看到VPN主机向提供web服务的主机B返回了一个ICMP不可达的差错报文。其含义是VPN主机收到了一个需要分片才能通过的数据包，而这个数据包在其IP头部又设置了不能分片（DF）的标志。所以该数据包不能通过VPN主机。
根据TCP/IP协议，在建立TCP连接时，传输双方都要指明自己的mss（最大报文长度）大小，然后选取双方之中最小的那个mss，以避免在随后的数据传送过程中出现数据包分片传输的情况。通过抓包分析，主机B的mss为1460字节，主机A的mss为1357字节。两者取小所以双方协商的结果确定 mss为1357字节，也就是说以后进行TCP数据传输时，数据包的最大传输单元MTU不能超过1397（mss+20字节的IP头部+20字节的TCP 头部），同时在IP头部设置了不能分片（DF）的标志。
然后在VPN主机上执行netstat –i，观察各个网络接口的路径MTU值为多少。观察结果如下：
Iface MTU
eth0 1500 //外网网卡接口
eth1 1500 //内网网卡接口
lo 16436 //本机回环接口
ppp0 1396 //WinXP VPN接入通道接口
可以看到ppp0接口的路径MTU为1396字节，也就是说如果一个数据包想要通过这个接口的话，一定不能大于1396字节，如果大于这个值，会出现两种结果：
1、如果这个数据包的IP头部没有设置不能分片（DF）的标志，那么VPN主机就把这个数据包分片，使其数据包大小小于1396字节，然后允许其通过。
2、反之，如果这个数据包的IP头部设置不能分片（DF）的标志，那么VPN主机就会返回一个ICMP不可达的差错报文。同时丢弃这个数据包。
问题就出在这里，主机A和主机B协商的mss为1357字节，也就是说其TCP数据包的MTU为1397，而ppp0允许的路径MTU却为1396，主机 A的MTU居然大于ppp0的路径MTU！当主机B向主机A发送了一个1397字节的数据包时，自然不能通过ppp0接口了。回到发现问题的那个情况，首页之所以能够显示成功，是因为首页包含的数据较小，传输时只需要一个没有超过1396字节的IP数据包就可以了，所以能够显示出来，而登陆成功后的页面包含的数据较大，需要分为多个IP数据包进行传输。这里可以假设一下，开头的一个IP数据包因为没有超过1396字节因而通过，而随后的IP数据包因为其大小为1397字节，超过了路径MTU，所以不予通过。反映到页面，就是登陆页面下面的大部分内容无法显示了。
我们再来看看用安装了Win2000主机C连接VPN又是什么状况呢？通过抓包发现，主机C提出的mss为1360（可以推算出其MTU为1400），而执行netstat –i，发现此时的ppp0的MTU为1496，路径MTU大于主机C的MTU，这个结果是正常的。
大家一定会问，为何主机B提出的MTU小于路径MTU，这个问题只能问问微软了，我查了一些英文资料，说这是WinXP本身系统的一个问题。
知道了问题的原理，那让我们来看看如何进行解决吧。解决方法很简单，就是借助iptalbes，设定主机B进行协商时提出的mss为1356。即在iptables里面加入一条规则：
iptables -A FORWARD -p tcp --syn -s 10.87.200.0/31 -j TCPMSS --set-mss 1356
Because mss is transmitted through IP data packets with the syn flag when the TCP connection is established, we stipulate in iptables that when forwarding data, as long as the IP data with the syn flag and the source address is host B is found When sending a packet, set its mss to 1356 bytes, so that it matches the MTU direction of the path of the ppp0 interface, and the data can naturally flow unimpeded.
Because mss is transmitted through IP data packets with the syn flag when the TCP connection is established, we stipulate in iptables that when forwarding data, as long as the IP data with the syn flag and the source address is host B is found When sending a packet, set its mss to 1356 bytes, so that it matches the MTU direction of the path of the ppp0 interface, and the data can naturally flow unimpeded.
Address of this article: http://www.92csz.com/52/1244.htmlIf not stated, it is an original article on the site, welcome to reprint. Please indicate the reprint from: moon's blog
Source: http://www.92csz.com/52/1244.html