如何用TUN模式实现局域网共享代理？

凌晨两点，李然盯着屏幕上的K线图，手指无意识地敲着桌面。比特币刚刚跌破六万刀，他的空单浮盈不错，但此刻他顾不上开心——他正在给团队里的三个新人同步链上数据，而他们的电脑全都卡在“连接中”的转圈动画里。

“又来了。”他叹了口气。公司内网限制严格，只有他的开发机通过特殊手段连上了海外节点，其他几台机器要么慢如蜗牛，要么直接超时。新人小陈在群里发了个哭脸：“李哥，我这钱包余额都刷不出来，是不是又得挂梯子？”李然知道，挂梯子不是长久之计——每台机器都要单独配置，稍有不慎就断连，更别提那些需要实时同步的链上监控脚本。

他想起上周在技术社区看到的一个词：TUN模式。当时没细看，现在却像根救命稻草。他打开搜索引擎，输入“TUN模式 局域网共享代理”，然后靠在椅背上，决定从头理清这件事。

为什么普通代理在局域网里总掉链子？

李然先复盘了现有方案。他之前用的是常见的HTTP/SOCKS5代理，在自己的开发机上开一个端口，然后让其他机器通过局域网IP加端口连接。理论上没问题，但实际用起来，小陈的电脑经常报“代理服务器无响应”，而另一台跑量化回测的机器则出现部分流量不走代理的情况——比如某些钱包客户端内置的节点连接直接绕过了系统代理。

“因为普通代理是应用层的东西。”李然自言自语。他想起网络课上的知识：HTTP代理只处理HTTP流量，SOCKS5虽然更底层，但很多程序（尤其是区块链节点软件、钱包的P2P模块）根本不理会系统代理设置。它们直接发TCP/UDP包，而普通代理对这些包无能为力。

更麻烦的是，局域网里每台机器都要手动配置代理地址，一旦他的开发机IP变了（DHCP租约到期），所有机器都得重配。小陈已经抱怨过三次“又连不上了”。李然需要一个方案，能让局域网内所有设备——包括那些不认代理设置的钱包、节点、甚至手机上的交易所App——都自动走他的代理通道。

TUN模式进入了他的视野。

TUN模式到底做了什么不一样的事？

李然找到一篇讲WireGuard和TUN的帖子，里面有一句话点醒了他：“TUN模式创建的是一个虚拟网卡，它工作在网络层（第三层），而不是应用层。”

他打开终端，试着在自己机器上创建一个TUN接口。ip tuntap add mode tun dev tun0，然后配上一个内网IP。这个tun0就像一块虚拟网卡，所有发往特定网段（比如10.0.0.0/24）的流量都会被路由到这块网卡上。而他的代理程序可以监听这个接口，把收到的IP包封装成代理协议，再发往真正的远程服务器。

关键区别在于：普通代理需要应用程序主动把流量发给代理端口（通过设置），而TUN模式是在路由表层面劫持流量。只要把局域网其他机器的默认网关指向他的开发机，或者在他的开发机上开启IP转发并配置NAT，那么其他机器发出的所有IP包——不管是什么协议，不管是HTTP还是比特币的P2P握手——都会先到达他的机器，然后被TUN接口捕获，进而送入代理隧道。

“这就相当于我把自己的机器变成了一个软路由。”李然兴奋地拍了下桌子。他马上想到了场景：小陈的电脑只要把网关改成他的IP，什么都不用配，钱包、交易所、链上浏览器全部自动走代理。手机也一样，连上同一个WiFi，改个网关就行。

但问题来了：他的开发机本身也需要上网，而且不能把所有流量都代理——比如访问公司内网服务器就得直连。这就需要精细的路由规则。

动手搭建：从零开始配置TUN共享代理

李然决定用最熟悉的Linux环境来试。他的开发机是Ubuntu 22.04，有一张物理网卡enp3s0，局域网IP是192.168.1.100。目标：让局域网内192.168.1.0/24的其他机器（比如小陈的192.168.1.101）通过他的代理访问外网，同时他自己也能正常访问内网和互联网。

第一步：创建TUN接口并配置路由

他先安装了一个轻量级的代理工具，这里用sing-box举例（因为它对TUN支持很好）。配置文件里定义一个tun入站：

json { "inbounds": [ { "type": "tun", "interface_name": "tun0", "inet4_address": "10.0.0.1/24", "auto_route": false, "strict_route": false, "stack": "system" } ], "outbounds": [ { "type": "shadowsocks", "server": "your_remote_server", "server_port": 8388, "method": "aes-256-gcm", "password": "your_password" } ] }

注意auto_route设为false，因为他要手动控制路由。启动sing-box后，系统里出现了tun0，地址是10.0.0.1。

然后他开启内核IP转发：sysctl -w net.ipv4.ip_forward=1。接着配置NAT，让局域网其他机器的流量能通过他的机器出去：

bash iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o tun0 -j MASQUERADE

但这里有个陷阱：如果直接这样，所有来自192.168.1.0/24的流量都会被丢进tun0，包括他自己访问内网服务器的流量。所以他需要加一条排除规则：

bash iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.0.0/16 -o enp3s0 -j MASQUERADE

意思是：去往内网网段的流量走物理网卡直接出去，不经过tun0。

第二步：让局域网机器把网关指向他

