关于 CF Worker 搭建节点的一点思考

小时候没什么网络支付账号和银行卡,买不了梯子,科学上网全靠 DPI 规避工具和各种协议的公益亦或是泄漏节点。现在有了自建节点,便不怎么折腾这些了。恰巧最近机场和各种中转有些风波,于是又对免费节点有了些兴趣,于是来整理一些思绪。 现在“非常火”的是基于 Cloudflare Worker 的实现,就绕...
关于 CF Worker 搭建节点的一点思考
关于 CF Worker 搭建节点的一点思考

小时候没什么网络支付账号和银行卡,买不了梯子,科学上网全靠 DPI 规避工具和各种协议的公益亦或是泄漏节点。现在有了自建节点,便不怎么折腾这些了。恰巧最近机场和各种中转有些风波,于是又对免费节点有了些兴趣,于是来整理一些思绪。

现在“非常火”的是基于 Cloudflare Worker 的实现,就绕着这个讲讲吧。

Worker 做了什么?

Worker 是 CF 的一个 Serverless 应用开发平台,用来搭建节点时,就是让它帮我们转发数据。

需要思考的问题是:我们到 Worker 怎么通信Worker 到我们的目标怎么通信

数据传输的方式有许多种,对于访问 Web 或 Worker 主要是 HTTP 和 WebSocket。Worker 访问外部网络的方式没多少,CF 主要提供了两个 API:一个连接 HTTP/WebSocket 的,一个连接裸 TCP 流的。

不同的代理场景

  • 镜像站 / API 代理
    对于上网,最常见的需求是访问网站(使用 HTTP)。我们需要访问什么网站,就让 Worker 原模原样把网站内容搬运过来。我们到 Worker 和 Worker 到目标用一样的方式,浏览器觉得自己在访问 Worker,地址栏显示 Worker 的地址。每访问一次计一次请求。
  • AllInOne / GotoX 模式
    我们要访问的网站有点多,一个页面下还有许许多多的跨域资源,一个 Cloudflare 账号最多塞 100 个 Worker,手动甚至自动部署起来也麻烦。我们自然而然地想到了 Worker 复用的方法:我们和 Worker 通信时带上我们要访问的网站,将其放在 URL 或者请求头里。这就是 AllInOne(其实是 AllInBoom!)镜像站和 GotoX 等软件做的事。
    如果要让浏览器等应用程序使用这种代理,Worker 就成了中间人。在网站数据到达你之前,Worker 已经把它剥离 TLS 了,所以要自签证书套一层 TLS 才能投喂给浏览器等应用程序。此方法是可以代理在 Cloudflare 上的网站的,因为 CF 连接 HTTP/WebSocket 的 API 可以访问 CF 上的资源的。此时浏览器觉得自己在访问目标网站同时知道有中间人,可能会有安全警告和奇奇怪怪的 Bug。
  • 裸 TCP 代理(如 edgetunnel)
    上网需求不仅仅是 HTTP 和 WebSocket,还有各种各样的基于 TCP 的协议,况且中间人攻击比较繁琐且容易出 Bug,还是把裸 TCP 流搬过来好了,这就是 edgetunnel 等项目做的事情。

TCP 代理的实现与限制

具体怎么做呢?TCP 是长连接的,HTTP 请求应答一下就没了,Worker 又是无状态的,下次请求上次的连接是拿不到的(也不绝对,可以用耐用对象等方式)。那只能靠同样长连接的 WebSocket 来携带我们的 TCP 代理数据。

基础模型如下:
我们 <---ws---> Worker <---tcp---> 目标

Cloudflare 网络限制
此时那个著名的限制来了:Worker 不能向 Cloudflare 的网络发起 TCP 连接。为了解决访问托管在 CF 上的网站的问题,衍生出了以下方法:

  1. 利用非 CF 的 CDN 节点:网络上有许多同学的 Reality 节点偷了 CF 网站,成了不是 CF 的 CDN 节点。访问 CF 时,我们访问这些节点,就可以让他们代理一下我们访问 CF 的请求。
  2. 公共 NAT64:专门的 CF 公共反代好像是没有,但公共 NAT64 可以完成这个事情。
  3. 链式代理:我们只是有一个链式代理的需求,不一定要用 proxyip 这种透明代理。境外的免费代理、VPN 一抓一大把。

现在的最终模型是:
我们 <---ws---> Worker <---tcp---> 公共代理 <---该代理支持的协议---> 目标

技术细节

理论上似乎可行了,落实一下具体细节:

  1. Worker 转发实现
    Worker 只要能帮我们用 WebSocket 转发 TCP 即可。
  2. 域名与连接方式
    怎么连接 Worker 呢?买不起域名,Worker 的域名能用吗?
    还真行。虽然 *.workers.dev 有 SNI 阻断和 DNS 污染,但裸 HTTP 或 H3 QUIC 是能用的。CF 目前还没支持 H3 的 WebSocket,那裸奔好了,不过 GFW 就能看到你没有被加密的应用流量了。但如果我们到最终的公共代理流量是加密的,其实也还好。
  3. 本地客户端
    需要写一个本地的代理服务器去调用 Worker。
  4. 测试
    公共代理可以用赛风(Psiphon),改好上游代理,连接一下测试速度。

image

赛风有点慢,换一个VPN试试:

image
测一半断流了,worker 10ms CPU时间就这样吧

源码:
cf-proxy-src.zip (38.5 KB)

Windows平台的编译产物和一些公共代理/VPN的打包:
Cloudflare Pages

2 个帖子 - 2 位参与者

阅读完整话题

来源: linux.do查看原文