Headscale：把 Tailscale 的控制面搬到自己的服务器
先说结论：自己管几台设备 → WireGuard 就够；设备多、又想让加设备变得像登录一样简单 → 用这套。
一、它解决什么问题
WireGuard 的痛点是运维：每加一台设备，要在服务端改配置、生成密钥、分配 IP、重启。十台设备之后，这份配置文件会变得难以维护。
Headscale 做的是「控制面」：设备用一次性密钥注册进来，IP 自动分配，服务端配置由它维护。数据面仍然是 WireGuard 点对点直连，不经过第三方。
二、部署
services:
headscale:
image: headscale/headscale:latest
restart: unless-stopped
ports: ["8080:8080"]
volumes:
- ./config:/etc/headscale
- ./data:/var/lib/headscale
command: serve
headplane:
image: ghcr.io/tale/headplane:latest # 可选：网页管理
restart: unless-stopped
ports: ["3000:3000"]配置文件里最重要的是两项：server_url（必须是公网可访问的 HTTPS 地址）和 ip_prefixes（虚拟内网段）。
三、加一台设备有多简单
# 服务端生成一次性密钥
headscale preauthkeys create --reusable --expiration 24h
# 客户端（手机/笔记本）
tailscale up --login-server https://headscale.你的域名 --authkey 生成的密钥两条命令，设备就进了虚拟内网，自动拿到 IP，自动能访问其他设备。这正是「体验」的价值所在。
四、ACL：谁能访问谁
默认所有设备互通。生产环境要配访问控制，否则一台被入侵的笔记本就能横向访问全部设备。
{"groups": {"admin": ["你的设备"]}}
"acls": [
{"action": "accept", "src": ["admin"], "dst": ["*:*"]},
{"action": "accept", "src": ["其他设备"], "dst": ["nas:443,22"]}
]写法的关键是默认拒绝：先只放通必要的端口，遇到问题再逐个加。
五、DNS 这件事
它内置了 DNS 能力：设备名自动解析、可以设搜索域。配置得当的话，访问内网服务只需记住 nas 而不是 IP。
但要注意：如果客户端本来有自定义 DNS（比如广告拦截），两边可能冲突，需要明确用哪一份。
六、常见的坑
- server_url 用 http 或 IP：客户端会拒绝，必须是 HTTPS 域名；
- 证书没配好：一次性密钥能生成，但设备连不上——先手动
curl验证域名可达； - 子网路由没开：想让设备访问「家里整个局域网」而不只是内网设备，需要配
--advertise-routes并在服务端批准； - 设备离线后 IP 被回收：默认策略会回收长期离线设备的地址，重新上线可能换 IP。需要固定的话把过期时间调长。
七、它不适合谁
- 只有两三台设备：直接 WireGuard，少一层服务要维护；
- 需要成熟的官方客户端体验和管理面板：官方服务在这块做得更好；
- 团队规模很大：它的管理界面和审计能力还在演进中。
基础隧道方案见 WireGuard；把服务收进内网后，外部访问入口就只剩统一认证了，见 Authelia。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论