近期宽带大面积改造 IPoE 后遇到的频繁提示网络环境异常频繁弹出验证码的问题推测及临时解决方法

[oblivion]

近期长三角一代联通和移动又大面积推动了一次 vBRAS 上线 IPoE 改造割接，
很多群里的小伙伴发现一夜之间自己的光猫被推送了路由模式并且已经变为 IPoE 认证，

但是在割接后发现打开很多互联网大厂网站，频繁要求滑动验证，点击验证，
相关 APP 也经常出现网络环境异常的提示，甚至外卖网购下单被风控无法下单，
还有一些人社交账号被无缘无故的封号。

结合相关群友来看，时间点集中在割接 vBRAS 和 IPoE 后，因此推断是某一变化导致被各互联网大厂风控。

经过近两周的抓包对比测试，最终将问题确定在了 MTU 上，
改造 IPoE 前的网络由于使用 PPPoE 认证导致 MTU 普遍在 1492 以下正常是 1480 ，
改造 IPoE 后网络 MTU 为标准的 1500 ，

猜测这些大厂的风控措施有一种探测来源 IP 的 MTU 进行风控的规则，
包括不限于使用 ICMP/TCP/UDP 对你的客户端 IP 发送或者回复一个标准 1500 尺寸包且不允许分片的方式，

经过多次控制变量的测试（全新操作系统，新的 IP ，连续使用一天左右），
以某厂为例，首次使用一个新 IP 打开该网站后，会收到 4~6 个 ICMP 包，尺寸是 1500 ，1472 ，1440 ，1280 ，
四种尺寸包正常回复：有风控，搜索任意关键字会弹出点击验证码，
1500 回复 code3 type4 ，其他正常回复：正常
1500 ，1472 回复 code3 type4 ，其他正常回复：正常
1500 ，1472 ，1440 回复 code3 type4 ，1280 正常回复：有风控，网页正常，登录提示环境异常
全部丢弃：有风控，但是很轻微，没有很多提示，偶尔会出几个验证码

因此推测 MTU 是这些大厂来判断客户端是 IDC 还是家庭客户的条件之一，
也可以推测出 IPoE 的 1500 MTU 会被认为是 IDC ，低于 1440 会被认为是代理，所以被疯狂风控。

解决方法很简单，先在光猫用 1480 的 MTU ，也可以用 iptables 处理，
但是经过群友尝试，iptables 规则并不能完全覆盖这些探测包，
比如某厂 APP 是在业务的 TCP 长连接发送大包探测。

有没有更合适的方法来规避这些探测呢？
以及，联通的 VNE9000 是哪个厂商的 vBRAS 呢？

[piku]

几天前的下午 1 点多，我这联通做了一次割接，但是没发现割接完后有什么变化（私有傻瓜桥接猫，路由器 PPPoE ）。但是老设备下只剩我一个用户了。
想当年全省加 ipv6 时就把我漏了。。。

[piku]

@llinge 我自己是在路由器上用一个 ip list 记录 PPPoE 口 ip

[piku]

还有就是我家里两台笔记本（并排放，网络环境一样），其中一台在淘宝时频繁被要求滑动验证，另一台就很少被要求滑动验证。

[rrfeng]

@billccn 去翻翻 ICMP 协议吧

op 可以把收到的 ICMP 放出来看看，ICMP 报文的 data 是触发这个 ICMP 的原数据包的 IP header 部分。

这种设想不科学也不经济。
要判断 IP 是否 IDC 的，有更简单实用的办法。

[swiftg]

震惊了，原来还可以这样风控，真是无所不用其极

[swiftg]

使用 cloudflare warp 访问阿里系的网站，疯狂弹窗，因为用的 wireguard 隧道，https://browserleaks.com/ip 和 https://www.speedguide.net/analyzer.php 检测 MTU 只有 1420 。不套 warp 的话 MTU 为 1500 就没事

[tavimori]

@billccn 既然现在家宽公网 IP 的并不多，那么多数共享公网 IP 出口的 MTU 都应该可以达到 1500 ，据此，使用 ICMP 主动 ping 来获取 MTU 并判定 IDC 应该不是很合理，不过综合其他指标（比如传输层使用的 MTU ）的话，可能还是有用的。

[pcslide]

对个人用户使用 icmp 探测？？？难道不知道 icmp 默认在网关就直接丢弃了吗？不要以为 ipv6 就不丢 icmp ，照样丢。

[sunnysab]

@swiftg 有没有可能是境外 IP 的缘故？

我家这边还是 PPPoE ，电信公网 IP ，访问阿里系（高德地图网页版、51cto ）经常被弹窗，高德地图弹窗概率 100%，而且他那个弹窗对火狐的兼容性又不好，果断放弃高德。

[oblivion]

