Headscale 还是 Nebula？自建虚拟内网在实际部署中的权衡与选择
首先聊聊 Headscale。它本质上是 Tailscale 控制面（Coordination Server）的开源实现。在 Headscale 的架构中，中心服务器扮演的是“协调者”角色，负责分发密钥和下发 ACL 策略，而实际的数据传输则通过 WireGuard 协议在节点之间建立隧道。
Headscale 最大的优势在于其极强的 NAT 穿透能力。在实际部署中，很多节点处于对称型 NAT 之后，很难实现点对点直连。此时 Headscale 的 DERP（Detoured Encrypted Routing Protocol）中继机制就成了救命稻草。即便无法直连，流量也可以通过 DERP 服务器中转，确保连通性。对于一个只有几十到几百个节点的团队，或者需要频繁通过 SSH、Web UI 远程管理内网设备的开发者来说，这种“只要能连通就行”的体验是至关重要的。
但 Headscale 并非没有短板。由于其依赖中心化控制面，一旦控制服务器宕机，虽然已建立的连接可能暂时维持，但新节点的加入或密钥更新将全部失效，形成了潜在的单点故障。更关键的是，当节点规模进一步扩大时，由于每个节点都需要维护与其他节点的隧道状态，资源消耗会呈现 $\text{O}(n^2)$ 的增长趋势，这在超大规模集群中会导致严重的性能瓶颈。
相比之下，Nebula 走的是完全不同的分布式路线。它引入了 Lighthouse（灯塔）的概念，灯塔的作用极其纯粹：它不参与数据传输，也不管理复杂的策略，仅仅是一个“地址簿”，告诉节点 A 此时节点 B 的公网 IP 是什么。一旦两个节点通过灯塔完成了握手，后续的流量完全点对点传输。值得注意的是，Nebula 并没有采用 WireGuard，而是使用了自己的一套加密协议。
Nebula 的核心竞争力在于其恐怖的扩展性。因为它基于证书认证（Certificate-based authentication），身份管理非常硬核，能够支撑成千上万个节点而不会出现性能崩溃。这使得它非常适合大规模服务器集群或跨地域的站点间连接。
然而，Nebula 的门槛显著高于 Headscale。首先，它缺乏像 DERP 那样的内置中继机制。这意味着如果两个节点之间因为防火墙策略或 NAT 类型死活穿不透，它们之间就彻底无法通信，没有任何兜底方案。其次，Nebula 几乎没有图形化界面，所有操作都依赖 CLI。在部署时，你需要手动生成 CA 证书、为每个节点签发证书，并编写复杂的 YAML 配置文件。对于不习惯命令行操作的团队来说，这确实是一个痛苦的过程。
总结来看，这两者的选择逻辑其实很简单。如果你追求的是“快速部署、极致体验、必须保证连通”，且节点规模在数百台以内，Headscale 是最优解。而如果你正在构建一个超大规模的自动化基础设施，对单点故障极其敏感，且团队有能力处理复杂的证书管理，那么 Nebula 才是真正的生产力工具。
