近期宽带大面积改造 IPoE 后遇到的频繁提示网络环境异常频繁弹出验证码的问题推测及临时解决方法
oblivion · 2023-04-26 14:43:34 +08:00 · 6860 次点击这是一个创建于 601 天前的主题，其中的信息可能已经有所发展或是发生改变。
近期长三角一代联通和移动又大面积推动了一次 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 呢？
很多群里的小伙伴发现一夜之间自己的光猫被推送了路由模式并且已经变为 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 呢？
 |
1
mzliangjianjun 2023-04-26 15:00:10 +08:00 via Android
哪里大面积改造
广东电信坐等 |
 |
2
dndx 2023-04-26 15:04:15 +08:00  2
这种风控措施都能被你发现，厉害了。
NE 应该是菊花厂的设备，NetEngine |
|
3
dndx 2023-04-26 15:16:42 +08:00
> 有没有更合适的方法来规避这些探测呢？
MSS clamping 到 1452 有用吗？猜测这种探测包也得有个触发条件，如果每个 TCP 都检查代价太高。也许是先看 TCP SYN 包，MSS 太高怀疑的再二次触发主动探测验证。 |
 |
4
lshero 2023-04-26 15:19:11 +08:00
不同操作系统还有接入方式的 MTU 值本来就不一样，风控想获取客户端的 MTU 做参数会不会很麻烦？
按照国内厂商的尿性你应该先看看是不是换了认证方式后分配的 IP 是新启用的 IP 段不在传统家庭宽带的 IP 段内导致被风控拦截 |
 |
5
msdurex 2023-04-26 15:42:00 +08:00 via iPhone
楼主是不是不太懂网络？ PPPoE 的 8 bit PPP 包头，给到对方还是 1500 bit 。你说的是移动给你做了 NAT4 吧。
|
 |
6
songofsaya 2023-04-26 15:42:55 +08:00
改 IPoe 之后有什么坏处吗？比如说公网没了，监控更加方便？更方便运营商恶心用户？
|
 |
7
wwbfred 2023-04-26 16:17:53 +08:00 8
@msdurex 实践是检验真理的唯一标准。如果你觉得 LZ 的结论不对，要么反驳他的实验设计有问题，要么反驳他对实验结果的理解有问题。
实际上访问某个网站收到主机发来的 ICMP 报文就是很不正常，而且很多家宽 IP 都是不回复 ICMP 报文的。如果此事确实发生，那么我们有理由怀疑他们用 ICMP 的回复结果做了某些策略。 |
 |
8
ericbize 2023-04-26 16:38:17 +08:00
@mzliangjianjun 广东电信的 iptv 已经改造了
|
 |
9
KoMAsS121 2023-04-26 16:59:56 +08:00
@songofsaya 不清楚，不过日本那边家宽运营商据说不都是这玩意。
|
 |
10
huaes 2023-04-26 17:06:44 +08:00
也可能是启用新 IP 段了，前段时间问 CN2 线路运营商就说家宽和 IDC 的 IP 就是互相挪用的
|
 |
11
zmcity 2023-04-26 17:31:46 +08:00 2
只能说明大厂的风控策略都是垃圾。
|
 |
12
ilovey482i 2023-04-26 17:34:59 +08:00
应用层能取到 MTU ？
|
 |
13
levenwindy 2023-04-26 17:48:04 +08:00 via Android
上个礼拜五前，粤北联通宽带，tp 路由器拨号成功后，windows, Android 端的 ipv6 异常，完全连不上，会导致部分应用加载不出图片。
Linux 端则没问题。路由器没 MSS clamping 功能，换软路由立即正常。 故障了将近两个月，上礼拜六故障消失。不清楚是不是同一个问题？ |
 |
14
aru 2023-04-26 17:53:37 +08:00
基本是新 IP 段导致的吧
探测 MTU 不大可能 |
 |
15
oblivion OP @dndx #3 是会有一些触发条件的，不是必现，需要静置一段时间，再访问这些网站 /APP ，大约 15 秒的样子会有 ICMP 过来，后续访问都很少会有，也许是没有抓到包，访问的南京 CDN 节点，会有杭州的 IP 发送 ICMP 。
@lshero #4 @huaes #10 IP 段的问题考虑过，某位群友投诉运营商回退了 PPPoE 后，IPoE 和 PPPoE 都在同一个 C 段，也有通过 DDNS 历史记录交叉比对，IP 段没有太大变化，是固定几个段。 @msdurex #8 包含 PPPoE 的 8 字节包头 1500 字节包只会止步于 BRAS ，自 BRAS 出口至对方 IP 是剥离了 8 字节包头的 1492 字节包 @songofsaya #6 暂时只有一个不能改桥接的缺点，其他公网 IPv4 该有的都有，原来没有的现在也没有 @wwbfred ICMP 是异步的随机地区发来的，推断是某种后台风控触发的，以前 1492MTU 这些包到达运营商 BRAS 就会被丢弃或者回复 too big ，现在 1500MTU 恰好可以到达用户端设备。 根据多个小伙伴的观察，这些探测不只有 ICMP ，还有某些 APP 用业务长连接发送大包的方式，一些视频网站会用 websocket 探测等等。 @ilovey482i #12 理论上只要想探测，方法有很多种。 |
|
16
levenwindy 2023-04-26 18:15:56 +08:00 via Android
接 13 楼，联通宽带，有公网 ip ，王者农药 用 qq 密码登录，会显示异常登录失败，多个不同 ip 段均有问题。电信宽带正常
上礼拜六后，一切正常。 |
 |
