MENU

利用 GOST 搭建加密中转隧道

February 16, 2020 • Read: 9304 • 越过长城,安全

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

参考

Last Modified: March 13, 2020
Archives QR Code
QR Code for this page
Tipping QR Code
Leave a Comment

23 Comments
  1. qzcloud qzcloud

    大佬,tls 隧道这个,现在udp 是不是用不了,只能TCP

    1. @qzcloud嗯,forward模式不支持UDP。

    2. @qzcloud而且TLS本来就是基于TCP的,不支持UDP。

  2. esKyoho esKyoho

    大佬,如果有三台机器:一台墙内中转,一台墙外中转,一台墙外落地。是不是把127.0.0.1改成落地机器的IP就可以了?

    1. @esKyoho理论上是,不过没测试过。

  3. uudis uudis

    大佬,运行 gost -L udp://:442 -L tcp://:442 -F relay+mtls://服务器IP:441

    提示 main.go:88: address 442: missing port in address

    请问是什么原因?应该如何解决?

    谢谢!

    1. @uudis后面那个地方多个空格吧

    2. zzz zzz

      @uudisgost -L relay+ws://:12345/127.0.0.1:443
      是不是开启了 ws tcp+udp

  4. g g

    大佬为啥我启动后只监听IPV6

    1. Qingz Qingz

      @g我也是诶,很奇怪。用的阿里云

    2. @g不会吧,我在vultr上试过,没什么问题。

    3. @Qingz阿里云还有IPv6吗?

  5. lzz lzz

    我用gost 500g流量一周就没了。 。。。 之前用ss每月只用2g的。

    1. ying乐 ying乐

      @lzz你这个头像。。。绝了

  6. hh hh

    大神!docker-compose如何安装使用可以说下步骤吗?还有如何把这节点加入ssoanel对接 ?

  7. 大佬请问下如果使用docker方式运行,该怎么填写docker的运行配置请教一下!

  8. 感谢,之前都不知道隧道怎么才能转发UDP流量,导致必须购买IPLC机器来给游戏加速,这样一来成本就低了,待会试试。

    1. @DDCH玩codm,用 深圳-香港-台湾 relay+wss 转发$$流量很快

  9. 请问docker-compose怎么配置多链路转发呢?

    这是我的docker-compose.yml文件

    version: "3" services: redirect: container_name: gost image: ginuerzh/gost restart: always network_mode: "host" command: - "-L=tcp://:1111/1.1.1.1:1111" - "-L=tcp://:2222/2.2.2.2:2222" - "-L=tcp://3333/:3333" - "-F=ws://3.3.3.3:443" - "-L=tcp://:4444/4.4.4.4:4444" logging: options: max-size: "10m" max-file: "3"

    这是我在3.3.3.3服务器上运行的命令

    ./gost -L "ws://:443?path=/ws&rbuf=4096&wbuf=4096&compression=false"

    发现一个问题,如果说3.3.3.3服务器出错了,那么其他的转发都会失效,不知道应该怎么去写这个docker-compose文件,让其支持多链路转发

    我也提了一个bug https://github.com/ginuerzh/gost/issues/571

  10. zzzzz zzzzz

    mwss不也是多路复用吗?直接relay+ws与relay+tls有很大差异吗

  11. v10 v10

    大佬,不知你的配置和这种配置有什么区别?而且这种配置我不是很能理解……
    国内鸡:
    {
    "Debug": true,
    "Retries": 0,
    "ServeNodes": [
    "udp://0.0.0.0:666/1.1.1.1.1:2333",
    "tcp://0.0.0.0:666/1.1.1.1.1:2333"
    ],
    "ChainNodes": [
    "relay+tls://xxx:[email protected]:443"
    ]
    }
    国外鸡
    {
    "Debug": true,
    "Retries": 0,
    "ServeNodes": [
    "relay+tls://xxx:[email protected]:443"
    ]
    }
    是否是在国内鸡建立666端口到国外鸡55R的2333端口的转发,然后将这个请求转发给国外鸡443端口?,两种配置貌似达到的作用是一致的,但感觉好像哪里不太一样,还望大佬教我。而且这样好像也没有暴露国外鸡55R的端口,这又是怎么做到的呢?

    1. v10 v10

      @v10你的那种配置方式我是能理解的,但这种转发配置是怎么做到不暴露国外鸡55R端口的呢?

  12. 问下博主,有没有一种办法或者思路:

    让国内的流量直接接入中转鸡本地的SS客户端,而国际流量再通过隧道到达落地鸡的SS客户端,实现流量的分流。

    感谢啦~