两家网吧主线IP居然同网段？差点以为VPN客户端路由器出问题

gocloud-xiaowan

兄弟们，昨晚差点被一个低级网络问题搞到自闭。写出来给大伙提个醒，省得你们以后踩坑。

事情是这样的：

网吧b一直靠VPN互联网吧a的uu加速器，这几天经常断开，最后死活拨不进服务端。

排查过程（血压升高版）：

1. 第一反应：账号和密码不对？确认了一下，没变。

2. 第二反应：VPN服务没开？ 远程过去检查VPN服务进程，正常运行，日志里只显示对方断开连接。

3. 第三反应：防火墙/映射？ 检查了服务端路由器端口映射，其他网吧拨号过去是正常的。没问题。

破案时刻（完整版）：

同事发现拨号到vpn客户端，ping服务端ip不通，如图1，

但客户指定wan出口是通的。Icmp协议默认走主线，那主线就不是wan口，检查一看，主线果然是wan2。

此时我在vpn客户端指定出口wan，vpn通了！

这就怪了，同为公网IP，怎么WAN1能走，WAN2就走不了？

我这才仔细对比了两个IP：

· 客户端WAN2：219.xxx.xxx.100/24

· 服务端WAN口：219.xxx.xxx.84/24

破案了！ 我们两家网吧的主线，被运营商划在了同一个/24网段里！vpn客户端指定WAN1没这个问题是因为wan1的IP段不同。但走WAN2时，系统一算——目标IP跟我自己在一个子网里啊，于是数据包压根没往联通网关送，直接在局域网内ARP广播找219.xxx.xxx.84去了，隔了几公里的两家店怎么可能找得到？包死在内网，服务端当然收不到握手包。

WAN1能通反而成了烟雾弹，让我一直以为线路没问题。要不是最后指定出口对比测试，怕是还要在路由表里转圈到天亮。

解决方案（极简版）：

解决方式很简单，两个思路：

1. 修改客户端VPN拨号的路由网关。 在VPN连接配置里，添加静态路由或者修改接口跃点数，强制让去往对端IP的数据包走公网网关（0.0.0.0），而不是试图ARP广播。

2. （最粗暴）改子网掩码。 如果条件允许，在路由器上尝试把客户端或者服务端的WAN口掩码改为255.255.254.0甚至255.0.0.0，让系统不认为他俩是"邻居"。但这招容易被运营商限制，不推荐。

总结教训：

以前总想着公网IP只要不冲突就行，从来没留意过掩码计算后的"逻辑邻居"问题。现在连锁店越来越多，运营商给IP又抠抠搜搜，很容易几家店分到同一个C段。双线接入的兄弟更要留心——一条线能通不代表另一条也能通，指定出口对比测试应该作为标准排查流程。