18
llinge 2023-04-26 18:22:37 +08:00
@oblivion #15 请教 ddns 历史记录再哪里能查到呢,
我是自己弄的脚本发现 ip 变了或者超过一定时间就用 wget 去更新一下. |
|
19
llinge 2023-04-26 18:27:09 +08:00
@oblivion #15 按说只要大范围推广后, 这个 IPoE 所用的 dhcp 某个加密字段的算法肯定会被搞出来, 到时候依然能桥接.
|
 |
20
2397613259qqq 2023-04-26 18:41:02 +08:00
日常用 1500 mtu 的互联网专线用户路过，上海和苏州地区，没有遇到过楼主所说的情况。
不过通过 tcp/ip fingerprint 做 idc 判断，在 pppoe 普及的中国确实是一个好办法。 |
 |
21
dianso 2023-04-26 19:01:31 +08:00
乱说，明明是 nat4
|
|
23
dndx 2023-04-26 19:48:30 +08:00 via iPhone 1
@ilovey482i 别说 MSS ，就连 3 层信息比如 TTL 都可以。Cloudflare 展示过一种用 eBPF 获取的方法： https://blog.cloudflare.com/epbf_sockets_hop_distance/
@2397613259qqq 我也想过这个问题，包括手机的流量 MTU 一般也是 1500 的，猜测 MTU 也不是唯一的判断条件，可能只有可疑的 IP 段（比如家宽，IDC ，云主机商）才会 challenge ，毕竟一般爬虫也不用手机流量来做代理。 |
 |
24
eudemonwind 2023-04-26 19:52:24 +08:00
哎, 上个网越来越难, 总烂尾尸干脆把互联网团灭了算求, 凭职位上网, 科级以上干部可以装宽带, 处级以上可以用手机... 何必搞这么弯弯绕绕恶心人.
|
|
25
dndx 2023-04-26 19:54:16 +08:00 via iPhone
就是这种主动探测手段，咋感觉跟某设备很像呢。
|
 |
26
Laynooor 2023-04-26 20:08:34 +08:00 via Android
|
 |
27
rrfeng 2023-04-26 20:13:04 +08:00 via Android
我在大厂，没听说过这种风控机制。
|
|
28
rrfeng 2023-04-26 20:23:23 +08:00 via Android
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 重新建链尝试。 多看书。 |
 |
29
Untu 2023-04-26 20:32:50 +08:00 via Android
有很多专线用户的，党政机关，大中小型企业，要按照 mtu 风控他们不早跳起来了，他们的数量也非常大
|
 |
30
yulihao 2023-04-26 20:47:37 +08:00
我个人更加倾向于新的 IP 段可能原来属于 IDC 的这个说法
宿舍宽带是 DHCP 拿的静态公网 IP （ IPIP 提示家宽段），没有遇到过要验证什么的。 |
 |
31
tavimori 2023-04-26 21:20:00 +08:00
即使是 PPPoE 上网，如果没用公网 IP 的话，服务端通过 ICMP 探测也只能探测到公网出口 IP 所在的设备位置，到该位置的 MTU 应该还不涉及 PPPoE ，所以仍然有 1500 的 MTU 吧？
|
 |
32
sleeppingblue 2023-04-26 21:29:54 +08:00
河北电信，公网 v4+v6 ，没有任何问题啊
|
 |
33
yyzh 2023-04-26 21:31:36 +08:00 via Android
@Laynooor 这个是不是从服务器反过来 ping 客户端测出来的 MTU?我 nat 大内网但是上面显示 mtu 是 1500
|
 |
34
Xusually 2023-04-26 21:45:34 +08:00
前些日子不是有帖子引起争论了么，说的就是国内还用 ADSL 就是垃圾，IPoE 才是潮流，再看 OP 这个帖子。。。。。。
|
|
35
2397613259qqq 2023-04-26 22:04:29 +08:00
@dndx 不好说，之前我有试过我的联通卡流量，mtu 值大小都是 ipsec 之类隧道的值
|
 |
36
Mimei 2023-04-26 22:15:08 +08:00
厉害了，学习
|
|
37
dndx 2023-04-26 22:19:21 +08:00
@Xusually IPoE 的确是未来，这个问题明显跟 IPoE 也没什么关系，要怪也只能怪这些大厂基于家宽都是 PPPoE 的假设搞出来的奇技淫巧。
|
 |
