BoringTun 不做 manager，那我用 Rust 做一个： WG-FRIEND

最近在折腾一个项目：WG-FRIEND

一句话介绍：

Semantic WireGuard/BoringTun lifecycle and client management helper

它的出发点其实很简单： 我这边最近比较常见的几个场景，是需要一台比较稳定的服务器做跨网络访问，需要远程回家，也需要把多台设备之间的 WireGuard 生命周期管理得更清楚一些。

但我一直觉得，现有这类方案里有个空档：

• wg-quick 很好用，但更像“把接口拉起来”的工具
• PiVPN 这类方案很适合快速起量，但整体还是偏 shell/script orchestration
• BoringTun 很强，尤其是 Rust userspace WireGuard 这条路线很有价值，但它本身并不负责 manager / control plane

所以用 Rust 实现 的 wg-friend 就此开始：将“拉起接口 / 管理服务 / 管理客户端 / 导入历史资产 / 做诊断”这些事情，从零散脚本提升成一个语义更明确的 control plane 。

目前这个项目主要做了几件事：

1. 把 WireGuard/BoringTun 的操作语义化

命令面我切成了四组：

• server
• client
• service
• doctor

我不太想继续沿用“全靠 shell 拼起来”的方式，而是想把常用动作收敛成更稳定的 CLI 语义。

2. 不再把客户端状态散落在各处

wg-friend 会把可完整物化的客户端，纳入 /etc/wg-friend 下面的 canonical state 。

也就是说，进入管理域的前提不是“这个客户端貌似存在过”，而是它必须足够完整，能产出：

• 元数据
• 标准导出配置
• QR-ready payload

3. 给历史部署一条 import 路径

很多现有机器并不是从零开始的，已经有 /etc/wireguard、有过去导出的 client conf 、也可能混着 PiVPN 或手工维护的文件。

所以我做了 client import，去扫描本地已有客户端配置，校验完整性，推导公钥，对上 server peer set ，然后再写入 wg-friend 的 canonical state 。

我更希望这个项目能做的是：

让旧部署渐进迁移，而不是推倒重来。

4. 明确和 systemd / BoringTun 的职责边界

这里我比较明确的设计是：

• systemd 去负责长期进程监督
• wg-friend 去负责 preflight / configure / verify / cleanup
• BoringTun 去负责 userspace WireGuard tunnel
• wg-friend 不去碰协议实现，而是做 manager/control plane

协议实现、服务托管、运维语义，这三层最好不要混成一团。

5. Rust 实现，不做 TUI ，优先可维护性

这个项目是 Rust 写的。 我没有做 TUI ，而是更偏向：

• 命令优先
• 缺参时再 prompt
• 输出尽量语义化
• 诊断尽量可读
• systemd 场景下行为尽量稳定

我想做的不是“一个很炫的界面”，而是一个真正能放到服务器上长期跑的 WireGuard/BoringTun helper 。

我现在对它的定位，大概就是：

BoringTun 不做 manager ，那这一层我来做。

如果你也有下面这些场景：

• 需要一台稳定的服务器承载 WireGuard/BoringTun
• 有远程回家需求
• 有多客户端管理、导出、二维码分发需求
• 机器上已经有历史 WireGuard 资产，不想推倒重来
• 希望整个 lifecycle 比 wg-quick + shell 更清晰一些

欢迎看看，也欢迎直接拍砖。

目前还是比较早期，主要先把管理模型、状态模型和生命周期边界打清楚。