真的安全?Cloudflare Worker部署VLESS翻墙代理的原理和proxyIP细节研究

0
16

小U上次分享自建VPN/代理翻墙已经是2017年(连WhatsApp都要翻墙?路由器刷固件架设SoftEther VPN Server翻墙的图文攻略),生活在墙外的我没有翻墙的“刚需”,但是祖国的春风在香港吹啊吹,又吹生了我对VPN翻墙的热情。昨晚花了一晚时间学习了Cloudflare Worker部署VLESS翻墙代理的代码 ,今早顺利根据网上的教程顺利来跑起了VLESS转发代理。如果你对VPN是否安全会有批判性思考,不是免费就9冲,那麽本文和大家分享几个技术细节你很可能感兴趣。

阅读全文: 真的安全?Cloudflare Worker部署VLESS翻墙代理的原理和proxyIP细节研究

摘要节点

Cloudflare Worker + VLESS的原理

Cloudflare Worker上可以运行javascript,作爲一个serverless function,每天有十万个10ms CPU time 的requests可以免费用。z大写的edgetunnel代码可以部署在Cloudflare Worker,爲数据包加添vlessheader信息,达到vless代理转发的目的。

由於Cloudflare在GFW国内某个程度能访问,而CF Worker又能访问GFW以外的信息,所以透过CF Worker来转发的数据理论上就达到了翻墙的效果

详细的部署方法可以参考:

最关键的是下图在Cloudflare上设置的Worker的代码:

最值得深究的小U认爲是proxyIP的这个设定,爲什麽呢?

爲什麽还要proxyIP?安全吗?

代码中有一行神秘的proxyIP设定触动小U Cybersecurity 的神经,网上教程建议设置爲:103.200.112.108。这IP到底是谁?有什麽用?爲什麽需要?既然叫proxy,应该流量就应该是经过这些IP,教程中还要我们关闭加密设置?!这。。。第一反应是用WHOIS查找这些IP的拥有者:

感觉不安。既然是利用Cloudflare的Infrastructure进行转发的VLESS代理,爲什麽还要绕道去第三方的IP做代理??会不会只是GFW墙内的情况所以要设定这个proxyIP?

小U把proxyIP 设置爲空白,果然Cloudflare Worker的页面就死了。唯有按图索骥研究这个proxyIP到底干什麽用的。

关於proxyIP的代码分析

细读z大的代码,发现proxyIP并不是每次转发都会用到,反而是“例外”的情况才会在retry() 函数中调用。那到底是什麽情况呢?z大在代码中其实有备注解释:

// if the cf connect tcp socket have no incoming data, we retry to redirect ip

很抱歉小U的英文能力没能理解,按照上下文,z大把本地socket叫websocket,远端的叫remotesocket或者tcp socket,那可能是远端的tcp socket没有返回数据,就重定向到ip?看代码,ip指的就是proxyIP,那到底是把什麽重定向,那个proxyIP又爲什麽能解决问题?

唯有按图索骥寻找这个proxyIP的资料,功夫不废有心人,小U找到了 cloudflare worker搭建vless | Masheep (piig.top) 作者也有探究这个proxyIP到底是什麽,他说:

一些神奇的ip,可以无条件的转发所有cf流量
如果上面的proxyip用不了了,可以替换成下面这些域名
cdn-all.xn–b6gac.eu.org
cdn.xn–b6gac.eu.org
cdn-b100.xn–b6gac.eu.org
edgetunnel.anycast.eu.org
cdn.anycast.eu.org
另外可以参考这个issues进行proxyip查找
issues:https://github.com/zizifn/edgetunnel/issues/162

这个#162issue帮我指引我到了正确的答案,z大在自己的repo issue中解释到:

由于cf bug,现在cf worker 不能直接访问cf 托管的网站。。所以需要配置一个中转ip。。。而有一些神奇的 ip,可以无条件转发所有 cf 的流量。

z大口中的“神奇的ip”,就是proxyIP。而这个“cf bug”其实是Cloudflare的“有意爲之”,Cloudflare已在网志上说:

Outbound TCP sockets to Cloudflare IP ranges are temporarily blocked, but will be re-enabled shortly.

也就是说CF Worker是不能访问CF自家的IP,是不是很不可思议?而z大的代码就考虑到这一点,如果出现远端TCP不返回数据(例如远端的IP是CF自家的IP),就会触发 retry() 函数,把TCP包再发给proxyIP retry,让proxyIP丢回给CF的目的IP。

验证proxyIP的工作原理

如果proxyIP只是在访问Cloudflare IP时候触发的failsafe,那麽如果一个网站不是Cloudflare host/proxy/edge-caching/namesever等等的话,应该能够正常的访问才对。那什麽网站不会用Cloudflare?自然是Cloudflare的竞争者,例如AWS的Cloudfront。所以上AWS应该不会有任何问题,把proxyIP去掉上AWS果然正常:

Google也有自己一套CDN,不需要经过proxy转发,所以也解释了爲什麽YouTuber测试CF Worker+Vless的看YouTube速度这麽快的原因。

ProxyIP的问题

由於有大量网站都是利用CLOUDFLARE CDN的,导致z大的这套组合拳会经常调用proxyIP。引申的问题有:

安全性问题

z大的vless转发script似乎只有帮数据包套vlessHeader,并不是传统VPN那样上加密。这样的情况把数据转发不知道背後是谁运营的proxyIP放心吗?

速度问题

这些proxyIP能提供的转发速度不是无限的,单个IP也不知道有没有地域优化,导致ping值和速度都受限制

能用多久?

我在网上搜到能用的这种“神奇的ip”就那麽几个,就算撇开安全性,如果没有了这种“神奇的ip”,Cloudflare又不重开Worker访问自家IP的权限的话,那麽这整套所谓“不需VPS 永久免费的Cloudflare VPN“就瞬间崩塌。

瑕不掩瑜:CloudFlare VLESS方案评价

虽然说道了现时的CF VLESS因爲proxyIP有各种问题,但是小U认爲CloudFlare+VLESS依然是现时最容易上手、性能首屈一指的免费翻墙方案。即使proxyIP出了问题,还是能用他能上到一些非Cloudflare的大型的外部网站和APP,进行下一步的翻墙部署,不能不说是极佳的“翻墙起手式”

关於VLESS on Cloudflare,小U还有几个问题想研究/分享的:

如有任何问题或想讨论的,欢迎留言~

surfshark怎么注册

0 0 投票数
Article Rating
订阅评论
提醒
guest
0 Comments
内联反馈
查看所有评论