Tuesday, March 29, 2011

pptp搭建的vpn代办代庖上网很慢 终于解决


问题:用pptp搭建了linux平台的vpn处事器,拨入后访谒内网ftp,下载文件极慢;用其作网关上网,除了baidu外,年夜部门网站访谒速度极慢,几乎无法访谒。 解决: 在pptp地址的linux处事的iptables的*filter表中插手 -I FORWARD -p tcp –syn -i ppp+ -j TCPMSS –set-mss 1356 /sbin/iptables -I FORWARD -p tcp –syn -i ppp+ -j TCPMSS –set-mss 1356 原因剖析 =====在断开vpn链接的情形下:在windowsXP下用ping -f -l XXXXXX 192.168.0.1一步一步测试(XXXXXXX为MTU巨细,可以年夜1500起头,逐渐减小,知道可以ping通)我们可以获得可以ping通的MTU最年夜为1426;=====在毗连vpn的前提下在windowsXP下用ping -f -l XXXXXX 192.168.0.1一步一步测试(XXXXXXX为MTU巨细,可以年夜1500起头,逐渐减小,知道可以ping通)我们可以获得可以ping通的MTU最年夜为1372; 跨越这个数则不能通,====拨通vpn,在处事器上用netstat i查看接口,获得Iface MTU Met … 继续阅读

问题:用pptp搭建了linux平台的vpn处事器,拨入后访谒内网ftp,下载文件极慢;用其作网关上网,除了baidu外,年夜部门网站访谒速度极慢,几乎无法访谒。 解决: 在pptp地址的linux处事的iptables的*filter表中插手 -I FORWARD -p tcp –syn -i ppp+ -j TCPMSS –set-mss 1356 /sbin/iptables -I FORWARD -p tcp –syn -i ppp+ -j TCPMSS –set-mss 1356 原因剖析 =====在断开vpn链接的情形下:在windowsXP下用ping -f -l XXXXXX 192.168.0.1一步一步测试(XXXXXXX为MTU巨细,可以年夜1500起头,逐渐减小,知道可以ping通)我们可以获得可以ping通的MTU最年夜为1426;=====在毗连vpn的前提下在windowsXP下用ping -f -l XXXXXX 192.168.0.1一步一步测试(XXXXXXX为MTU巨细,可以年夜1500起头,逐渐减小,知道可以ping通)我们可以获得可以ping通的MTU最年夜为1372; 跨越这个数则不能通,====拨通vpn,在处事器上用netstat i查看接口,获得Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flgeth0 1500 0 102528561 0 0 0 194391413 0 0 0 BRUeth1 1500 0 519820535 954 11553 924 208798037 0 0 0 BRUlo 16436 0 151062 0 0 0 151062 0 0 0 LRUppp0 1396 0 19 0 0 0 8 0 0 0 OPRU 可知ppp的最年夜mtu为1396,当然,对应的mss应为(mtu-20字节的IP头部+20字节的TCP 头部=)1356 【小常识1】计较机收集中的MSS:MSS: Maximum Segment Size 最年夜分段巨细MSS最年夜传输巨细的缩写,是TCP和谈琅缦沔的一个概念。MSS就是TCP数据包每次能够传输的最年夜数据分段。为了达到最佳的传输效能,TCP和谈在成立毗连的时辰凡是要协商双方的MSS值,这个值TCP和谈在 实现的时辰往往用MTU值庖代(需要减去IP数据包包头的巨细20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460。通信双方会 按照双方供给的MSS值得最小值确定为此次毗连的最年夜MSS值。 【小常识2】mtu是收集传输最年夜报文包。 mss是收集传输数据最年夜值。 mss加包头数据就等于mtu. 简单说拿TCP包做例子。 报文传输1400字节的数据的话,那么mss就是1400,再加上20字节IP包头,20字节tcp包头,那么mtu就是1400+20+20. 当然传输的时辰其他的和谈还要加些包头在前面,总之mtu就是总的最后发出去的报文巨细。mss就是你需要发出去的数据巨细。 【小常识3】http://www.cnpaf.net/Class/TCPANDIP/200511/9898.html 假设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而顺遂发到对端。 -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看到,第一个为ppt1,第二个为ppt2) 参考: 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 因为mss是在TCP毗连成立起头时,经由过程带有syn标识表记标帜的IP数据包进行传输的,所以我们在iptables琅缦沔划定,在转发数据时,只要发现带有 syn标识表记标帜而且源地址为主机B的IP数据包时,将其mss设定为1356字节,这样就与ppp0接口的路径MTU向匹配了,数据自然就可以通顺无阻啦。 因为mss是在TCP毗连成立起头时,经由过程带有syn标识表记标帜的IP数据包进行传输的,所以我们在iptables琅缦沔划定,在转发数据时,只要发现带有 syn标识表记标帜而且源地址为主机B的IP数据包时,将其mss设定为1356字节,这样就与ppp0接口的路径MTU向匹配了,数据自然就可以通顺无阻啦





Published by
Published by xFruits
Original source : http://www.vpn123.tk/?p=219...

No comments:

Post a Comment