什么是 Eagle Tunnel(ET)

简单来说,这就是个代理工具。起初,ET(Github Repo)是一个HTTP代理协议的简单实现。但经过结构的演变,现在它的确更符合隧道这个名字。在生活学习工作中,我们时不时会用到各种网络代理协议,ET 想要做到的,是一个透明的隧道,Web客户端在左边,Web服务器在右边。

tunnel

在计划里,ET 将可以接收各种代理协议(目前仅仅支持SOCKS5 和 HTTP(s)),过滤成统一的 ET 协议格式,再进行加密的流量转发。

arch

ET 已经处于可用状态,虽然它还在迭代中。它的目标是,简单部署,稳定工作,轻量占用。

我为什么开发ET

由于未知的神秘力量,国内总有很多网站打不开。因此和很多人一样,我被迫开始使用代理工具。不过从去年下半年开始,常用的工具都开始变得不稳定,这当然不怪工具本身,但我不得不因为网络环境的恶化不停为工具启用各种加密协议和混淆插件。 随着一个个VPS被封掉IP,代理工具的效率却与协议的安全性成反比——安全系数越高,由于加密和混淆的存在,效率越低。

事实上,目前的绝大多数网站,本身就自带最安全的SSL加密,那么我们在外面再额外套一层加密,意义又能有多大呢?代理大致可以分为两类——使用长连接的和使用短连接的。长连接意味着复杂的协议,以及较高的带宽损失。而对于短连接类而言,我们所需要保护的,仅仅是代理协议握手时的报文而已,从尺寸上来讲,通常连1KB都不到,我们有必要为了这区区1KB搞一套复杂的加密和混淆吗?要知道这并不是没有代价的,除了更高的延迟之外,额外的SSL握手,在网络不够通畅的情况下,很可能会导致连接失败。因此我试着开发了ET,由于几乎没人使用,它的协议非常安全,我几乎没有给流量做任何有质量的额外加密,但这并不妨碍它的稳定工作,同时,这带来了CPU资源的节约(如下图)。当然,从代码结构或者通信协议上来讲,如果将来有需要,给它增添额外的加密外壳是很容易的。

cpu_screenshot

如果 ET 开始有人使用

现在我们有一个新的问题,万一将来有一天,使用ET的人变多,ET的协议被更加恶化的网络环境吃掉怎么办?

ET还没资格遇到这样的挑战,不过想当然地预测一下,也许有一个更简单的解决方案——我们调整协议就行了。这并不是一件不可接受的事情,对于使用短连接的ET来说,调整协议的损失相当低。就目前的ET架构而言,ET的程序分为两个部分——提供核心功能的内核,以及提供用户界面的外壳。理想情况下,外壳与内核会保持相对解耦,也就是说,为了对抗日益恶化的网络环境,ET有可能会更新内核的通信协议,而这对用户的外在体验没有丝毫影响。换句话说,用户所要做的,就是简单地选择协议版本,只要服务端与客户端的协议版本号一致,ET就可以正常工作。网络环境的危险毕竟是有限的,而协议版本的可能性是无限的。极端一点,ET甚至可以开放协议定义的接口,由用户自定义自己的握手协议。

我也看到有人在讨论,神秘力量启用了AI,可以智能识别流量特征,因此哪怕给SS装备上RSA,仍然会被精准识别。但我的亲身体验告诉我,目前对SS的识别是相当精准的,VPS往往刚刚上线SS便被ban掉,如果不启用SS服务,启用的是自建协议的ET,却可以长期(目前已经半年)稳定使用。这说明即便AI存在,也是与SS的协议耦合的。网络上提到的论文《The Random Forest based Detection of Shadowsock’s Traffic》我也大致浏览了一遍,如果理解没出偏差,其生效的前提也得是代理的客户端与服务端同时处于控制之下。不过既然都在控制里了……

以上都是我的YY,因为ET用户太少了,所以这是否真能解决问题,我也不知道。不过目前作为小众产品,它还挺好使的 : )。


2018年10月更新

虽然ET的用户仍然很少,但很奇怪的,它似乎第一次遇到了考验。某天我的VPS突然无法访问(从另一个VPS却可以),这是一年来首次的遭遇。我在第一时间添加了自定义协议头的特性——其实架构上一直都支持,只是之前未在配置文件控制器里开放而已。一个星期以来,效果似乎不错,但也许还需要更多的时间,才能验证这个策略的有效性。当然,仅仅自定义协议头的预防能力并不强,协议特征仍然非常明显。但我已经有了完善的构思——有效但工作量较大。如果有必要,我会在将来实施它。

发表评论

电子邮件地址不会被公开。 必填项已用*标注