大陆网络出境环境日益恶劣,很多人都利用了国内的服务器来中转流量,比如采用阿里云、腾讯云等国内 BGP 线路中转流量落地到香港 PCCW、日本 NTT 等线路,相对于直接采购一条 CN2 线路有时候成本更低。
基本上大多数人都用的最简单的 iptables 或者 socat 转发,直接将收到的包转到落地节点,本来这并没有什么问题,但自 2020 年以来,墙不断发威,SS/SSR 直连会被非常迅速的识别并封禁。同时又有研究人员指出,SS 的普通流加密存在非常严重的中间人攻击,可以以一种很巧妙的方式轻易解密数据包。此时,构建一条加密中转隧道就成了必要的选择。
选型
大概看了看隧道加密的各类文章,可以将实现方案分为两类:
-
一类是如 Stunnel、GOST 的 TLS 加密隧道,通过 TLS 或其他加密方式,将数据包加密传输,在落地节点上解密转发到最后的出口;
-
一类是如 Zerotier、WireGuard 的组网形式,将异地的两台机器组成一个内网,然后在内网中直接进行数据转发,此时数据会由组网组件来进行加密处理;
第一类方案操作比较简单,理解起来也比较容易,但缺点是 TLS 等加密方案大多都是基于 TCP 的,所以对这类隧道对 UDP 的支持较差。而第二类方案可以较好地支持 UDP 转发,但由于本身是特定的加密协议,特征较为明显,且 WireGuard 基于 UDP,对大陆的网络环境适应性不太好。综合考虑,还是先选择了第一类方案。
实践
GOST 是一个用 Go 语言实现的安全隧道工具,功能较为丰富,支持组建代理链路。在这里我们基本只用到了端口转发这一个功能,具体文档可以参考这里。
2020-3-8 更新relay+mtls
似乎性能有点问题,速度上不去,可能多路复用有点 bug,建议直接用 relay+tls
或者用 relay+mwss
。
由于 forward
协议不支持转发 UDP,所以给作者提了 一个 issue,近日作者更新了版本,新增了 relay
协议,支持了 UDP 的转发。
那么,加密隧道就可以这样设置。
1、国内中转机器
gost -L udp://:1053 -L tcp://:1053 -F relay+mtls://1.2.3.4:12345
监听本机 1053 端口的 TCP、UDP 连接,转发到落地机器的 12345 端口。
2、落地机器
gost -L relay+mtls://:12345/127.0.0.1:443
监听本机的 12345 端口,接收转发过来的连接,再转给本地的 443 端口。
不加密直接转发
有些节点已经换成了 V2Ray+WS+TLS 的方案,已经有了一层 TLS 加密,这时就不需要再在隧道上加一层来套娃了,徒增性能损耗,可以直接端口转发。GOST 也可以支持直接转发,这样就可以省去 iptables 或者 socat 的工作。
gost -L=tcp://:443/1.2.3.4:443 -L=udp://:443/1.2.3.4:443
很简单,直接监听本机 443 端口,转发到落地节点 1.2.3.4 的 443 端口上。这种节点后端个人比较习惯生产环境都用 docker-compose
部署,便于更新和管理,可以这样写。
version: "3"
services:
redirect:
image: ginuerzh/gost
restart: always
network_mode: "host"
command:
- "-L=tcp://:443/1.2.3.4:443"
- "-L=udp://:443/1.2.3.4:443"
logging:
options:
max-size: "10m"
max-file: "3"
然后 docker-compose up -d
即可启动。
docker-compose
的安装在 Ubuntu、Debian 上可以这样操作。
apt update && apt upgrade
apt install python3-pip
pip3 install -U pip
pip3 install docker-compose
TLS 加密隧道
目前网上也有一些 GOST 加密隧道的教程,但大多都有问题,有些人直接使用 GOST 的代理链路功能来转发,这样会导致落地节点上也多开了一个 GOST 代理,而且没有任何验证,可以直接起一个 GOST 客户端连上去,有一定风险。其实 GOST 的文档里提到了加密隧道的搭建方法,即利用 forward
协议。
国内机器
gost -L=tcp://:443 -L=udp://:443 -F=forward+mtls://1.2.3.4:443?mbind=true
监听 443 端口并利用 mtls
传输到落地节点 1.2.3.4
的 443
端口,?mbind=true
启用多路复用,不写也没什么关系。
落地节点
gost -L=mtls://:443/127.0.0.1:843
落地节点的 SSR 进程监听 127.0.0.1:843
,然后 gost
监听 443
端口转发到 SSR
上即可。
同样附一个 docker-compose.yml
。
中转机器
version: "3"
services:
tls:
image: ginuerzh/gost
restart: always
network_mode: "host"
command:
- "-L=tcp://:443"
- "-L=udp://:443"
- "-F=forward+mtls://1.2.3.4:443?mbind=true"
logging:
options:
max-size: "10m"
max-file: "3"
落地节点
version: "3"
services:
ssr:
image: fanvinga/docker-ssrmu
restart: always
network_mode: "bridge"
environment:
API_INTERFACE: "modwebapi"
WEBAPI_URL: "****"
WEBAPI_TOKEN: "***"
MU_SUFFIX: "***"
FAST_OPEN: "true"
SPEEDTEST: 6
NODE_ID: 1
TZ: "Asia/Hong_Kong"
logging:
options:
max-size: "10m"
max-file: "3"
gost:
depends_on:
- ssr
image: ginuerzh/gost
restart: always
network_mode: "bridge"
links:
- ssr
ports:
- "443:443/tcp"
- "443:443/udp"
command:
- "-L=mtls://:443/ssr:443"
logging:
options:
max-size: "10m"
max-file: "3"
这里利用 Docker 的桥接网络,没有将 SSR 进程的端口暴露给主机,而是利用桥接直接将流量转发到 SSR 的容器内,省事一点。