利用 GOST 搭建加密中转隧道

大陆网络出境环境日益恶劣，很多人都利用了国内的服务器来中转流量，比如采用阿里云、腾讯云等国内 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。

2020-3-7 更新展开目录

由于 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 的容器内，省事一点。

参考展开目录

• Redirect attack - Shadowsocks 流密码的不安全因素
• GOST 文档中心