38
lxcopenwrt 2023-04-26 23:08:13 +08:00
不知道那些说手机流量 MTU 是 1500 的结论是怎么来的，反正广东移动、联通的手机流量 MTU 都不是 1500 ，移动是 1420 联通是 1400 ，不过楼主说的结论也确实不成立这些 MTU 值应该都被判定为代理但实际没有
|
 |
39
datocp 2023-04-27 04:55:48 +08:00 via Android
之前的文档说 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 |
 |
40
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 。 |
 |
41
piku 2023-04-27 07:18:04 +08:00 via Android
几天前的下午 1 点多，我这联通做了一次割接，但是没发现割接完后有什么变化（私有傻瓜桥接猫，路由器 PPPoE ）。但是老设备下只剩我一个用户了。
想当年全省加 ipv6 时就把我漏了。。。 |
|
43
piku 2023-04-27 07:24:24 +08:00 via Android
还有就是我家里两台笔记本（并排放，网络环境一样），其中一台在淘宝时频繁被要求滑动验证，另一台就很少被要求滑动验证。
|
|
44
rrfeng 2023-04-27 09:01:18 +08:00 via Android
@billccn 去翻翻 ICMP 协议吧
op 可以把收到的 ICMP 放出来看看，ICMP 报文的 data 是触发这个 ICMP 的原数据包的 IP header 部分。 这种设想不科学也不经济。 要判断 IP 是否 IDC 的，有更简单实用的办法。 |
 |
45
swiftg 2023-04-27 11:48:55 +08:00
震惊了，原来还可以这样风控，真是无所不用其极
|
|
46
swiftg 2023-04-27 12:05:11 +08:00
使用 cloudflare warp 访问阿里系的网站，疯狂弹窗，因为用的 wireguard 隧道，https://browserleaks.com/ip 和 https://www.speedguide.net/analyzer.php 检测 MTU 只有 1420 。不套 warp 的话 MTU 为 1500 就没事
|
|
47
tavimori 2023-04-27 12:46:28 +08:00
@billccn 既然现在家宽公网 IP 的并不多，那么多数共享公网 IP 出口的 MTU 都应该可以达到 1500 ，据此，使用 ICMP 主动 ping 来获取 MTU 并判定 IDC 应该不是很合理，不过综合其他指标（比如传输层使用的 MTU ）的话，可能还是有用的。
|
 |
48
pcslide 2023-04-27 19:37:26 +08:00
对个人用户使用 icmp 探测？？？难道不知道 icmp 默认在网关就直接丢弃了吗？不要以为 ipv6 就不丢 icmp ，照样丢。
|
 |
49
sunnysab 2023-04-28 07:16:54 +08:00 via Android
@swiftg 有没有可能是境外 IP 的缘故？
我家这边还是 PPPoE ，电信公网 IP ，访问阿里系（高德地图网页版、51cto ）经常被弹窗，高德地图弹窗概率 100%，而且他那个弹窗对火狐的兼容性又不好，果断放弃高德。 |
|
50
oblivion OP @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 。 |
 |
51
cwbsw 2023-04-28 18:34:45 +08:00
还好吧，MTU 往大了改很难，但往小了改不是很容易。
麻烦的是不能桥接。 |
 |
54
HH8 2023-04-29 00:40:08 +08:00
那就好 还以为只有我们这里出问题 原来大家都一样 继续 67673 塔学
|
 |
55
Terminl 2023-04-30 02:50:51 +08:00
就是 IP 的问题和 MTU 没什么关系
|
 |
56
bukusishen777 2023-04-30 17:27:35 +08:00
请教大佬，看你以前提到过中兴光猫改桥接的方法。现在 f7607p 也有这个问题，但是按照您提供的方法，有时候也是不生效的，表现为光猫第四个核心基本跑满，都是软中断，然后软路由那边速度就很低了。 不知道有什么命令可以查看硬件转发是否生效。 现在是光猫桥接后，选择透传模式，由软路由处理 vlan 信息。 这样能改善，第四核心占用 15%以下。 按照一般的 vlan 改写的话，第四核心的 cpu 占用率几乎 100%。
|
 |
57
siyanmao 2023-05-01 01:33:19 +08:00
@oblivion 在 TCP 里发大包还是有点麻烦的，要旁路掉内核的 MSS 控制和网卡的 TSO ，得魔改内核和应用层，没法过 CDN 。估计只能用在 IoT 或者推送之类的应用上。不过检测 MTU 只能检测出 L2/L3 的 VPN ，遇到 Shadowsocks 这样的 L4 代理就没办法了。
对于 ICMP 响应，看来他们的逻辑是越符合 RFC 越有问题。这倒是也有道理。运营商 CGN 、一般的 NAT 网关很可能不会响应 ICMP ，而很多 Linux 服务器不太会屏蔽掉 ICMP 。我感觉以后默认的 iptables 得屏蔽掉太大的 ICMP Echo Request 。 |
Select Language