阿湯博主在下班以后或者節假日偶爾要連接一下公司VPN處理一些工作上的事情，部署使用了一年多，VPN一直也沒出過什么異常問題。

但是突然有一天在家用手機連接VPN，發現無法打開網頁了，像baidu.com，qq.com這些都打不開了。

最近VPN也沒做過什么更改，怎么會突然出問題呢？

一開始以為是DNS的問題，通過ping和路由跟蹤測試，發現也能正常解析并達到域名解析的服務器。

然后又測試了微信、微博客戶端，連接VPN的情況下都能正常使用，內網的服務器和網站都可以正常訪問。

這下有點不知所措了，冷靜思科片刻后，決定一步步排查問題。

首先電腦連上VPN，測試下網絡訪問情況，電腦連上以后一切正常。

開始懷疑是手機問題，馬上換回之前用的舊手機測試發現一切正常，這下證實了我的懷疑。

為了進一步確認問題，到公司以后借了兩個安卓和一個蘋果手機，連接VPN測試，發現都無法正常打開百度、騰訊、360這些網站。

那為什么我原來那個舊手機就正常，比較新的手機都不能訪問呢？

經過斷斷續續的一段時間查找問題原因，基本確認造成連接VPN以后無法打開網站的罪魁禍首就是MTU和MMS。

那MTU是什么呢？

百度百科的介紹：

最大傳輸單元（Maximum Transmission Unit，MTU）用來通知對方所能接受數據服務單元的最大尺寸，說明發送方能夠接受的有效載荷大小。

是包或幀的最大長度，一般以字節記。如果MTU過大，在碰到路由器時會被拒絕轉發，因為它不能處理過大的包。如果太小，因為協議一定要在包(或幀)上加上包頭，那實際傳送的數據量就會過小，這樣也劃不來。大部分操作系統會提供給用戶一個默認值，該值一般對用戶是比較合適的。

以太網和802.3對數據幀的長度都有一個限制，其最大值分別是1500字節和1492字節。鏈路層的這個特性稱為MTU，即最大傳輸單元。不同類型網絡的數幀長度大多數都有一個上限。如果IP層有一個數據報要傳，而且數據幀的長度比鏈路層的MTU還大，那么IP層就需要進行分片( fragmentation)，即把數據報分成干片，這樣每一片就都小于MTU。

MSS(最大分段大小)是TCP里面的一個概念，它是TCP數據包每次能夠傳輸的最大數據分段，不包含包頭部分，它與IP MTU滿足如下關系：

MTU=MSS+20bytes（IP包頭）+20bytes（TCP包頭）

通過對概念的了解，知道主要原因就是手機連接VPN后的MTU協商值不太合適。比如Windows電腦手動設置MTU ping測試：

由于手機查看MTU網上也沒有什么好的方法，所以無法對比我舊手機和現在手機的MTU值。

解決方法就是通過Linux的iptables攔截MTU協商包并強行修改為1360。

下面是strongswan.org提供的解決方案：

原文如下：

MTU/MSS issues?

It is possible that you encounter MSS/MTU problems when tunneling traffic. This is caused by broken routers dropping

ICMP packets and thus breaking PMTUD. You can work around it by lowering the advertised MSS value of TCP with the TCPMSS

target in iptables.

Or, if you control the router in question, fixing PMTU may be advisable -- to do so you need to permit the appropriate ICMP

traffic (type 3, destination unreachable, code 4, fragmentation needed - though all of type 3 is usually allowed.)

In particular, one must pay attention to the source address of ICMP messages emitted by the VPN gateway, which will usually be

the primary IP address of the gateway's internal interface, not that of the endpoint experiencing the issue.

The value you set with the TCPMSS target must accommodate for any other overhead introduced by the tunneling protocols

in use (for instance, UDP encapsulation of ESP).

Google the issue and read the man page of iptables and iptables-extensions if there are any questions about its usage.

The charon.plugins.kernel-netlink.mss and charon.plugins.kernel-netlink.mtu may be used, too, but the values set there apply

to the routes that kernel-netlink installs and the impact of them onto the traffic and the behavior of the kernel is currently quite unclear.

Add the following iptables rules on the IKE responder to reduce the MSS (as noted above, the actual values depend on the overhead

imposed by the tunneling protocols and the MTU, so it might have to be lower than what's used in the example here):

iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

Alternatively, you can add the same rules in PREROUTING/POSTROUTING (also in the mangle table).

Additionally, set net.ipv4.ip_no_pmtu_disc on the server to 1.

In newer kernels, the counter XfrmOutStateModeError in /proc/self/net/xfrm_stat is incremented if the kernel detects that a packet would be too large after encapsulation.

如果成功解決，你可以將這些命令添加到 /etc/rc.local 讓系統重啟后繼續有效。

iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

配置以后重啟VPN服務，手機再次連接VPN，上網正常。

相關文章：

非固定公網IP怎么部署VPN實現局域網訪問 http://m.maowutv.com/atang_4797.html

最大傳輸單元MTU詳解 http://m.maowutv.com/atang_5116.html