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

但是突然有一天在家用手機(jī)連接VPN，發(fā)現(xiàn)無法打開網(wǎng)頁了，像baidu.com，qq.com這些都打不開了。

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

一開始以為是DNS的問題，通過ping和路由跟蹤測試，發(fā)現(xiàn)也能正常解析并達(dá)到域名解析的服務(wù)器。

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

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

首先電腦連上VPN，測試下網(wǎng)絡(luò)訪問情況，電腦連上以后一切正常。

開始懷疑是手機(jī)問題，馬上換回之前用的舊手機(jī)測試發(fā)現(xiàn)一切正常，這下證實了我的懷疑。

為了進(jìn)一步確認(rèn)問題，到公司以后借了兩個安卓和一個蘋果手機(jī)，連接VPN測試，發(fā)現(xiàn)都無法正常打開百度、騰訊、360這些網(wǎng)站。

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

經(jīng)過斷斷續(xù)續(xù)的一段時間查找問題原因，基本確認(rèn)造成連接VPN以后無法打開網(wǎng)站的罪魁禍?zhǔn)拙褪荕TU和MMS。

那MTU是什么呢？

百度百科的介紹：

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

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

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

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

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

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

由于手機(jī)查看MTU網(wǎng)上也沒有什么好的方法，所以無法對比我舊手機(jī)和現(xiàn)在手機(jī)的MTU值。

解決方法就是通過Linux的iptables攔截MTU協(xié)商包并強(qiáng)行修改為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 讓系統(tǒng)重啟后繼續(xù)有效。

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服務(wù)，手機(jī)再次連接VPN，上網(wǎng)正常。

相關(guān)文章：

非固定公網(wǎng)IP怎么部署VPN實現(xiàn)局域網(wǎng)訪問 http://www.zhongjima.net/atang_4797.html

最大傳輸單元MTU詳解 http://www.zhongjima.net/atang_5116.html