userspace tsnet 不给宿主机路由：一个容易踩的组网坑

问题现象

一台机器用 userspace 模式的 tsnet 加入了自建 Headscale 组网，节点状态正常、控制面能看到它、其它节点也 ping 得通。但这台机器自己去访问组网内的其它地址，一律超时。

原因

userspace 模式的 tsnet 不创建 TUN 网卡、不改系统路由表。它提供的是进程内的网络栈——只有调用 srv.Dial() 的那个 Go 程序自己能走组网，同一台机器上的其它进程（浏览器、curl、Python）完全感知不到它的存在。

同理，用 srv.Listen() 监听的端口也只存在于组网里。在本机 lsof -i 是看不到这个监听的，127.0.0.1 也连不上——因为它压根没绑到本地网络栈。

怎么验证

最快的判据是看监听：如果代码用的是 srv.Listen 而不是 net.Listen，那这个端口就只在组网内可达。本机访问必然失败，跟防火墙、DNS、ACL 都没关系。

解法

加一层本地转发：在同一个进程里用 net.Listen 监听回环地址，把连进来的流量用 srv.Dial() 转发到组网目标。这样本机其它进程连 127.0.0.1:PORT 就等于连上了组网里的服务。

只绑回环，不要绑 0.0.0.0——那等于把组网内的服务开放给整个局域网。

为什么仍然选 userspace

既然有这个限制，为什么不用内核态？因为一个系统守护进程通常只能连一个控制面。机器上已经跑着连别处的客户端时，切控制面会把原来的连接全部弄丢。userspace 旁挂的代价就是要自己搭这层转发，换来的是互不干扰。