我不想重复造轮子：HMN、Headscale 和安全托管网络的下一步

发布时间：2026-05-09 更新方向：Hermes Managed Network / Headscale / Agent 运维 / 安全托管

这两天我在整理 Hermes Managed Network，也就是 HMN 的推进顺序。

一开始我想做的是一套“让 Agent 帮我托管服务器”的系统。但梳理下来之后，我越来越确定一件事：

HMN 不应该重复造底层组网轮子。

网络连通、NAT 穿透、虚拟内网、ACL、节点身份，这些事情已经有非常成熟的方案，比如 Headscale / Tailscale。HMN 真正应该做的是另一层：

谁可以接入，谁能执行什么动作，什么动作需要审批，所有操作如何审计，资产文档如何沉淀。

所以现在的方向很明确：

Headscale / Tailscale 负责“机器怎么连上”
HMN 负责“连上之后谁能做什么”

一、我现在想要的架构边界

目前重新梳理后的架构是这样的：

Telegram / CLI / API
        ↓
HMN Core
  - node registry
  - token lifecycle
  - policy / approval
  - task queue
  - component lifecycle
  - audit
  - docs state
        ↓
Network Provider Adapter
  - headscale
  - tailscale SaaS（后续）
  - none / direct IPv6
        ↓
Execution Layer
  - worker pull
  - SSH executor over Tailscale IP（后续）
  - playbook runner
        ↓
Managed Nodes / NAS
  - full-worker
  - lite-worker
  - beacon-only
  - proxy-managed

这里最重要的分界线是：

• HMN Core 不直接实现 VPN。
• HMN Core 不直接理解 Headscale 的内部细节。
• Headscale 只是 network provider。
• 高风险动作必须走审批和审计。
• 无公网节点优先走主动 Pull，不开放入站端口。

这样可以避免系统越写越乱。

二、当前已经完成到哪里

当前 HMN 的控制面 MVP 已经有了基础能力：

• FastAPI controller
• SQLite persistence
• join token / node registry
• pending → managed 节点生命周期
• heartbeat
• worker pull task
• task result submit
• audit log
• component registry / lifecycle MVP
• reverse-proxy / forwarder / monitor manifest MVP

也就是说，现在不是纯设计稿了，已经有一个能跑起来的控制面骨架。

但它还不是完整的“托管组网平台”。接下来最重要的不是急着堆功能，而是先把核心安全边界补齐。

三、为什么 Headscale 不是一开始就硬接

Headscale 很重要，而且一定要接。

但我不想一开始就把它塞进 Core 里。原因很简单：HMN 自己的安全边界还要先稳住。

比如这些问题必须先回答清楚：

• join token 被撤销后，还能不能接入？
• node 被 revoke 后，还能不能 heartbeat？
• revoked node 还能不能拉 task？
• worker protocol 不兼容时，是否还能拿任务？
• 高风险操作到底怎么进入审批？
• 所有 decision 有没有 audit？

如果这些没稳住，先把网络打通反而危险。

网络通了，但权限、撤销、审计和审批没跟上，就会变成一个“很好用但没有保险”的系统。

四、我现在按优先级这样推进

Phase 0：PR 收尾与状态同步

先把当前 MVP 的真实状态写清楚。

已经完成的就标记完成，没完成的拆成明确任务。比如：

• join token 创建已完成
• join token 撤销 / 过期 UX 还没完成
• node registry 已完成
• SQLite 存储已完成
• audit log 已完成
• SSH executor 未完成
• Telegram approval flow 未完成

这一步看起来像文档工作，但其实很重要。因为后续所有开发都要基于这张地图推进。

Phase 1：核心安全闭环

这一阶段优先级最高。

要补的是：

1. Token lifecycle 加固

• token revoke
• token expiry
• token list 状态展示
• revoked / expired token 无法 join

1. Node revoke enforcement

• revoked node 不能 heartbeat
• revoked node 不能 poll task
• revoked node 不能 submit result

1. Offline node handling

• 根据 heartbeat 判断 online / offline / warn
• node status 展示 last heartbeat
• worker-status 对超时节点返回 warning

1. Worker auth / task safety

• 只有 managed node 能拿任务
• wrong fingerprint 不能 poll/submit
• incompatible worker protocol 不能拿任务

这一阶段完成后，HMN Core 才算比较稳。

Phase 2：审批状态机雏形

接 Telegram 审批之前，先把 approval 数据模型和 CLI 做出来。

