最近在折腾一个项目：WG-FRIEND
一句话介绍：
Semantic WireGuard/BoringTun lifecycle and client management helper
它的出发点其实很简单： 我这边最近比较常见的几个场景，是需要一台比较稳定的服务器做跨网络访问，需要远程回家，也需要把多台设备之间的 WireGuard 生命周期管理得更清楚一些。
但我一直觉得，现有这类方案里有个空档：
wg-quick 很好用，但更像“把接口拉起来”的工具所以用 Rust 实现 的 wg-friend 就此开始：将“拉起接口 / 管理服务 / 管理客户端 / 导入历史资产 / 做诊断”这些事情，从零散脚本提升成一个语义更明确的 control plane 。
目前这个项目主要做了几件事：
命令面我切成了四组：
serverclientservicedoctor我不太想继续沿用“全靠 shell 拼起来”的方式，而是想把常用动作收敛成更稳定的 CLI 语义。
wg-friend 会把可完整物化的客户端，纳入 /etc/wg-friend 下面的 canonical state 。
也就是说，进入管理域的前提不是“这个客户端貌似存在过”，而是它必须足够完整，能产出：
很多现有机器并不是从零开始的，已经有 /etc/wireguard、有过去导出的 client conf 、也可能混着 PiVPN 或手工维护的文件。
所以我做了 client import，去扫描本地已有客户端配置，校验完整性，推导公钥，对上 server peer set ，然后再写入 wg-friend 的 canonical state 。
我更希望这个项目能做的是：
让旧部署渐进迁移，而不是推倒重来。
这里我比较明确的设计是：
协议实现、服务托管、运维语义，这三层最好不要混成一团。
这个项目是 Rust 写的。 我没有做 TUI ，而是更偏向：
我想做的不是“一个很炫的界面”，而是一个真正能放到服务器上长期跑的 WireGuard/BoringTun helper 。
我现在对它的定位，大概就是：
BoringTun 不做 manager ，那这一层我来做。
如果你也有下面这些场景：
wg-quick + shell 更清晰一些欢迎看看，也欢迎直接拍砖。
目前还是比较早期，主要先把管理模型、状态模型和生命周期边界打清楚。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。