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

近期长三角一代联通和移动又大面积推动了一次 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 呢？

dndx

2023-04-26 19:48:30 +08:00

@ilovey482i 别说 MSS ，就连 3 层信息比如 TTL 都可以。Cloudflare 展示过一种用 eBPF 获取的方法： https://blog.cloudflare.com/epbf_sockets_hop_distance/
@2397613259qqq 我也想过这个问题，包括手机的流量 MTU 一般也是 1500 的，猜测 MTU 也不是唯一的判断条件，可能只有可疑的 IP 段（比如家宽，IDC ，云主机商）才会 challenge ，毕竟一般爬虫也不用手机流量来做代理。

rrfeng

2023-04-26 20:23:23 +08:00

ICMP type 4 source quench 根本没有 code 。

我怀疑你看反了，是
type 3：
Destination unreachable

code 4：
Fragmentation is needed and Don't Fragment was set

这是个正常的 ICMP 通告因为你的 MTU 太大了中间设备或者目的服务无法处理。

家宽 MTU 升级出现这个现象是有可能的。
但是服务提供方不可能根据这个做风控，这个都不一定是服务端发回来的，可能是任意一个中间设备。
而且客户端（家宽）收到这个报文也不会产生什么回复。
客户端实现了 PMTU 的话，会调小 MTU 重新建链尝试。

多看书。

datocp

2023-04-27 04:55:48 +08:00

之前的文档说 mtu 是个严重影响网络呑吐的参数，表现为封包重组很多页面难以打开。实际上在 tplink 那种固件，根据网络上的文档根本无法针对不同类型的网站设定 mtu 。记得当年看到的讨论 pppoe 设置的是 1454 实际上在一些洋路由器上根本不能设，vpn 链路都小到 1196 了。

Openwrt 在近两年才变成双向解决，感觉自己的网络从来没因为 mtu 出过问题。

-A FORWARD -o pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

billccn

2023-04-27 06:21:13 +08:00

@rrfeng 看个 TTL 就知道 ICMP 回报是用户设备还是中间设备发来的。trace route 就是通过这个原理实现的。

楼主把整个原理说的很清楚，都是可行的，而且做了实验验证。

@yulihao 楼主已经描述过了，这个风控是因为 IPoE 割接，MTU 发生了变化才触发的。同时这个 IP 池内还有混合 1500 和小于 1500 。正常的宿舍、政企宽带是不会产生两种 MTU 的。

@tavimori 楼主既然抓到了大厂发来的 ICMP 包那明显是公网 IP

@lxcopenwrt 不一定是根据数值直接判断，可能是检测 IP 段里 MTU 发生了变化。因为运营商也没有义务无偿提供 IP 地址分配的数据库，大厂肯定都是买来或者收集来的，这个数据会过期，所以肯定会有一个动态跟新的过程。比如一个网段一直是 1400 的包，那就标记为手机。现在一个本来标记是家宽的段突然出现不同的 MTU 那确实应该触发，因为不是这个段换到了 IDC 就是个别用户在套 VPN 。