VPN
💡 VPN(Virtual Private Network),虚拟专用网络,目的是为了联通两个内网,并起到加密作用,并不是为了翻墙而生,但是其流量特征可以被用来翻墙,使用时间较早,因此被民间认为VPN就是翻墙的代名词
VPN数据加密,IPSec OpenVPN——特征明显
但是由于VPN本质是用来合并两个企业的内网的,所以GFW不会直接干掉 当特殊时期、长时间大流量连接就会被中断
和VPS不同的是,VPN是直接将内容经过GFW发到目标VPN服务器,并借由VPN服务器转交真正的意图
优点是相较于代理,本地可以没有客户端直接通过网页进行,以及代理层级较高,可以最大限度地代理系统级应用
缺点是在本地不进行客户端的伪装加密,直接经过GFW告诉GFW本身VPN服务器,GFW服务器对VPN的IP敏感,容易封锁或者是在特殊时期封锁
⚙ 综合来说这种方式已经不再推荐,VPN本身在公司之间作为内网联通的手段应用广泛,且在国家备案。例如学校内部校园网从外部访问的时、知网在校外访问时的VPN线路等。然而作为翻墙来说,流量未经混淆或加密经过GFW就会被记录下VPN的IP地址,这有利于GFW对VPN服务器的活动进行监视。 现在活下来的VPN除了钓鱼型的VPN之外,剩下的VPN要么是手里有着能够和GFW相抗衡的IP数量的境外VPN服务,这种或许质量不错但是收费极其昂贵;或者是套壳机场代理节点的VPN。若是想要稳定的翻墙还是均衡考虑这种方法。
Shadowsocks
💡 不同于VPN,这是一种翻墙而生的协议(虽然作者好像被请去喝茶了,也有同名软件),简称SS,是一种借助于本地客户端对GFW最终解析到的域名请求做出对称加密的方式加密域名请求来逃避GFW的审查,真正实现了既能加密流量,又没有流量特征
1、原理解释
首先在本地客户端(例如v2ray)设置好需要监听的端口
本地客户端将监听的内容使用**对称加密(加密和解密的密钥相同)**的方式对请求的域名(例如:google.com)加密成无序字符串,并配置好VPS的地址和端口 这串被加密过的数据流经过GFW时,因为无法解密加密内容因而无法得知请求的域名内容,只能获取要访问的VPS服务器,所以放行数据
2、优点
不同与使用VPN进行翻墙的方式,此协议转为翻墙而生
双层服务器加解密(本地软件例如v2ray和墙外的VPS服务器)
虽然不如VPN代理的级别高,部分系统级别的应用无法即使开全局也无法代理,但是翻墙比较稳定而且成本极低
对于局域网共享、伪装域名混淆免流等自定义功能的支持比较完善
开放程度较高,各类教程比较完备,可以多样化的阻挡GFW的审查
3、问题
3.1、重放攻击
💡 虽然SS是一个非常好的协议,开创了翻墙的新起点,但是现在使用实际上已经很少了,原因在于GFW可以主动向国外的VPS服务器通过重放攻击进行审查,如果SS的协议设置不够完善,GFW就会发现其运行有SS协议并将VPS的服务器列入黑名单,这样这个节点和这台VPS就基本上废了
本地发送流量:ss将流量加密,在经过GFW的时候,GFW并不知道我们想要访问的域名内容,且SS服务器的IP并不在GFW的黑名单中
GFW或许会认为你可疑,但互联网很大,GFW也不能保证所有自己的数据库没有记载的IP都有问题,所以GFW只能放行
经过GFW:然而数据流是要发送给SS服务器的,所以要配置好SS服务器的IP和端口等内容,且这部分信息经过GFW时能够被GFW所探知
GFW虽然能够获得IP和端口但是无法获得SS加密本地数据的密钥
因此SS服务器对GFW发送的数据包密钥验证不通过并给出错误回执
结果:GFW虽然无法和SS服务器建立有效链接,但是GFW却可以通过这个举动判断SS服务器是否运行了SS协议,从而对SS服务器做出IP封锁
此种攻击方式被称为重放攻击,如果你是SS服务器的持有者,你可以通过命令查看SS协议运行状况,找出不属于自己本地发往SS服务器的IP的失败链接,通过Ping的方式找到该IP的归属地
3.2、预防措施——plugin插件
💡 插件的目的在于伪装流量,将SS协议所代理的流量伪装成一个正常的http或者websocks流量,具体的分类有v2ray plugin等
http协议头:在已经加密好的SS协议前面加上一个http协议头,将任何流量都伪装成一个http数据
GFW处:在这部分http协议头能够被正常看到,但是SS协议部分却仍处于加密状态
VPS部分:加了插件后数据包经由GFW发往plugin插件,而不是直接发送给ss服务器 ,由plugin插件的监听端口,去掉http协议头,把真正的内容还原发往ss节点服务器
但要注意的是并不是所有的客户端都支持plugin插件功能
3.3、混淆等解决方案
近些年来不加插件直接裸奔SS协议就是找死,也可以通过CDN(详见线路节)或者更换SS服务器IP的方式救急,通过AEAD等方式加密比较常用
Vmess
💡 大多数人第一次接触到的结点的协议就是vmess(比如我),vmess协议不仅适配广泛,而且成本低廉,通用于免流。本质上和SS协议类似,都是将请求的数据加密为无序字符串,但是加密过程更加严谨,vmess协议比较依赖系统时间,如果更改系统时间就不能正常使用。
1、加密原理
由加密方式和密钥确定第一次加密,使用时间戳和用户ID声称md5加密头,这是第二次加密
1.1、淘汰原因
因为在短时间之内头部可以重复适用,而且不适用AEAD加密方式,也就是说这个数据包可以被重放攻击
所以要想中间的数据包不被篡改,就需要对中间的数据包采用AEAD加密方式,那么头部的md5随机字符串就舍弃了
经过这种操作后,无法向下兼容,所以从版本v4.28.1之后设置为额外id为0就是AEAD加密方式,不是0就是md5
最终再2022.1.1彻底废弃了md5的加密方式,vmess和ss都是将内容加密为无规则的字符串,只不过更加的严密一点
2、引入TLS
💡 既然单纯的vmess协议存在缺陷,那只要像Trojan一样引入TLS变成http流量就行了
仅仅是建立好一个AEAD加密方式的vmess节点本质上还是一个无规则的字节流
需要和Trojan一样,引入TLS来使得其成为一个正常的https数据流
加密方式:
3、最原始的Vmess(Vmess+TCP)
3.1、Vmess+TCP+TLS
TLS的作用就是,给数据流加上一个http头部伪装成一个正常的http流量
3.2、承载
改为TLS之后,将TLS放在和vmess平级的地方,并由其承担vmess发出的流量,再转给TCP
协议:
TCP:需要先建立连接的一种协议;
ws基于tcp,ws承载vmess,tcp承载ws
3.3、伪装
伪装在vmess前面加上一个http头部,伪装成http流量
但是本身不是由http承载,还是由tcp/udp承载(ws没有伪装)
4、协议嵌套
4.1、Vmess+ws+TLS
Vmess流量给ws,ws流量给tls,tls流量给tcp
4.2、Vmess+TLS+TCP
Vmess的流量由tls承载,tls的流量由tcp承载
这种情况下无法再认证失败后跳转到正常网站来回避GFW审查
4.3、Vmess+ws+TLS+web
因为vmess不能像Trojan一样在认证失败后跳转到一个正常的网页,所以如果这个时候GFW来审查就可能出问题
解决办法就是在原本的vmess+tls+tcp的基础上增加一个正常的网页来作为认证失败的时候的跳转
Tcp不能直接做到,所以要改成ws(客户端和服务器都要改)
和Trojan的不同
而这种方案只有nginx暴露在外面,可以更好隐藏vmess服务器
监听只允许本机,不是0.0.0.0,因为是本机直接对nginx负责
4.4、nginx
如果是tcp协议经过解密后就是vmess的部分,nginx无法解析vmess,只能由ws进行二次封装
Vless
💡 是一种轻量的vmess,vmess还存在二次tls加密的问题,解密需要的时间过长,Vless可以去掉tls的二次加密,速度更快,同时适配的客户端最多,被广泛使用
1、关系
Vless是RPRX开发的协议,但是他作为v2ray的主要开发者之一
之后开发了xtls,刚出来不想被滥用所以在开源中只限于编译(v2ray分家)
后面的人无法基于此进行打包,X说你想打包就打包吧,我只是这么写
后面说x不改就停止对v2ray的支持,x不懂debian/Ubuntu的规则,事先不知道v2已经被打包,x是win用户,对于linux只限于服务器,说大家都是用命令安装的,跟debian的沟通产生误会后解释不清,炸毛了情绪化发言被围攻
V2的另一个主要开发者说愿意修改协议,而这产生分歧,他表示愿意遵循开源协议,提供一个脚本来移除xtls的代码
X先生则是另立门户,基于v2ray发展自己的xtls开发xray,功能和v2ray差不多,但是支持xtls
和Trojan本质都是不对数据进行加密,交给tls进行加密,只是头部没有Trojan(56)长,因为只有uuid(16)
2、vless
3、回落
Tls1.2 的序列号相当于1.3比较有规律,容易被GFW捕捉到,xtls已经被精准的探测到了
在Trojan中,对于不符合的流量会落到上一步,继续寻找符合的,可以公用一个端口,一个端口可以搭建不同的协议,只有vless能用
Trojan
1、概述
通过SS协议我们可以知道,单纯的对本地请求的域名内容进行伪装经过GFW是十分不安全的。所以需要Plugin插件,为伪装的内容加上http请求头来冒充http流量。由于互联网上一半左右的流量都是http流量,所以伪装成http流量是十分“保险”的,这也是本节Trojan协议的特色。
Trojan协议是将端口监听到的流量变成http流量,可以简单地理解为加了plugin插件的SS协议,不同的是Trojan协议本身就是一个拥有正规合法的域名证书的TLS协议(这部分后文再解释),就算是GFW进行重放攻击,Trojan协议也能够将GFW的访问介入一个正常的网页(这个网页可以是自己做的假网页,也可以是一个正常的网页,比如baidu.com);这就很大程度上规避了GFW的审查。
当然也存在着一些缺点,比如双层TLS加密等,但这不是Trojan协议存在的问题,而是所有伪装成http流量的协议或多或少都会存在的问题。这会降低解码效率,延迟增加,但是也有相应的解决方案。总的来说这是一个比较成熟的协议,不仅有着覆盖全平台的客户端的支持,而且有着很多人对这个协议进行完善改良;该协议也被广泛的应用在一些专线、解锁流媒体等节点中。值得注意的是,该协议对免流不太友好。
2、辅助知识
💡 在介绍Trojan协议之前,首先需要引进**http协议**、**https协议**和**TLS、域名、证书**等概念。这些内容既是了解翻墙必不可少的概念,也是整个互联网中关键的部分。
2.1、HTTP
HTTP协议即“明文传输”协议。超文本传输协议(Hyper Text Transfer Protocol,HTTP)是一个简单的请求-响应协议,它通常运行在TCP之上。我们常见的在浏览器地址栏中的以http://
开头的部分就是http协议;是现存互联网上最大的协议。
其传输过程是将HTML(Hyper Text Markup Language),即超文本标记语言通过浏览器加以汇编后明文进行传输的协议。其优点是覆盖全平台,效率极高;缺点是过程是明文的,输入的任何内容都会被中间经过的服务器看见或者更改。例如:
请输入账号密码 账号:123 密码:456
经过中间服务器乃至于防火墙的时候显示的就是:
<!DOCTYPE html>
<html>
<head lang="zh">请输入账号密码</head>
<body>
<p>账号:123</p>
<p>密码:456</p>
</body>
</html>
这在当今社会是极为不安全的,所以现在的浏览器地址栏的网址一般是https://
开头的,http后面的s就是TLS非对称加密协议,纯粹的http://开头的网址已经被大部分浏览器认为是不安全的并弹出警告。
2.2、HTTPS
TLS加密协议是一种非对称加密算法,通过TLS对http进行加密后的数据只用通过特定的公钥才能够解开。而公钥是记录在CA证书上的,CA证书由权威的认证机构颁发,我们的计算器将这些权威的CA证书颁发机构添加的本机的根证书目录,作为信任的标志。一但是这些机构颁发的证书就会被互联网所承认。
对称加密:ss——加密的密码和解密的密码保持一致(123-123)
非对称加密:公私钥(私加123,公解321) 私钥自己生成,公钥是基于私钥生成出来的 公钥公开,任何人都可以知道,私钥保存在自己的服务器里
所以要想进行TLS加密首先要有证书,证书要在CA机构申请(有特定的代码,详见VPS节),申请证书之前需要有一个域名(详见域名节)以及其公钥和私钥
申请证书的过程你可以想象成是逆向CA证书颁发机构提出申请,CA机构需要你证明你的域名是你的(比如让你在你的域名网站上加上特定字符等)
2.3、TLS加密
TLS是浏览器自行对于浏览器发送的内容进行加密,这部分在经过任何中间服务器乃至于防火墙的时候都不是明文状态
当然也不是绝对的安全,抓包软件已经识别了CA证书的加解密方式并提供了证书破解
但是现阶段还是相对安全的,涉及到账号密码等安全内容会有其他加密方式
只加密你的传输内容,而不是对于所有的域名、IP、端口等都加密
不需要对网站进行加密,因为一个IP可能有多个网站,每个网站都有自己的公钥和私钥,网址sni
TLS1.3可以加密sni——esni——GFW直接丢包(你可能借机访问被禁止的网站),这种方式还没有普及,如果普及GFW也要做出相应的修改
3、Trojan
3.1、证书
Trojan因为是模拟https所以需要申请证书,所以需要域名
如果是自签就写上vps的ip,如果是购买域名可以直接写域名,sni默认不写
自签就是自己做CA,这种需要不严重或者添加到受信任的根证书certmgr.msc里面
3.2、流量传输过程
Trojan协议实际上是经过了2此TLS加密
第一次是https自己本身的浏览器加密,第二次是Trojan协议的加密
前者加密请求内容,后者加密请求域名,后者的加密覆盖前者
Trojan是正经的申请合法的域名和证书,所以在经过GFW的时候不会因此怀疑,因为和plugin插件伪装的http流量不同,Trojan本身就是合法的http流量
如果使用的不是CA证书申请,而是自签的话;需要将自己的自签证书加入需要进行访问的计算机的根证书目录或者不开启证书验证
就算GFW对Trojan服务器释放重放攻击,Trojan自身的域名在配置完成后也可以将不通过验证的访问导向一个正常的网站(比如baidu.com)
3.3、效果
4、存在的问题和解决办法
💡 Trojan也有自己的问题会进行两次的tls加密,第一次是自己的加密,第二次是正常访问目标的tls加密,目的都是为了伪装成https流量,其他的方法或多或少也会存在问题。可以通过XTLS的方式进行解决。
4.1、XTLS
XTLS是X先生写的一个协议,目的是解决因Trojan协议带来的TLS双层加密的问题,通过精准的探测双层TLS的特征,抹除重复加密的部分来缩短解密的时间,使得Trojan的性能对大化。
本质上消除两次加密重复且不需要的部分,减少加解密时间,性能接近于裸奔
本机在浏览器发送请求,首先被浏览器的http加密一次,但是目标域名之类的因为要向DNS获得IP,所以没有被加密。而IP例如google.com如果直接发送会被GFW的黑名单识别拦截
所以再经过Trojan协议的二次TLS加密,这个过程隐藏了原来http://的内容,在前面加上了Trojan协议的域名伪装成正常的http流量。目的是为了隐藏本机的域名请求意图
Trojan的内容加密部分就是第一次在浏览器搜索的部分,Trojan的服务器IP不再GFW的黑名单之中,且域名的证书是合法有效的,所以不用加密Trojan的域名请求
4.2、趣闻
💡 有很多人好奇X-ray和XTLS的关系,实际上没啥好说的,就是几个误会交织在一起发展出更大的误会
XTLS的开发者X先生在开发XTLS的时候是v2ray的主要开发者之一,并在v2中引入了XTLS的代码,因为怕XTLS滥用所以在GitHub的开源文档中写了目前只做汇编之类的。Debian系统开发者给X先生留言说希望更改开源内容,以便可以在Debian中打包。
X先生回复说我虽然是那么写的,但是你想打包就打包吧;但是Debian认为你的开源报告中的说法不符合开源打包的要求,所以坚持希望X先生修改,否则就只能下架。这个时候X先生不知道自己的XTLS已经被打包进了Debian,而且X先生主力机是Windows,在Linux中也主要是用命令安装东西,所以对Linux开源社区的规则不太了解(可能还有X先生和Debian的交流都是用的谷歌翻译的锅>_<),所以X先生就是倔强的不改
然后v2的另一个主要开发者出来当和事佬,说会出一个脚本来删除v2中XTLS的代码,然后X先生就炸毛了。就离开v2ray出来单干,开发了自己的Xray,他的书名文档写的很有意思,几乎是白话文,大家可以看看。
X-ray就一个内核,v2ray这个软件是运行内核的图形化界面