【探讨】Cloudflare 对某些接入点施加了并发限制？

[1-1-2]

引言

Hey guys, 在近期的IP优选测试中，我发现 cloudflare 的一些网段似乎新增了一个访问速率的限制，现描述如下，供测试探讨。

关于接入点，这里我挑选了两个比较有代表性的网段A 172.64.0.0/13 和B 103.31.4.0/22 中的两个随机IP作为测试标靶，域名直接选择了 cf 自身某服务作为受害者（这里在测试中可以替换成你自己的URL）。

在二次测试中，还加入了C 162.158.0.0/15，也测出了一样的结果。

重现及可能的结果

基准（正常情况）

curl --max-time 4 --resolve "speed.cloudflare.com:443:172.67.174.208" --resolve "speed.cloudflare.com:80:172.67.174.208" https://speed.cloudflare.com --write-out "A$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null
curl --max-time 4 --resolve "speed.cloudflare.com:443:104.16.166.17" --resolve "speed.cloudflare.com:80:104.16.166.17" https://speed.cloudflare.com --write-out "B$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null

此时正常返回 Code 200.

A       |  [200] 0.244330s
B       |  [200] 0.520345s

一阶测试——小压力脚本“鼠标连点器”

这里我们模拟一个小爆发性并发访问，后接一个间隙（这个很重要，服务器有反应时间），再发起二次访问

#!/bin/bash
 
for((i=1;i<=8;i++)); do
curl --max-time 4 --resolve "speed.cloudflare.com:443:172.67.174.208" --resolve "speed.cloudflare.com:80:172.67.174.208" https://speed.cloudflare.com --write-out "A$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null &
curl --max-time 4 --resolve "speed.cloudflare.com:443:104.16.166.17" --resolve "speed.cloudflare.com:80:104.16.166.17" https://speed.cloudflare.com --write-out "B$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null &
done

sleep 5 && echo [sleep well i feeling good buddy]

for((i=1;i<=3;i++)); do
curl --max-time 4 --resolve "speed.cloudflare.com:443:172.67.174.208" --resolve "speed.cloudflare.com:80:172.67.174.208" https://speed.cloudflare.com --write-out "A$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null &
curl --max-time 4 --resolve "speed.cloudflare.com:443:104.16.166.17" --resolve "speed.cloudflare.com:80:104.16.166.17" https://speed.cloudflare.com --write-out "B$i\t|  [%{http_code}] %{time_total}s\n" --silent -o /dev/null &
done

curl --max-time 4 --resolve "speed.cloudflare.com:443:104.17.166.18" --resolve "speed.cloudflare.com:80:104.17.166.18" https://speed.cloudflare.com -v

执行后我观察到以下输出

A6      |  [200] 0.524630s
B2      |  [200] 0.539266s
A1      |  [200] 0.547740s
B1      |  [200] 0.554521s
A2      |  [200] 0.556001s
B5      |  [200] 0.544360s
A3      |  [200] 0.553001s
B3      |  [200] 0.553504s
B8      |  [200] 0.542134s
A5      |  [200] 0.555027s
B4      |  [200] 0.557301s
A8      |  [200] 0.557039s
B6      |  [200] 0.560634s
A7      |  [200] 0.563932s
B7      |  [200] 0.563680s
A4      |  [200] 0.577440s
[sleep well i feeling good buddy]
* Added speed.cloudflare.com:443:104.17.166.18 to DNS cache
* Added speed.cloudflare.com:80:104.17.166.18 to DNS cache
* Hostname speed.cloudflare.com was found in DNS cache
*   Trying 104.17.166.18:443...
* TCP_NODELAY set
A2      |  [200] 0.786743s
A3      |  [200] 0.786725s
A1      |  [200] 0.803739s
B1      |  [000] 4.001142s
B2      |  [000] 4.000895s
B3      |  [000] 4.001490s
* Connection timed out after 4000 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 4000 milliseconds

可以观察到：

1. B网段直接把我给 Ban 了，但此时还能ping通

   ping 104.16.166.17 -> 来自 104.16.166.17 的回复: 字节=32 时间=260ms TTL=55

2. 在后续测试中，我加入了C网段 162.158.0.0/15 IP 162.159.131.188，进行ABC同步测试，测结果A[200]，BC[000]

3. B和C的Ban机效果是连带累加的，也就是如果你把B惹毛了，C也不鸟你了，反之亦然

第二阶段

1. 一阶结束后约2mins，轻轻摸一下 CF

   curl --max-time 4 --resolve "speed.cloudflare.com:443:162.159.131.188" --resolve "speed.cloudflare.com:80:162.159.131.188" https://speed.cloudflare.com -v

   正常返回 Code 200，缓过劲儿来了

2. 再打开“鼠标连点器”发起挑战，CF会第二次把你Ban掉，此时 ICMP 都给你搞没了，ping都不通了。
   ping 104.16.166.17 -> 请求超时。
   虽然如此，别的 IP 的 ICMP 依旧“忠诚”，只是不响应 TCP 了。
   ping 104.16.166.18 -> 来自 104.16.166.18 的回复: 字节=32 时间=260ms TTL=55

3. 三阶我就没敢测试了，感觉已经够了。

总结

1. Cloudflare 部分接入点出现了不同于往常的单IP并发速率限制，猜测是过于激进的防 DDos 策略？
2. 在我的测试钟，Ban机时间大致在5mins内，我没有掐表，可能也就1~2min(s)。
3. 第一次 Ban，还能ping通，然后CF会把你放出来。多摸几次，ICMP都没得了。

补充

有好奇的网友就要问了：“是不是你curl特征太明显了？”

嘶，我还真想过，做了补充测试。

我手上正好有一个域名的默认CF接入点是B网段的，为了以示区分那么叫他β站吧，同时称该接入点IP为b（也即β站@b, d∈B）。流程如下：

1. 使用 Edge 正常访问 β站主页，然后关掉标签页，保留窗口。
2. “鼠标连点器”，改B段IP为b，运行搞起——Ban了。
3. 重新打开β站，访问几个子页——正常。（噢，你看还不是你curl特征太明显了哈哈哈哈哈）
4. 打开同于名下一个大文件下崽载链接，Edge 调起 IDM 下载——连接超时。
5. 关闭 IDM 联动，打开同一下崽链接，Edge内发起下载——正常下载。（嘶，你看...）
6. ctrl + shift + N，启动无痕窗口，访问β站——连接超时（。。。）

个人小结：

1. 关于特征一说，我技术有限，无法证明。
2. 猜测：Ban后，已建立的未结束的 TCP 连接可以继续保持通讯不会被切断，新发起的TCP不再被接收。
3. Ban策略采用的不是上限制，而是限时黑名单制，即便是bye掉了所有TCP，在这段时间内还是不响应你滴。

有图为证：

[trytrytogo]

好专业的测试。

[XUANheng]

前來膜拜········希望是因為下個月有一個極其重要的紀念日所引起的臨時措施

[1-1-2]

猜测是 GFW 会比对 SNI 的 DNS 记录与访问的 IP 值，不对应会触发阻断。