Nebula 是什么：基于证书的覆盖网络

Nebula 是覆盖网络工具：主机用证书互相认证，在现有 IP 网络上建立加密的三层隧道。它不是代理，也不是 IPsec 或 WireGuard 的配置档。截至 2026-10-10，最新正式发布是 v1.11.2（2026-09-22）。本文说明项目、许可证和结构，不含组建步骤，也不对方案排序。

Nebula 是什么

一个可独立引用的定义句：Nebula 是基于 Noise 协议框架的对等、双向认证的软件定义网络；证书用来声明节点的地址、名字，以及它属于哪些自定义分组。

官方文档给覆盖网络的定义是：跑在另一张网络上面的虚拟网络。按这个定义，VPN、SSH 隧道和云厂商的 VPC 都可以叫覆盖网络。Nebula 选择的形态是三层虚拟网：TUN 适配器承载 TCP、UDP 和 ICMP，并可以只把一部分流量送进覆盖网络。虚拟网卡的三层与二层差别见 TUN 与 TAP。

它不提供 SOCKS 或 HTTP 入口，也不根据网站域名选择出口。那是代理平台的工作，见 HTTP 代理与 VPN 有何不同。

沿革与现在的维护关系

Slack 工程博客于 2019-11-19 宣布开源。博客写明：公开时 Nebula 已在 Slack 内部使用超过两年，并运行在 Slack 的每台服务器上；当时列出的平台是 Linux、macOS 和 Windows，另有早期的 iOS 原型。同一天的 GitHub 发布标签是 v1.0.0。仓库 slackhq/nebula 的创建时间是 2019-11-16。

博客列出的创建者是 Nate Brown 与 Ryan Huber，并提到 Oliver Fross、Alan Lam、Wade Simmons、Lining Wang 的贡献。博客还写明，设计目标参考过 tinc 在难以直连的节点之间建隧道的一些策略。那是动机说明，不是对 tinc 的协议转述。

官方文档 的历史一节写着：经过数年内部开发后，Slack 于 2019 年开源；截至 2021 年 12 月，Nebula 仍支撑 Slack 超过 5 万台生产主机的全球覆盖网络。这是文档里带日期的陈述。本文没有材料证明 2026 年的规模是否仍是这个数字。

同一页写明：创建者 Ryan Huber 与 Nate Brown 于 2020 年创立 Defined Networking，以便继续开发 Nebula；Slack 仍是开源项目的主要赞助方；这份官方文档由 Defined Networking 发布。Defined Networking 的关于页把二人离开 Slack 的时间写为 2020 年 2 月。

仓库 AUTHORS 列出 Slack Technologies, Inc.、Nate Brown 与 Ryan Huber。本次读取的贡献计数中，nbrownus 与 wadey 居前。计数不是职务名单。

文档同时提到托管产品 Managed Nebula，用来区分「自己运行证书与 lighthouse」和「由 Defined Networking 托管」。那是商业服务的名称，不是开源二进制的一部分。本文不介绍其价格或适用性。

许可证

LICENSE 是 MIT 许可证，版权行为：

Copyright (c) 2018-2019 Slack Technologies, Inc.

GitHub 的 SPDX 标识是 MIT。这份抬头只覆盖 2018–2019 年。2019 年之后的提交是否在各自文件里另有版权声明，本文没有逐文件核对。

MIT 允许使用、修改和再分发，条件是保留版权声明和许可声明。它不像 GPL 那样要求衍生作品以同一许可证提供源码。这是许可证文本的差别，不是对项目的评价。

架构：证书、分组、lighthouse、TUN

官方技术概述把组件说成四块：

组件	文档中的作用
证书与 CA	互相认证。证书断言地址、名字和分组；信任来自同一证书机构
分组	用户定义的安全组，供节点上的防火墙规则引用，从而按成员身份过滤覆盖网络流量
lighthouse	发现节点。帮助对端找到彼此，并可选用 UDP 打洞穿过多数 NAT。它是查找用的主机，不是流量必须经过的中心网关
TUN	把覆盖网络呈现为一块三层虚拟网卡

发现与打洞的概念背景见 VPN NAT 穿越与打洞。lighthouse 的地址应当稳定，这是文档对发现节点的要求。示例配置注释写明监听端口默认是 UDP 4242。这只是默认值记录，不是部署步骤。

