Naiveproxy客户端搭建指南

发表于 阅读次数： 本文字数： 2.1k 阅读时长 ≈ 7 分钟

小心使得万年船

最近又要进入敏感时期了，所以安全得包装，22年10月份封禁了一大批。随着Xray作者提出的TLS in TLS可以被探测到。可见目前协议不是安全的，Xray提出了一个解决方案：XTLS。但是XTLS会占用服务器得443端口，需要接手服务器所有流量。对于目前得我来说并不是很方便，而且我推崇服务器只开放常规端口，做到像普通服务器一样。

几种解决方案

那么，有没有别的安全得翻墙方式么？也是有的，针对TLS in TLS，那片文章也提出了三个解决方案。
117-Naiveproxy客户端搭建指南-2023-05-30-09-32-52

  1. NaiveProxy
    • 原理是高度模仿HTTPS访问
    • 使用的人数不多，而且客户端支持也不多，甚至文档也不多
  2. 魔改得shadowsocks
    • 新版本得Xray支持，就是推荐的加密方式：
      2022-blake3-aes-128-gcm
      2022-blake3-aes-256-gcm
      2022-blake3-chacha20-poly1305
    • 好像不支持caddy转发，只能开放对应端口，不是很符合我尽量少开放端口得原则
    • NaiveProxy说过不要自己戳密码，SS就是他举例得典型
  3. MITM，简单说就内部流量脱去TLS加密，由服务器进行加密。
    • 原理很简单，你不是TLS in TLS，那么我内部得就明文传输，这样就是完整的TLS
    • 问题也很简单，就是你翻墙访问得所有网站都会提示你证书不可信。

所以最后我选择了NaiveProxy。

部署方案

准备材料：

  • 1台可以访问的VPS
  • caddy v2
    部署方式：
  • docker部署

这个很重要，请确认你的版本和我得是不是对应的，因为我这次找了很多文档，都是caddy v1的或者就是什么其他部署方式，对我来说，参考程度有限。
其次我不推崇使用一键脚本，那用起来舒服，但是对自己的服务器上有一块盲区，总归是不安全的。我推荐使用docker部署，安全和便捷兼具，我会尽量做到一步到位。如果你还没安装docker，可以翻看我之前的教程，或者去官方看教程。也是很简单的。
NaiveProxy是没有服务器软件的，直接使用包含naïve的caddy forwardproxy分支来代替单独的naïve服务端，所以我们需要一个docker安装caddy即可。

  1. 创建一个空文件夹,然后创建dockerfile，复制一下代码：

    1
    2
    3
    4
    5
    6
    7
    FROM caddy:builder-alpine AS builder

    RUN xcaddy build \
        --with github.com/caddyserver/forwardproxy@caddy2=github.com/klzgrad/forwardproxy@naive
    FROM caddy:alpine

    COPY --from=builder /usr/bin/caddy /usr/bin/caddy

    这里需要注意forwardproxy的master是caddy v1版本的，所以必须在后面写上caddy2，然后看文档也要注意，选择caddy2分支。两边不一样。

  2. 在同一个文件夹下面创建文件docker-compose.yml

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    version: "3.9"  # optional since v1.27.0
    services:
    caddy: #caddy反向代理
        container_name: caddy
        build:
        context: .
        dockerfile: dockerfile #这里就是调用你步骤一创建的文件
        restart: unless-stopped
        environment:
        - PUID=1000
        - PGID=1000
        - TZ=Asia/Shanghai
        volumes:
        - /<你的路径>/data:/data #caddy留存的证书信息,最好保存,方便后续迁移
        - /<你的路径>/caddyconfig:/etc/caddy #caddyfile的配置文件
        - /<你的路径>/file:/usr/share/caddy #caddy的运行网页
        ports:
        - "80:80"
        - "443:443"
        - "443:443/udp"

  3. 部署docker，直接使用命令(确保路径下有这个文件)：

    1
    docker-compose up docker-compose.yml

  4. 在- /<你的路径>/caddyconfig:/etc/caddy #caddyfile的配置文件这个路径下创建Caddyfile文件：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    :443, xxxx.xxxx.com { # 443必须的，否则无法执行，逗号后面有个空格，别忘记了。
        route {
            forward_proxy {
                basic_auth <用户名> <密码>
                hide_ip
                hide_via
            }
            file_server {
                root /usr/share/caddy/share # 可以在之前的网页路径下随便放一个index网页
            }
        }
    }

  5. 重启下docker就可以了。

  6. 打开本地电脑的客户端下的config.json

    1
    2
    3
    4
    {
    "listen": "socks://127.0.0.1:1080",
    "proxy": "https://用户名:密码@xxxx.xxxx.com"
    }

    端口可以改，也可以不改。

  7. 如果使用习惯v2rayng的话，可以：服务器——添加自定义服务器
    117-Naiveproxy客户端搭建指南-2023-05-30-10-13-21
    浏览选择一下对应的config.json即可。但是测速和测延迟就失效了。

