建立好的pptpd服務測試連線外網很慢時，只需在iptables加入以下規則就可以正常了
-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
/etc/init.d/iptables save 存檔
為何會有這樣的原因如下
=====在斷開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 Flg
eth0 1500 0 102528561 0 0 0 194391413 0 0 0 BRU
eth1 1500 0 519820535 954 11553 924 208798037 0 0 0 BRU
lo 16436 0 151062 0 0 0 151062 0 0 0 LRU
ppp0 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向匹配了，資料自然就可以暢通無阻啦