数据面在握手完成后是 AEAD。README 与文档都写：默认配置使用椭圆曲线 Diffie–Hellman，以及 AES-256-GCM。 v1.11.2 的 pki.go 在配置未写 cipher 时使用字符串 aes，并只接受 aes 与 chachapoly。示例配置注释要求全网节点使用同一种 cipher。概述里的 “AES-256-GCM” 来自 README 和文档；本次没有再往 Noise 库内部核对字符串 aes 的密钥长度。

握手框架是 Noise Protocol Framework。它是一份独立规范，不是 IETF RFC。v1.11.2 的 handshake/patterns.go 当前启用的子类型是 Noise IX（HandshakeIX，两条消息都携带载荷和证书）。同文件里的 XX 模式处于注释中，不能写成已启用。README 的概述没有点名 IX，IX 是读该标签源码得到的结论。

源码里还能看到证书 v1 与 v2 的状态对象。公开概述仍用「地址、名字、分组」描述证书，没有在引言里展开两个版本的差异。本文也不展开。

文档列出的平台

2026-10-10 的官方文档写明，Nebula 用 Go 编写，并提供 Linux、macOS、Windows、iOS、Android 与 FreeBSD 的包装。v1.11.2 的 go.mod 声明 go 1.26.0。移动端源码仓库是 DefinedNet/mobile_nebula，与 slackhq/nebula 分开。

2019 年博客里的平台列表更短。以哪一年的名单为准，要看所引用的那一页，不能把 2019 年的「早期 iOS 原型」和今天的 iOS 应用说成同一件事。

文档中的典型用途

文档把目标写成：让一组主机跨互联网安全通信，并使用类似云安全组的防火墙表达。对应的使用方式是描述，不是建议：

• 把位于不同机房、云厂商或终端上的机器放进同一块虚拟三层网络，而不改它们所在网络的编址。
• 用证书分组限制哪些节点可以互访。规则在节点本地执行，分组信息来自证书。
• 在没有稳定公网地址的主机之间，借助 lighthouse 完成发现。概述把建立之后的数据路径写成对等隧道。协议消息里另有 relay 地址字段；中继在什么条件下启用，概述没有展开，因此不能写成「流量绝不经过第三方」。

它不解决「浏览器走哪个代理」或「DNS 查询交给哪台解析器」。那些问题属于另一层。

和相关项目差在哪

项目	重心	与 Nebula 的边界
Nebula	带证书、分组和发现节点的覆盖网络	数据面与发现同属这一项目
WireGuard	精简隧道协议	身份是静态公钥，对端地址通常另行配置。见 WireGuard 与 OpenVPN 与 AllowedIPs
strongSwan / IPsec	IKE 协商与 ESP	使用 RFC 7296 等公开的 IKE/IPsec 规范，而不是 Noise。见 IKEv2 与 WireGuard
Headscale	Tailscale 控制服务器的自托管实现	官方仓库把它定义为控制面。Nebula 不是 WireGuard 的控制服务器
代理核心	入站、路由、出站	处理的是应用或透明代理的连接，不是一块给主机互访的虚拟三层网

Headscale 的许可证和维护者本文没有展开。表中只使用了其仓库描述里的那一句角色定义。

引用数字和源码结论时的界限

1. 「超过 5 万台主机」只出现在文档的 2021 年 12 月表述里。
2. 「默认 AES-256-GCM」是 README 与文档的原话；源码能确认的是默认字符串 aes，以及备选 chachapoly。
3. Noise IX 来自 v1.11.2 的 handshake/patterns.go，不是概述页的句子。换标签后要重新看该文件。
4. MIT 版权行停在 2019 年。之后的版权分布没有在本文中逐文件列出。

本文只整理公开资料。组网仍然要遵守网络所有者和当地法规的要求；这里不讨论绕过访问控制的做法。

主要资料

• 官方文档：Introduction to Nebula
• Slack 开源公告：Introducing Nebula（2019-11-19）
• 源码与发布：slackhq/nebula，标签 v1.11.2
• Noise 规范：noiseprotocol.org
• 证书与预共享密钥这一更一般的对照：预共享密钥与证书认证