RSS: https://songxwn.com/atom.xml
tun2proxy 是一个基于 smoltcp 在 Linux 上 通过 HTTP 和 SOCKS 代理的创建隧道接口的项目,使用 Rust 语言开发。
项目地址:https://github.com/blechschmidt/tun2proxy
git clone https://github.com/blechschmidt/tun2proxy.git
# 克隆项目
cd tun2proxy
cargo build --release
# 编译 (需要提前安装 cargo 工具)
cd ./target/release
# 进入输出目录
官方发布地址:https://github.com/blechschmidt/tun2proxy/releases
PS:选好对应 CPU 和系统
本站编译好的:https://songxwn.com/file/tun2proxy (Linux X86-64)
ip tuntap add name tun163 mode tun user $USER
# 提前创建好 tun 三层虚拟口
sudo ip link set tun163 up
# 配置状态为 UP
./tun2proxy --tun tun163 --proxy "socks5://username:[email protected]:9527"
# 前台运行,将 socks5 转换为三层接口。格式为 proto://[username[:password]@]host:port
ip route add 128.0.0.0/1 dev tun163
# 手动配置路由指向,也可以配置策略路由等操作。
PS:IP 命令配置的都是临时的,重启失效。
./tun2proxy --setup auto --proxy "socks5://1.2.3.4:1080"
# 自动将所有流量路由到指定的代理。
Tunnel interface to proxy.
Usage: tun2proxy [OPTIONS] --proxy <URL>
Options:
-t, --tun <name> Name of the tun interface [default: tun0]
--tun-fd <fd> File descriptor of the tun interface
--tun-mtu <mtu> MTU of the tun interface (only with tunnel file descriptor) [default: 1500]
-p, --proxy <URL> Proxy URL in the form proto://[username[:password]@]host:port
-d, --dns <strategy> DNS handling strategy [default: virtual] [possible values: virtual, over-tcp, direct]
--dns-addr <IP> DNS resolver address [default: 8.8.8.8]
-6, --ipv6-enabled IPv6 enabled
-s, --setup <method> Routing and system setup [default: none] [possible values: none, auto]
-b, --bypass <IP|CIDR> IPs and CIDRs used in routing setup which should bypass the tunnel
-v, --verbosity <level> Verbosity level [default: info] [possible values: off, error, warn, info, debug, trace]
-h, --help Print help
-V, --version Print version
当 DNS 解析由机器上的服务或本地网络中的服务器执行时,DNS 解析将不会通过隧道接口执行,因为指向 localhost 或本地网络的路由比 Tun 通道更细。 在这种情况下,建议更新文件以使用通过隧道接口路由的名称服务器地址。当虚拟 DNS 正常工作时,你会看到通过以下方式解析后的主机名连接日志信息,
Tun 虚拟设备和物理网卡的区别是 Tun 虚拟设备是 IP 层设备,从/dev/net/tun 字符设备上读取的是 IP 数据包,写入的也只能是 IP 数据包,因此不能进行二层操作,如发送 ARP 请求和以太网广播。与之相对的是,Tap 虚拟设备是以太网设备,处理的是二层以太网数据帧,从/dev/net/tun 字符设备上读取的是以太网数据帧,写入的也只能是以太网数据帧。从这点来看,Tap 虚拟设备和真实的物理网卡的能力更接近。
1
kkocdko 320 天前
终于看到用 smoltcp 做的了 hhhhh ,之前就有这个想法但一直没时间做。
还是很好玩的,但是如果想拿来用的请谨慎,smoltcp 性能堪忧,比不上 gvisor 的 tcp stack 实现。如果只是代理需求,可以考虑 sing-box 或者 clash-meta 内置的 tun device 功能(源自 gvisor netstack ,如果系统支持也可以直接用内核里的),性能要好很多。 |
2
heiher 320 天前 via Android
smoltcp 的性能确实比较一般。在我的 tun2socks 项目中比较过几款不同实现的吞吐、CPU 和内存使用量:
https://github.com/heiher/hev-socks5-tunnel |
3
junmoxiao 320 天前
程序 C-c 停止时是否会自动恢复 sudo ip 修改的那些设置呢?
|
6
junmoxiao 320 天前
用 --setup auto 时
|
9
Songxwn OP @heiher #8
[2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 construct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client construct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client tcp construct ip [2024-01-08 13:56:47] [I] 0x1dd1f10 socks5 client tcp -> [34.117.186.192]:80 [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 session tcp construct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 session tcp new [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 session run [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client connect [110.255.70.50]:6051 [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client connect server [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 session tcp bind [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client connect server fd 10 [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client set auth [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client auth prarsGvF1X:51374941 [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client handshake [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client write request [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client read response [2024-01-08 13:56:47] [E] 0x1dd1f10 socks5 client auth.ver 72 [2024-01-08 13:56:47] [E] 0x1dd1f10 socks5 session handshake [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 session tcp destruct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client tcp destruct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 client destruct [2024-01-08 13:56:47] [D] 0x1dd1f10 socks5 destruct |
10
heiher 306 天前
@Songxwn 哈喽,请再试试 2.6.6 版本:
https://github.com/heiher/hev-socks5-tunnel/releases/tag/2.6.6 问题的机理很可能是:在 2.6.6 版本之前,hev-socks5-tunnel 的 socks5 客户端采用流水化的 socks5 握手实现方式,该方式会将所有的请求合并发送,以减少建立延迟。但这种方式对 socks5 服务器端的实现要求比较严格,如果遇到处理接收缓冲区不严谨的实现,就会造成后续请求不匹配。2.6.6 版本开始支持流水化握手方式开关,且默认关闭。 |