换个角度解释 解决workers.dev被墙的各种方案
对于workers.dev被墙的问题, 现在网上流传了好几个不同的解决方案.
我之前写了一篇 在自己的域名下 设置路由 指向 Cloudflare worker
在网上你可以看到添加CNAME解析的, 你还可以看到我用Cloudflare优选IP根本不添加解析的, 现在还冒出来用Cloudflare Pages的(这样就不需要自己有个域名了) ...
很多人不理解这些方案中的一些"骚操作".
希望此文能从另一个角度向你解释这些方案的原理.
前提条件
需要你了解 连接 V2Ray Websocket + TLS 模式的过程
不清楚的话, 请仔细阅读上面的链接
我把V2Ray客户端的设置参数界面对照图搬出来
(箭头指向的是同一个参数, 以下行文过程中会带上编号方便读者明白我说的是哪个参数)
workers.dev被墙的原理
你的翻墙客户端发出的数据包, 需要经过GFW的"过滤"(审查)才能达到你的梯子/VPS.
GFW会检查数据包的SNI, 对应客户端节点参数的域名host(5)
如果GFW发现SNI满足 *.workers.dev 的匹配规则, 就将此数据包丢弃(或者做其它干扰操作).
解决workers.dev被墙的原理
解决问题的原理, 就是要想办法让我们发出的数据包里的SNI 不是 *.workers.dev
你会发现不管用什么方案, 最终让你修改V2Ray客户端的节点参数, 域名host(5)都被改掉了, 不再是*.workers.dev
具体实现
以借路Cloudflare的CDN网络的方案来说，
1. 你的翻墙客户端要将数据包发送到CDN网络
可以采用以下实现之一:
* 这也正是各种解决方案千奇百怪的地方。
a. V2Ray客户端的节点参数 地址Address(1) 填CF优选IP
如：141.101.122.236b. 地址Address(1) 填某域名，在你本地的hosts文件里设置解析为CF优选IP
如：141.101.122.236 wkr.ciys.cfc. 在Cloudflare的DNS设置里，将某域名设置解析为CF优选IP
如：wkr.ciys.cf 解析为 141.101.122.236d. '第三方'提供的可以当优选IP用的某个域名
如：icook.hk* 实质上是'第三方'设置了将这个域名解析为CDN网络的某个服务器的IP
e. 在Cloudflare的DNS设置里，将某域名设置打开CDN
* 此时，该域名的DNS解析什么IP不重要；是CNAME项 还是A项 AAAA项 都不重要。因为打开了CDN，这个域名就会解析为CDN网络的某个服务器的IP
2. CDN网络根据收到的数据包的SNI参数决定如何处理
以 域名host(5)参数为 wkr.ciys.cf 为例
CDN网络根据设置好的路由 wkr.ciys.cf/* 将数据包转发给某worker处理 (如: hrk.ciys.workers.dev)
3. worker收到了数据包，根据配置好的脚本处理
以如下脚本为例:
意思是说把数据包转发给 ball-speed.herokuapp.com
4. 目标域名(你的梯子)收到了数据包
整条数据流成功走通了。
如果是用Cloud Pages的解决方案
第1步是一样的
2. CDN网络根据收到的数据包的SNI参数决定如何处理
域名host(5)参数 是xxx.pages.dev
CDN网络转给对应的 Page 处理
后面的步骤也差不多一样的
================
后记
为什么添加的路由是 wkr.ciys.cf/* 而不是 wkr.ciys.cf ？
因为配置了websocket的path的梯子，你的客户端节点信息里是填了 路径path(6) 的。CDN网络收到的数据包声明"我的目的地是wkr.ciys.cf/somepath"
wkr.ciys.cf/somepath 这个目的地可以匹配 wkr.ciys.cf/* 而不能匹配 wkr.ciys.cf。也就是说如果你没有配置路由为wkr.ciys.cf/* 的话，CDN网络无法将此数据包送往worker。数据流走到这一步就断了。
评论
发表评论