@llinge #17 上面只提到了使用 ICMP 发送到你出口公网 IP 这一种方式，实际上还有通过业务通道探测 MTU 的方式，比如在 MQTT 的 TCP 长连接中发送不可分片的大包进行探测。
#19 目前支持 IPoE 认证的设备大都严防死守，各厂家甚至还加了 secure boot 和分区加密，以前的破解方式失效了，也没法把二进制提取出来分析，只能后期再看了。

@2397613259qqq #20 推测 MTU 只是风控参数中的一环，专线这些可能有其他参数。

@dianso #21 既然能收到 ICMP 包，那必然是公网，移动也是公网地址。

@lshero #22 ipv6 体验比较差，最近一直关闭使用的。

@dndx #23 同意，MTU 只是众多风控参数的一环，实际上通过 TCP 探测更有效，比如一个 C 段里面都是 1492 的 MTU ，其中几个 IP 是 1440 ，那必然是通过某些代理访问的，如果一个 C 段都是 1440 的 MTU ，那也不会有问题。所以猜测是割接 IPoE 导致同一个 C 段里面既有 1492 又有 1500 ，触发了风控。
#25 经过群友测试，几个不同的网站都会触发某一地的探测，因此推测是某个第三方风控产品的厂家做的，风控服务 /各种拖动滑动验证码服务 /IPGeo 服务这些。
#37 @lxcopenwrt # 38 @billccn #40 现在反过来想，这个奇淫技巧确实有效，毕竟大部分企业普通宽带，家庭宽带都是 PPPoE 的方式，一但 MTU 变小或者过大，都可能是套代理或者 IDC 爬虫自动请求之类，加上其他一些参数进行风控也算合理，至于企业专线手机上网这些，第三方 IP 地理位置库都有标记，按需加白就可以，剩下只有这些动态 IP 的拨号宽带需要处理了。

@rrfeng #28 发帖的时候写错了，确实是 type 3 code 4 ，而且是我回复的包，与服务器无关。实际是我访问某网站南京的 CDN 节点，几十秒后会有浙江的 IP 连续发包探测，而且这种有规律的 ICMP 包在空闲时段没有，因此是我来回复，与服务器端与中间设备都无关，因为 1500 的包已经正确到达了我公网 IP 。而且已经说明了，这只是最简单的一个例子，而且不一定是唯一风控条件，比如某厂还会在业务 TCP 长连接发大包探测 MTU 。
routeros 日志如下
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1500
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1472
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1440
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1400
proto ICMP (type 0, code 0), 对方 IP->我公网 IP, len 1280

@Untu #29 所以 MTU 不是唯一风控条件，只是其中一个参数。

@tavimori #31 是的，ICMP 的方式只能探测到公网终结点，上面提到的是公网 IP 的情况，联通和移动都是公网 IP 。所以一些厂商还会用 TCP 通道来探测 MTU 。

@pcslide #48 ICMP 只是其中一种最简单的方式，在 TCP 业务通道也可以探测 MTU 。

[cwbsw]

还好吧，MTU 往大了改很难，但往小了改不是很容易。
麻烦的是不能桥接。

[swiftg]

@sunnysab 同样境外 IP ，MTU 1500 的就没有弹窗

[HH8]

@dianso ipv6 卡的一皮

[HH8]

那就好 还以为只有我们这里出问题 原来大家都一样 继续 67673 塔学

[Terminl]

就是 IP 的问题和 MTU 没什么关系

[bukusishen777]

请教大佬，看你以前提到过中兴光猫改桥接的方法。现在 f7607p 也有这个问题，但是按照您提供的方法，有时候也是不生效的，表现为光猫第四个核心基本跑满，都是软中断，然后软路由那边速度就很低了。 不知道有什么命令可以查看硬件转发是否生效。 现在是光猫桥接后，选择透传模式，由软路由处理 vlan 信息。 这样能改善，第四核心占用 15%以下。 按照一般的 vlan 改写的话，第四核心的 cpu 占用率几乎 100%。

[siyanmao]

@oblivion 在 TCP 里发大包还是有点麻烦的，要旁路掉内核的 MSS 控制和网卡的 TSO ，得魔改内核和应用层，没法过 CDN 。估计只能用在 IoT 或者推送之类的应用上。不过检测 MTU 只能检测出 L2/L3 的 VPN ，遇到 Shadowsocks 这样的 L4 代理就没办法了。

对于 ICMP 响应，看来他们的逻辑是越符合 RFC 越有问题。这倒是也有道理。运营商 CGN 、一般的 NAT 网关很可能不会响应 ICMP ，而很多 Linux 服务器不太会屏蔽掉 ICMP 。我感觉以后默认的 iptables 得屏蔽掉太大的 ICMP Echo Request 。

[zhhww57]

@oblivion 这里说一下，不仅是 icmp 有 mtu ，udp ，tcp 也有 mtu ，也许可以通过和客户端建立连接，然后发送不同分片的包，探测内网 mtu 情况，可能这些 idc 不是用 icmp ，前面 icmp 只是尝试，可能用了 tcp 或者 udp ？