NaiveProxy和V2Ray共存 Naive流量走Socks5代理进V2Ray 墙内CN域名和IP 路由到黑洞blackhole或WARP

点击标签看相关主题:

需求

如果共享NaiveProxy梯子给朋友，万一朋友开了全局模式，把墙内的CN流量丢进来了，然后梯子又去访问墙内，那么墙就知道这是个梯子了。

所以需要把 墙内CN域名和IP 路由到黑洞blackhole或WARP

而NaiveProxy服务端没有路由功能。


思路 

NaiveProxy出来的流量走Socks5代理进V2Ray, 然后利用V2Ray的路由功能分辨出CN的域名和IP, 并分流到黑洞blackhole或WARP.

NaiveProxy服务端(Caddy)

参考

https://github.com/klzgrad/forwardproxy#other

upstream 参数可以指定流量的下一步出口

V2Ray设置inbound和路由

参考

https://www.v2ray.com/en/configuration/protocols/socks.html#inboundconfigurationobject

建立一个inbound为Socks5 


具体实践

1. 先把V2Ray和NaiveProxy都搭好

V2Ray教程: https://zelikk.blogspot.com/2022/11/v2ray-vless-vmess-websocket-cdn-tls-caddy-v2.html

Naive教程: https://zelikk.blogspot.com/2022/11/naiveproxy-caddy-v2-vless-vmess-cdn.html

2. Naive服务端(Caddy)增加Socks5出口

修改Naive的Caddyfile, 添加一行

upstream socks5://127.0.0.1:1080

修改Caddyfile 添加 upstream 配置 Naive proxy 流量走Socks5出去

3. V2Ray添加Socks5入口inbound

编辑文件config.json在inbound段下面添加一段

注意跟在原有的这段后面要加个英文逗号，再写Socks5的部分。这是因为json的语法格式。

编辑config.json添加v2ray inbound socks5

{
  "listen": "127.0.0.1",
  "port": 1080,
  "protocol": "socks",
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "http",
      "tls"
    ]
  },
  "settings": {
    "auth": "noauth",
    "udp": false
  }
}

检查一下config.json文件格式有没有问题

/usr/local/bin/v2ray -config /usr/local/etc/v2ray/config.json --test

/usr/local/bin/v2ray -config /usr/local/etc/v2ray/config.json --test 测试v2ray配置文件格式

像这样显示 Configuration OK. 说明格式是正确的。

4. 重启Naive服务端(Caddy)和V2Ray

service caddy restart

service v2ray restart

检查一下各功能是否正常使用。

当通过Naive节点翻墙时，检查v2ray的日志中是否有记录。

v2ray日志access.log检查路由设置效果

5. 修改V2Ray的路由设置

这里的修改方法就和其它教程里v2ray设置路由的方法是一样的了。

我只举我自己的例子，让墙内CN域名和IP路由到WARP

{
     "type": "field",
     "outboundTag": "socks5-warp",  
     "domain": ["geosite:cn"]  
},
{
     "type": "field",
     "outboundTag": "socks5-warp", 
     "ip": ["geoip:cn"]  
},

重启v2ray以后，测试效果。

v2ray日志access.log检查路由设置效果

访问国内CN测IP网站ipw.cn检验路由设置 访问国内CN测IP网站myip.ipip.net检验路由设置

后记

第2步和第3步，用的 1080 这个端口是互相对应的。如果你的VPS上这个端口已经被占用，那就换一个，两个地方要保持一致。也就是说Naive服务端(Caddy)从这个端口丢数据出来，V2Ray从这个端口接收。

--------

第5步，你如果粗暴一点就把tag设置为blocked, 然后在outbound那里tag为blocked的出口是黑洞blackhole.

--------

开Socks5的inbound时，使用的是"listen": "127.0.0.1" 所以这个端口没有对外。你可以使用 ping.pe 等工具测试一下Socks5的端口是不是在外部可以访问。

config.json文件示例

{
  "log": {
    "access": "/var/log/v2ray/access.log",
    "error": "/var/log/v2ray/error.log",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 9877,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "05b02aa-faa-447-bdd-06863aa8b84",
            "level": 1,
            "alterId": 0
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "ws"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    },
    {
      "tag": "socks_proxy",
      "port": 1080,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      },
      "tag": "direct"
    },
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv4"
      },
      "tag": "force-ipv4"
    },
    {
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv6"
      },
      "tag": "force-ipv6"
    },
    {
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 40000
          }
        ]
      },
      "tag": "socks5-warp"
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "dns": {
    "servers": [
      "https+local://8.8.8.8/dns-query",
      "8.8.8.8",
      "1.1.1.1",
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "ip": [
          "0.0.0.0/8",
          "10.0.0.0/8",
          "100.64.0.0/10",
          "127.0.0.0/8",
          "169.254.0.0/16",
          "172.16.0.0/12",
          "192.0.0.0/24",
          "192.0.2.0/24",
          "192.168.0.0/16",
          "198.18.0.0/15",
          "198.51.100.0/24",
          "203.0.113.0/24",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "outboundTag": "socks5-warp",
        "domain": [
          "geosite:cn"
        ]
      },
      {
        "type": "field",
        "outboundTag": "socks5-warp",
        "ip": [
          "geoip:cn"
        ]
      },
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

评论

  1. juc十二月 03, 2022

    你好，文中的配置文件能全发一下吗？我目前配置outbounds出了点问题

    回复删除
    回复
    1. ǝɔɐǝԀʎzɐɹƆ十二月 03, 2022

      你好。我更新了配置文件示例在文末。建议你先测试json文件格式无误事再查逻辑问题。
      /usr/local/bin/v2ray -config /usr/local/etc/v2ray/config.json --test

      删除
    2. juc十二月 03, 2022

      感谢您的分享，这解决了我的问题。谢谢。

      删除
    3. ǝɔɐǝԀʎzɐɹƆ十二月 03, 2022

      不客气，很高兴帮到你！：）

      删除

发表评论

The Hot3 in Last 30 Days

用浏览器 检测Reality伪装效果 是否搭建成功 排错Troubleshoot

图片
Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的.
Read more »

用darkstat统计VPS上的流量

图片
感谢 https://0x3f.org/posts/darkstat-as-a-network-discharge-meter/ https://ilovn.com/2023/03/25/darkstat/ 安装 apt install -y darkstat 启用 darkstat -i 监听网卡 -p 网页端的端口号 如 darkstat -i eth0 -p 8964 页面端查看 http:// 你的vps的IP : 网页端的端口号 如 http:// 12.34.56.78 : 8964 效果类似下面这样 点 host 可以看到数字表格的统计信息. 点其中一条 可以看到更详细的信息. 能看到在本VPS上, 还有指定IP上, 分别用到了什么端口(包括TCP UDP), 以及分别跑了多少流量. 如果你有有更好的工具, 欢迎留言分享!
Read more »

233 sing-box 脚本 TCP 端口转发 Reality 协议 排错 Troubleshoot

图片
233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...
Read more »