小陈的电脑上，把默认网关从192.168.1.1改成192.168.1.100。Windows下可以用route add 0.0.0.0 mask 0.0.0.0 192.168.1.100，Linux下ip route replace default via 192.168.1.100。手机在WiFi高级设置里改网关。

改完后，小陈打开钱包，余额秒刷出来。他激动地在群里发了个“牛逼”。但李然知道，这才刚开始——因为DNS还没处理。

第三步：处理DNS泄漏和分流失效

小陈很快反馈：“李哥，钱包能连了，但有些网站打不开，提示DNS错误。”李然检查发现，小陈的DNS请求还是发给了原来的路由器192.168.1.1，而路由器可能污染了某些域名。他需要在开发机上搭一个DNS转发，并让局域网机器使用他的DNS。

他在sing-box里加了一个DNS入站，监听53端口，然后配置DNS规则：国内域名走本地DNS，国外域名走代理DNS。同时，他在iptables里加了一条：

bash iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p udp --dport 53 -j DNAT --to-destination 192.168.1.100:53

这样所有局域网机器的DNS请求都被劫持到他的机器上。小陈的电脑不用改DNS设置，自动生效。

但新的问题来了：有些应用（比如某些链上工具）会自己指定DNS服务器（比如8.8.8.8），绕过系统设置。李然又加了一条规则，强制所有去往8.8.8.8的流量也走代理：

bash iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d 8.8.8.8 -p udp --dport 53 -j DNAT --to-destination 192.168.1.100:53

第四步：应对虚拟币场景的特殊需求

李然自己跑着一个比特币全节点，还有几个监控以太坊mempool的脚本。这些程序需要大量UDP流量（比如DNS查询、P2P发现），而且对延迟敏感。他发现TUN模式默认会把所有UDP也代理走，但有些远程代理服务器对UDP支持不好（比如Shadowsocks的UDP relay可能不稳定）。

于是他做了分流：在sing-box的outbounds里加一个direct出站，然后在路由规则里把国内IP和已知的链上节点IP（比如某些交易所的API IP）直连，只有去往国外未知IP的流量才走代理。这样既保证了速度，又避免了UDP断流。

他还发现，小陈的手机上安装了某交易所App，这个App会检测代理——如果发现走了代理，就拒绝服务。但TUN模式下，App看到的是自己的流量直接发往目标IP，根本不知道中间经过了代理。因为TUN是在网络层转发，应用层完全无感。小陈试了试，果然可以正常交易了。

稳定运行一周后，李然总结的坑与技巧

一周后，团队的四台机器和两部手机全部通过李然的开发机共享代理，链上数据同步速度从原来的半分钟缩短到两秒。小陈再也不喊“李哥”了，改喊“李路由”。但李然知道，这套方案有几个必须注意的地方。

坑一：MTU问题导致大包丢失

TUN接口默认MTU是1500，但代理隧道封装后实际可用MTU会变小。李然发现小陈下载大文件时经常卡住，后来把tun0的MTU改成1400，问题消失。命令：ip link set dev tun0 mtu 1400。

坑二：局域网内其他机器无法访问开发机上的服务

因为改了网关，小陈的电脑访问李然开发机上的本地服务（比如一个测试用的API）时，流量会先到tun0，然后被路由规则绕回，可能导致失败。李然加了一条路由：在开发机上，对来自192.168.1.0/24且目标为192.168.1.100的流量，直接走本地回环。iptables里加：

bash iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d 192.168.1.100 -j RETURN

坑三：IPv6泄漏

有些链上工具会优先使用IPv6。如果代理只支持IPv4，IPv6流量就会绕过代理直接出去，导致IP泄漏。李然干脆在开发机上禁用了IPv6转发，或者用ip6tables把IPv6流量也NAT到tun0（如果代理支持IPv6）。更简单的办法：在局域网机器的网卡上禁用IPv6。

技巧：用策略路由实现按设备分流

李然后来又优化了一步：他不想让所有设备都走代理，比如那台跑回测的机器需要直连内网数据库。于是他用了策略路由——在开发机上根据源IP决定是否走tun0。具体是在iptables的mangle表里打标记，然后用ip rule配置不同路由表。这样小陈的电脑走代理，回测机直连，互不影响。

那个凌晨之后的清晨

天快亮了，李然看着监控面板上四条绿色的连接线，小陈的电脑、手机、还有那台回测机都稳定运行。比特币价格反弹了一点，他的空单回撤了些，但他不在意。他打开博客编辑器，开始写下这段经历——标题就叫《如何用TUN模式实现局域网共享代理？》。

他知道，很多做虚拟币的人都在小团队里工作，几个人共用一条网络，却各自为战地配代理。TUN模式不是银弹，但它把“共享”这件事从应用层下沉到了网络层，让那些不听话的钱包、节点、交易所App统统乖乖走同一条隧道。而这一切，只需要一台Linux机器，一个TUN接口，和几条iptables规则。

他最后在文章里写了一句：“别让你的代理只活在浏览器里。让它在网络层生根，局域网里每一台设备、每一个数据包，都会感谢你。”然后他点了发布，合上电脑，窗外已经泛白。小陈在群里发了个新消息：“李哥，今天能教我配TUN吗？”李然笑了笑，回复：“先睡觉，醒了再说。”