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

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

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

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

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

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

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

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

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

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

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

那MTU是什么呢？

百度百科的介紹：

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

是包或幀的最大長(zhǎng)度，一般以字節(jié)記。如果MTU過大，在碰到路由器時(shí)會(huì)被拒絕轉(zhuǎn)發(fā)，因?yàn)樗荒芴幚磉^大的包。如果太小，因?yàn)閰f(xié)議一定要在包(或幀)上加上包頭，那實(shí)際傳送的數(shù)據(jù)量就會(huì)過小，這樣也劃不來(lái)。大部分操作系統(tǒng)會(huì)提供給用戶一個(gè)默認(rèn)值，該值一般對(duì)用戶是比較合適的。

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

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

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

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

由于手機(jī)查看MTU網(wǎng)上也沒有什么好的方法，所以無(wú)法對(duì)比我舊手機(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實(shí)現(xiàn)局域網(wǎng)訪問 http://www.zhongjima.net/atang_4797.html

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