近期宽带大面积改造 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 呢？

[mzliangjianjun]

哪里大面积改造
广东电信坐等

[dndx]

这种风控措施都能被你发现，厉害了。

NE 应该是菊花厂的设备，NetEngine

[dndx]

> 有没有更合适的方法来规避这些探测呢？

MSS clamping 到 1452 有用吗？猜测这种探测包也得有个触发条件，如果每个 TCP 都检查代价太高。也许是先看 TCP SYN 包，MSS 太高怀疑的再二次触发主动探测验证。

[lshero]

不同操作系统还有接入方式的 MTU 值本来就不一样，风控想获取客户端的 MTU 做参数会不会很麻烦？

按照国内厂商的尿性你应该先看看是不是换了认证方式后分配的 IP 是新启用的 IP 段不在传统家庭宽带的 IP 段内导致被风控拦截

[msdurex]

楼主是不是不太懂网络？ PPPoE 的 8 bit PPP 包头，给到对方还是 1500 bit 。你说的是移动给你做了 NAT4 吧。

[songofsaya]

改 IPoe 之后有什么坏处吗？比如说公网没了，监控更加方便？更方便运营商恶心用户？

[wwbfred]

@msdurex 实践是检验真理的唯一标准。如果你觉得 LZ 的结论不对，要么反驳他的实验设计有问题，要么反驳他对实验结果的理解有问题。
实际上访问某个网站收到主机发来的 ICMP 报文就是很不正常，而且很多家宽 IP 都是不回复 ICMP 报文的。如果此事确实发生，那么我们有理由怀疑他们用 ICMP 的回复结果做了某些策略。

[ericbize]

@mzliangjianjun 广东电信的 iptv 已经改造了

[KoMAsS121]

@songofsaya 不清楚，不过日本那边家宽运营商据说不都是这玩意。

[huaes]

也可能是启用新 IP 段了，前段时间问 CN2 线路运营商就说家宽和 IDC 的 IP 就是互相挪用的

[zmcity]

只能说明大厂的风控策略都是垃圾。

[ilovey482i]

应用层能取到 MTU ？

[levenwindy]

上个礼拜五前，粤北联通宽带，tp 路由器拨号成功后，windows, Android 端的 ipv6 异常，完全连不上，会导致部分应用加载不出图片。
Linux 端则没问题。路由器没 MSS clamping 功能，换软路由立即正常。
故障了将近两个月，上礼拜六故障消失。不清楚是不是同一个问题？

[aru]

基本是新 IP 段导致的吧
探测 MTU 不大可能

[oblivion]

@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 理论上只要想探测，方法有很多种。

[levenwindy]

接 13 楼，联通宽带，有公网 ip ，王者农药 用 qq 密码登录，会显示异常登录失败，多个不同 ip 段均有问题。电信宽带正常
上礼拜六后，一切正常。

[llinge]

@oblivion 这个 ICMP 是发给家里的路由器还是“顺着已建立的 TCP/UDP”发送到手机呢?

[llinge]

@oblivion #15 请教 ddns 历史记录再哪里能查到呢,
我是自己弄的脚本发现 ip 变了或者超过一定时间就用 wget 去更新一下.

[llinge]

@oblivion #15 按说只要大范围推广后, 这个 IPoE 所用的 dhcp 某个加密字段的算法肯定会被搞出来, 到时候依然能桥接.

[2397613259qqq]

日常用 1500 mtu 的互联网专线用户路过，上海和苏州地区，没有遇到过楼主所说的情况。
不过通过 tcp/ip fingerprint 做 idc 判断，在 pppoe 普及的中国确实是一个好办法。