手机连接VPN以后无法打开网页解决办法

阿汤博主在下班以后或者节假日偶尔要连接一下公司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实现局域网访问 https://www.amd5.cn/atang_4797.html

最大传输单元MTU详解 https://www.amd5.cn/atang_5116.html