到此就可以直接使用了，最后测一下速度：

  1. vless+h2+tls:
    117-2023-05-29-21-06-43

  2. NavieProxy:
    117-2023-05-29-21-08-18

  3. 自建speedtest的测速:
    117-2023-05-29-21-09-15

最后的速度和网页测速差不多，这是晚高峰的速度，我1000M的网络跑到这个速度算是很可以了。

其他的配置说明

这里说明一下其他的可选配置：

  1. caddy的route功能：将一组指令按字面意思作为一个单元进行评估。路由块中包含的指令不会在内部被重新排序。所以route包围的命令就会同等对待，正常是按照先后顺序，前面的指令执行后面的指令就不会继续执行，所以使用route可以避免这种情况。
  2. forword的一些功能，具体的可以去看对应官方文档，反正功能挺齐全的。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    :443, example.com
     route {
         forward_proxy {
             basic_auth user1 0NtCL2JPJBgPPMmlPcJ
             basic_auth user2 密码 # 身份验证
             ports     80 443 #端口，如果你用的是别的端口在这改
             hide_ip # 推荐，防止主动探测的
             hide_via #推荐，防止主动探测的
             probe_resistance xxxx.com #防止主动探测的
             serve_pac        /secret-proxy.pac # pac文件存放，可以
             dial_timeout     30
             upstream         https://user:[email protected] # 这个是上游的，用来配置代理链条的，即一台给另一台
             acl {
                 allow     *.caddyserver.com
                 deny      192.168.1.1/32 192.168.0.0/16 *.prohibitedsite.com *.localhost
                 allow     ::1/128 8.8.8.8 github.com *.github.io
                 allow_file /path/to/whitelist.txt
                 deny_file  /path/to/blacklist.txt
                 allow     all
                 deny      all # unreachable rule, remaining requests are matched by `allow all` above
             }
         }
         file_server
     }
    其中:
    • hide_ip 用来删除头文件的ip和下面一样，推荐配置
    • hide_via 用来删除头文件via的推荐配置，不删除的话是会显示Via: 2.0 caddy
    • probe_resistance:后面可以跟上网址，如果有人访问网址没有带用户名和密码的话，会默认弹出"407 Proxy Authentication Required" ，这样会暴露出我是代理服务器，这个配置就是你要访问这个秘密网址才会弹出，但是我们caddy使用了route，所以如果没有密码的话会访问到正常的网页，可以根据情况配置
    • serve_pac：用来配置pac文件的，我用v2rayNg自带，所以不配置，默认pac文件位置http:网址/proxy.pac，你改好放那里就行
    • dial_timeout：超时
    • upstream：这个是用来配置代理链条的，如果你还希望再加一层，可以通过这个转发到上游去，让它继续代理。
    • acl：路由规则，允许/拒绝的ip，域名甚至文件都可以

总结

综合来说：NaiveProxy的优点很明显，服务器配置简单，而且安全。缺点也很直白，客户端简陋，支持的少。
从翻墙工具的发展历史我们可以看出这场攻防战的思路在变：
一开始时SS，讲究的是一个加密，破解不了，没人知道你访问的内容，后起之秀的思路也是顺着这条，加TLS等证书加密，但是随着墙的封锁，大家发现，我们和墙并不是对等关系，墙并不需要证据就可以封锁你，只要它觉得你是在翻墙就可以。战争的思路也要随着改变，更多的人选择藏木于林，尽可能的模拟正常的网站流量和藏匿自己的服务器。现在新一代的工具主流思想就是尽可能地模拟正常的网络流量。
思路的转变并不是坏事，毕竟局势不一样了，所以我目前的思路也是，尽可能的模仿正常网站，不会乱开多余的端口。
最后，有没人愿意合租服务器，使用NaiveProxy配置，流量没限制，主要NaiveProxy也无法限制。有的话可以留言或者联系我[email protected]

参考文章：
Trojan-Killer
XTLS 深入浅出
NaïveProxy官方部署文档
forwardproxy
caddy2的route指令
caddy1-forwardproxy的中文文档