我希望先有：

pending → approved / rejected / expired

再配套：

hmn approval list
hmn approval show <ID>
hmn approval approve <ID>
hmn approval reject <ID>

风险策略也要先定清楚：

low       自动执行 + 审计
medium    默认汇报，可配置自动执行
high      必须审批
critical  默认拒绝

这样后面 Telegram 只是一个入口，不会变成核心状态来源。

Phase 3：Headscale Network Provider MVP

这一步开始正式接 Headscale。

但它应该作为 provider adapter，而不是写死进 HMN Core。

目录可以类似这样：

src/hermes_managed_network/network/
  __init__.py
  base.py
  headscale.py

Core 只依赖通用接口：

NetworkProvider.create_preauth_key()
NetworkProvider.list_nodes()
NetworkProvider.expire_node()
NetworkProvider.apply_tags()
NetworkProvider.get_node_status()

第一版只做最小能力：

• hmn network status
• hmn network sync
• hmn network preauth-key create
• hmn wake --network headscale
• node 记录关联 Headscale node id / tailnet IP / tags / online state
• 所有操作写 audit

第一版暂时不做：

• 复杂 ACL 生成器
• 多租户 tailnet
• exit node 自动化
• subnet router 自动化
• 自动让所有节点互通

先把边界打稳。

Phase 4：Headscale + Executor 联动

Headscale 接上后，下一步才是把 SSH executor 接进来。

这时 SSH 不再依赖公网地址，而是走 Tailscale IP：

HMN Master
  ↓ Headscale/Tailscale IP
Managed Node

这一步要做：

• SSH executor 使用 Tailscale IP
• node status 同时展示 HMN 状态和 Headscale 状态
• component verify 可以通过内网 IP 做只读探测
• 高风险 SSH/playbook action 必须进入 approval

这样就不会重复造轮子，又能把 Headscale 提供的网络能力纳入 HMN 的审批和审计体系。

Phase 5：NAS / IPv6 接入优化

我这边还有一个具体场景：无公网 IPv4 的 NAS，但它有 IPv6。

这个场景不急着插队，但要记录下来。

原则是：

NAS Worker 主动出站
  → HTTPS / IPv6
HMN Master / Headscale

即使 NAS 有公网 IPv6，也不应该开放 NAS 入站端口。还是走 Worker Pull：

• NAS 主动 heartbeat
• NAS 主动 poll task
• NAS 主动 submit result

后续要补：

• IPv6 URL 的 join-command 测试
• NAS IPv6 接入文档
• endpoint fallback
• lite-worker / cron installer
• 群晖、QNAP、OpenWrt 等无 systemd 环境适配

Phase 6：组件真实能力

最后再推进真实组件。

现在 reverse-proxy / forwarder / monitor 还是 manifest 和生命周期 MVP。后面要逐步变成真实能力：

• monitor：展示 uptime、load、memory、disk、mount、docker facts
• reverse-proxy：Caddy driver MVP
• forwarder：gost / frp / socat driver MVP
• backup：include/exclude、dry-run、checksum、结果写文档
• docs-sync：机器文档、服务文档、域名索引

这一层要等 Core、审批、网络层稳了之后再做，不然真实改机器会很危险。

五、我对时间的判断

按现在进度，比较现实的时间表是：

一周内：
  HMN Core 安全边界补齐

两周内：
  Headscale 接入 + 初步内网执行能力

一个月内：
  NAS、monitor、backup、docs-sync 形成较完整托管闭环

这里的重点不是“快点把功能全写完”，而是每一步都能撤销、能审计、能解释。

因为我想要的不是一个会执行命令的机器人。

我想要的是一套可以长期托管自己机器和服务的安全控制面。

六、当前推进顺序

最终我把后续开发顺序定成这样：

1. docs: sync roadmap and add priority plan
2. feat: harden token lifecycle
3. feat: enforce revoked node access boundaries
4. feat: add offline node status
5. feat: add approval state machine MVP
6. feat: add headscale network provider MVP
7. feat: use headscale identity for SSH executor
8. feat: improve NAS IPv6/lite-worker onboarding
9. feat: add monitor facts dashboard
10. feat: add backup and docs-sync components

这个顺序的核心逻辑是：

先安全边界
再审批
再网络层
再执行器
最后真实组件

这样 HMN 才不会变成又一个“能连上机器但不知道能不能安全操作”的工具。

它应该是一个真正可托管、可扩展、可审计的运维控制面。