Nebula VPN 1.11.2 介绍与选型指南

Nebula VPN 1.11.2 网状组网 VPN 工具介绍：核心架构、证书体系、NAT 穿透与防火墙机制，及与 Tailscale/Headscale/WireGuard/NetBird 的量化选型对比，版本与社区数据取证于 2026-10-20。

Nebula VPNVPN网络配置2026/10/20

Nebula VPN 1.11.2 介绍与选型指南

目标：说清 Nebula VPN 是什么、怎么组网、适合谁用，并给出与 Tailscale、Headscale、WireGuard、NetBird 的量化选型对比。本文版本与社区数据取证于 2026-10-20（GitHub Releases atom 订阅源与仓库页实测抓取），安装与配置的完整实操见本专栏后续篇章，本篇快速开始一节的所有命令均已在 Ubuntu 22.04 实机执行并保留真实回显。

一、环境信息

本文取证与快速开始实测所用的环境如下：

  • 操作系统：Ubuntu 22.04.4 LTS（x86_64，内核带 /dev/net/tun 设备）
  • 软件版本：Nebula VPN 1.11.2（当前最新稳定版，2026-09-22 发布）
  • 安装方式：官方 GitHub Releases 二进制包（nebula-linux-amd64.tar.gz）
  • 部署形态：单机部署 lighthouse（信标）节点，systemd 托管
  • 网络参数：overlay 网段 10.99.0.0/24，underlay 监听 UDP 4242
  • 数据来源：github.com/slackhq/nebula 的 releases.atom 订阅源与仓库页 HTML，抓取日期 2026-10-20

💡 说明：Nebula VPN 是 Slack 开源、现由 Defined Networking 维护的 VPN 网状组网工具（github.com/slackhq/nebula），与站内《NebulaGraph》图数据库专栏同名异物，两者毫无关系。检索本文时认准「Nebula VPN」全称与 defined.net 官网即可避免混淆。

二、软件概述

Nebula 是一个可伸缩的网状（mesh）VPN 工具，用 Go 语言编写，目标是把分布在世界各地、位于不同 NAT 与防火墙之后的机器，组成一张基于证书身份的加密扁平网络。它最初由 Slack 开源（解决自家跨云、跨办公网机器互联的需求），2022 年起由 Slack 联合创始人成立的 Defined Networking 公司继续维护，并在此基础上提供商业托管控制面。本项目采用 MIT 协议开源，仓库页实查数据（2026-10-20）：stargazerCount 18451、forksCount 1197。

与「连上中央服务器再转发全部流量」的传统 VPN 不同，Nebula 的定位是主机间的加密组网层：每台机器运行一个 nebula 守护进程，持有一张由私有 CA 签发的证书（证书里写死了该主机的 overlay IP、所属组、有效期），节点之间通过 UDP 直接建立加密隧道，流量在节点之间点对点直达，不经过任何中心节点转发。

一句话概括它的技术画像：

维度事实（官方 Release/仓库页实测取证）
语言与形态Go 编写的单二进制守护进程（nebula）+ 证书工具（nebula-cert），v1.11.2 的 linux-amd64 tar 包 18,600,385 字节且两个二进制已合并打包
开源协议MIT（仓库页 LICENSE 标签实测）
当前稳定版v1.11.2（2026-09-22 发布，releases.atom 实查）
传输层UDP（默认端口 4242），加密基于 Noise 思想的握手（运行日志中握手风格为 ix_psk0）
身份体系自建 CA + Nebula 证书（当前默认 v2 证书格式，curve 25519）
组网形态全网状直连 + lighthouse 信标节点做地址索引，NAT 环境差时可选 relay 中继
平台支持Linux/macOS/Windows/FreeBSD 官方二进制，iOS/Android 由官方或第三方 App 提供

如何理解「全网状」与其他组网拓扑的差异，直接决定选型：

💡 技术拓展：VPN 组网拓扑主要有以下几种，Nebula 属于第一种（全网状直连）。

拓扑原理/特点代表实现适用场景
全网状 mesh节点两两直连，任意两点流量不绕行第三方Nebula、Tailscale/Headscale（数据面）节点数适中、追求低延迟点对点
中心星型 hub-spoke所有流量经中心网关转发OpenVPN、strongSwan 经典部署需要统一审计出口、访问内网服务端
中继 relay打洞失败时经中继转发，成功则回落直连Nebula relay、Tailscale DERP大量节点处于严格 NAT 之后
内核路由型不做用户态加密隧道，靠内核加密接口WireGuard固定 IP 点对点、追求极限性能

Nebula 的取舍：用 lighthouse 只做「通讯录」不做「搬运工」，数据面尽量点对点；打不通时才用 relay 兜底，因此大规模下控制面开销极低。

三、核心架构

Nebula 的架构围绕「证书即身份、lighthouse 即索引、TUN 即出口」展开。理解三个角色后，配置文件里每个段落都有了着落点。

3.1 三个核心角色

  • nebula 守护进程（每个节点一个）：负责握手、加解密、防火墙过滤、TUN 设备收发包。本文实测 v1.11.2 单节点内存占用约 9.8 MB（systemctl status 实测 Memory: 9.8M）。
  • lighthouse（信标节点）：持有全网节点的「证书 IP → 公网地址」映射表。新节点上线时向 lighthouse 汇报自己的地址，想连别人时先问 lighthouse 要地址，然后直接向对方发起握手——lighthouse 只参与控制面，不转发业务流量。一个网络至少部署一个 lighthouse，生产建议 2 个以上。
  • nebula-cert（证书工具）：签发 CA、签发节点证书、打印与校验证书。证书里写明节点 overlay IP（v2 格式叫 networks）、组（groups）、有效期，是防火墙规则与身份识别的唯一依据。

3.2 一次连接的完整流程（实测日志还原）

本机实测的 lighthouse（10.99.0.1）与 client（10.99.0.2）握手过程，两侧日志均为真实回显：

client 侧（发起方）：
time=2026-10-20T18:28:05.088+08:00 level=INFO msg="Handshake message sent" vpnAddrs=[10.99.0.1] localIndex=2297257411 remoteIndex=0 udpAddrs=[10.200.0.1:4242] initiatorIndex=2297257411 handshake="map[stage:1 style:ix_psk0]"
time=2026-10-20T18:28:05.089+08:00 level=INFO msg="Handshake message received" vpnAddrs=[10.99.0.1] from=10.200.0.1:4242 certName=lighthouse certVersion=2 fingerprint=6ba4197fd96fa91cb41bd5c74881ad61c460459e6b1f64d8e81b870d4bb5c998 issuer=d3fc0ec8573301be67e8224b622b19022ba555b63d0d6820f58dc2799b3163ce initiatorIndex=2297257411 responderIndex=2184454339 handshake="map[stage:2 style:ix_psk0]" durationNs=822435 sentCachedPackets=1

lighthouse 侧（应答方，journalctl 实测）：
nebula[1459489]: time=2026-10-20T18:28:05.088+08:00 level=INFO msg="Handshake message received" vpnAddrs=[10.99.0.2] from=10.200.0.2:4243 certName=client certVersion=2 fingerprint=b13d16e2ddaf8bb1dc710448405f94d480e0bc838f5997e62b102bae528afffc issuer=d3fc0ec8573301be67e8224b622b19022ba555b63d0d6820f58dc2799b3163ce initiatorIndex=2297257411 responderIndex=2184454339 handshake="map[stage:2 style:ix_psk0]"

流程拆解：client 从 static_host_map 拿到 lighthouse 的 underlay 地址（10.200.0.1:4242）发送 stage 1 握手；双方在 stage 2 互验证书链（日志里的 certVersion=2、fingerprint、issuer 即证书指纹与签发 CA 指纹）；隧道建立后，lighthouse 顺带把 client 的真实地址（10.200.0.2:4243）记入映射表，供其他节点查询。整个握手在一毫秒内完成（durationNs=822435 纳秒）。

3.3 数据面：加密与 NAT 穿透

  • 加密：数据包使用 ChaCha20-Poly1305 或 AES-GCM 封装（cipher 参数，双端可协商，实测见 C1 篇）；握手密钥交换基于证书里的 curve25519 公钥。
  • NAT 穿透：punchy 组件周期性向对端发送打洞包维持 NAT 映射（punch），并支持「对端主动回连」（respond）。实测开启 punch 后，单侧 NAT 后的节点可直接互通。
  • TUN 接口：nebula 在本机创建一块 TUN 网卡（默认名 nebula0，可用 tun.dev 定制），overlay IP 直接落在网卡上，路由层面与普通网卡无异。实测 ip addr show nebula0：
912: nebula0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1300 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 10.99.0.1/24 brd 10.99.0.255 scope global nebula0
       valid_lft forever preferred_lft forever

3.4 控制面：没有控制面的「控制面」

Nebula 没有常驻控制服务器。所谓控制面就是 CA 私钥签发证书 + 配置文件分发：管理员用 nebula-cert 签出每个节点的证书，连同 ca.crt、config.yaml 发放到节点即可。节点配置里只需知道 lighthouse 的 overlay IP 与 underlay 地址（static_host_map）。这是它与 Tailscale（依赖 SaaS 控制面或自托管 Headscale）最本质的差异，也是选型时最需要权衡的一点。

四、功能特性

以下特性均有对应配置段或命令行参数，全部参数的逐项实测见本专栏《Nebula VPN 1.11.2 配置参数详解》篇。

4.1 证书身份与分组授权

每张证书绑定 overlay IP、groups 组列表与有效期；防火墙规则可以按 group/groups/host/cidr/ca_name/ca_sha 精确授权，例如「只允许 laptop 组访问 443 端口」。CA 还可以用 -groups 参数限制子证书能使用的组，用 -networks 限制能分配的网段。

4.2 内置防火墙（default deny）

Nebula 自带按规则过滤的防火墙，默认拒绝一切入站与出站（inbound_action/outbound_action 默认 drop），必须显式放行。规则支持协议（tcp/udp/icmp/any）、端口（单值/范围/any）、主机、组、CIDR 多维组合。本实测验证：把 lighthouse 入站规则收窄为仅 icmp 后，client 的 TCP 请求立即被丢弃（curl 4 秒超时退出码 28），随后通过 kill -HUP 热加载恢复放行，无需重启进程。

4.3 NAT 穿透与 relay 中继

节点主动向 lighthouse 汇报地址、周期打洞（punchy.punch）、支持对称 NAT 的 respond 回连与 respond_delay；直连完全打不通时，可以把某节点配置为 relay（relay.am_relay: true），其他节点经其中转。

4.4 路由扩展：unsafe_routes

证书除自身 IP 外还可携带 unsafe_networks，允许节点作为网关把 overlay 流量路由到它身后的非 Nebula 网段（如站点内网 192.168.87.0/24），实现「连入整个站点」的效果。

4.5 可观测性

内置 graphite 与 prometheus 两种指标后端。实测在 lighthouse 开启 stats.type: prometheus 后，kill -HUP 热加载即监听 127.0.0.1:9801，日志出现 Starting prometheus stats listener addr=127.0.0.1:9801，/metrics 返回 286 行指标，包含 firewall_conntrack_count、hostmap_main_hosts、certificate_ttl_seconds 等。

4.6 平台与部署形态

官方 Release 提供 linux（amd64/arm64/arm-5/6/7/386/loong64）、darwin、freebsd 的 tar/zip 包；v1.11.2 起 tar 包内同时包含 nebula 与 nebula-cert 两个二进制。另有 iOS/Android 客户端与 Defined Networking 的商业托管控制面。

五、快速开始（最小可用示例）

以下命令在 Ubuntu 22.04 实机全部执行过，回显逐行照抄。目标是：下载官方二进制 → 签发 CA 与节点证书 → 跑起一个 lighthouse 节点。

5.1 下载官方二进制

curl -LO "https://github.com/slackhq/nebula/releases/download/v1.11.2/nebula-linux-amd64.tar.gz"

实测文件大小与官方发布页一致（18,600,385 字节）。v1.11.2 的发布件不再附带 CHECKSUMS 清单文件（发布资产实测仅含各平台 tar/zip），建议下载后记录 sha256 以便比对：

sha256sum nebula-linux-amd64.tar.gz

实测输出：

6140d33f2ec21ce7f6b655b5bc820e93a684d97e51d0ddcf907324b5b28aac1e  nebula-linux-amd64.tar.gz

5.2 解压并安装到系统路径

tar xzf nebula-linux-amd64.tar.gz
ls
install -m 0755 nebula /usr/local/bin/nebula
install -m 0755 nebula-cert /usr/local/bin/nebula-cert
nebula -version
nebula-cert -version

实测输出：

nebula
nebula-cert
Version: 1.11.2
Version: 1.11.2

5.3 签发 CA 与 lighthouse 节点证书

mkdir -p /etc/nebula
nebula-cert ca -name "Quzuo Nebula CA" -duration 87600h -out-crt /etc/nebula/ca.crt -out-key /etc/nebula/ca.key
nebula-cert sign -name lighthouse -networks "10.99.0.1/24" -groups "lighthouse" -ca-crt /etc/nebula/ca.crt -ca-key /etc/nebula/ca.key -out-crt /etc/nebula/host.crt -out-key /etc/nebula/host.key
ls -l /etc/nebula/

实测输出（命令全部静默成功，exit=0，ls 回显）：

total 16
-rw------- 1 root root 261 10月 20 18:20 ca.crt
-rw------- 1 root root 174 10月 20 18:20 ca.key
-rw------- 1 root root 326 10月 20 18:20 host.crt
-rw------- 1 root root 127 10月 20 18:20 host.key

5.4 最小 lighthouse 配置

写入 /etc/nebula/config.yaml（lighthouse 不需要 static_host_map 与 lighthouse.hosts）：

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key

lighthouse:
  am_lighthouse: true
  interval: 60

listen:
  host: 0.0.0.0
  port: 4242

tun:
  dev: nebula0
  mtu: 1300

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: any
      proto: any
      host: any

5.5 校验配置并启动

nebula -test -config /etc/nebula/config.yaml
echo "exit=$?"

实测输出节选（实测尾部，首行为完整配置回显故略；exit 为 0 表示配置可用）：

time=2026-10-20T18:21:10.771+08:00 level=INFO msg="Firewall rule added" firewallRule="map[caName: caSha: cidr: direction:outgoing endPort:0 groups:[] host:any localCidr: proto:0 startPort:0]"
time=2026-10-20T18:21:10.771+08:00 level=INFO msg="Firewall rule added" firewallRule="map[caName: caSha: cidr: direction:incoming endPort:0 groups:[] host:any localCidr: proto:0 startPort:0]"
time=2026-10-20T18:21:10.771+08:00 level=INFO msg="Firewall started" firewallHashes=SHA:498215dec4e5687a2353f51c10838c113bd1af35ef72b8e8c9f536986ada5417,FNV:2782948616
time=2026-10-20T18:21:10.771+08:00 level=INFO msg="Main HostMap created" preferredRanges=[]
time=2026-10-20T18:21:10.771+08:00 level=INFO msg="punchy enabled"
exit=0

前台启动验证监听与 TUN 网卡：

nebula -config /etc/nebula/config.yaml

实测日志（另开终端核查端口与网卡）：

time=2026-10-20T18:21:28.491+08:00 level=INFO msg=listening addr=0.0.0.0:4242
time=2026-10-20T18:21:28.491+08:00 level=INFO msg="Nebula interface is active" interface=nebula0 networks=[10.99.0.1/24] build=1.11.2 udpAddr=0.0.0.0:4242 boringcrypto=false

ss -lunp | grep 4242

实测输出：

UNCONN 0      0            0.0.0.0:4242       0.0.0.0:*    users:(("nebula",pid=1457634,fd=7))

看到 0.0.0.0:4242 的 UDP 监听与 Nebula interface is active 日志，lighthouse 即已就绪。systemd 托管、开机自启、client 节点接入与升级卸载的完整流程见《Ubuntu 22.04 安装 Nebula VPN 指南》。

六、适用场景与限制

6.1 适用场景

  • 跨云/多机房主机组网：各云厂商的内网不互通时，用 Nebula 把所有 Linux 主机拉进一张 10.99.0.0/24，服务之间直接用 overlay IP 互访。
  • 运维后门与安全隔离：SSH/数据库管理口只监听 overlay IP，配合分组防火墙（只有 ops 组能连 22 端口），公网完全不暴露。
  • 分支机构互访：站点 A/B 各部署一台 lighthouse 可达的节点，通过 unsafe_routes 把站点内网发布进 overlay。
  • 大量节点、低控制面预算：lighthouse 无状态轻量（实测单节点内存 ~10MB），不需要为控制面买单或维护数据库——对比 Headscale 需要 PostgreSQL/SQLite 与常驻服务。

6.2 限制与短板（选型前必须接受）

  • 证书分发是手工活：新增节点 = 签证书 + 发证书 + 发配置，没有自助注册、扫码入网这类体验（商业版 Defined 平台才有）。节点多且变动频繁时，运维成本线性增长。
  • 无 Web 管理界面：纯配置文件驱动，规则变更靠改 yaml + HUP/重启。
  • 移动端体验一般：iOS/Android 客户端可用，但证书导入与配置仍偏手工。
  • UDP 单协议：underlay 只有 UDP，在 UDP 被严防的网络（部分企业出口）需要自备 relay 或其他通道。

七、同类选型对比

对比口径：2026-10-20 实查各项目 GitHub 仓库页（stars/forks/license 为页面 JSON 数据实测抓取），功能维度来自各自官方文档；Nebula 版本节奏取自 releases.atom 实测（v1.10.1 2026-01-16 → v1.10.2 2026-01-21 → v1.10.3 2026-02-08 → v1.11.0 2026-07-23 → v1.11.1 2026-08-21 → v1.11.2 2026-09-22，9 个月 6 个稳定版）。

维度Nebula VPNTailscaleHeadscaleWireGuardNetBird
定位证书驱动的全网状组网工具商业级零配置组网网络Tailscale 控制面的自托管实现内核级点对点 VPN 协议/工具自托管或云控制面的组网平台
控制面无常驻服务（证书+配置分发）SaaS（可自托管 enterprise）自托管 Go 服务 + 数据库无（手工密钥交换）自托管 Go 服务（含数据库）或 NetBird 云
数据面用户态 UDP 隧道（Noise 系握手）WireGuard（用户态适配）WireGuard（官方客户端）内核态 WireGuardWireGuard
NAT 穿透punchy 打洞 + relay 中继NAT 打洞 + DERP 中继同 Tailscale（DERP 自建可选）无自动穿透（需公网可达或端口转发）打洞 + 自托管 TURN 类中继
身份/授权CA 证书 v2（IP/组/有效期内置）SSO/邮箱登录 + ACL同 Tailscale 策略静态公钥对SSO/ACO + ACL/分组
内置防火墙有（default deny，双端规则）ACL 在控制面下发同 Tailscale无（交给系统 iptables）有（控制面下发）
开源协议MITBSD-3-Clause（客户端）BSD-3-ClauseGPL-2.0（内核与工具）自定义许可（仓库 spdxId 实测 NOASSERTION）
GitHub stars（2026-10-20）18,45137,80944,825非仓库中心化项目（内核树/官网分发）30,086
forks（2026-10-20）1,1973,3752,645同上1,770
部署上手成本低-中（签证书+单配置文件）极低（登录即用）中（自建控制面+客户端配置）中（逐节点写 wg 配置）中（自建需数据库/对象存储）
站内实测文档本专栏《Tailscale 1.104 介绍与选型指南》《Headscale 介绍与选型指南》《WireGuard 1.0 工具线介绍与选型指南》暂无

关键差异与选型解读：

  • 要「零运维控制面 + 数据自主」：Nebula 最彻底——控制面退化成一次性的证书签发，没有数据库、没有常驻服务，节点数量多也不增加控制面负担；代价是没有自助入网体验。
  • 要「体验优先、允许 SaaS」：Tailscale（客户端开源、控制面托管）；在意数据主权又想要 Tailscale 体验则自建 Headscale（控制面仍需托管数据库与域名，参考 《Ubuntu 22.04 安装 Headscale 指南》）。
  • 要「内核级性能、点对点固定拓扑」：直接 WireGuard，但失去自动穿透与身份分组；两者也常组合使用（Nebula/Headscale 的数据面都是 WireGuard 思想的变体或实现）。
  • 要「自托管 + 丰富 UI + ACL」：NetBird 功能面最接近商业产品，但自托管栈更重（Go 服务 + 数据库 + 中继组件）。
  • 传统站点到站点的加密互联选 OpenVPN/strongSwan 更合适（参考 《OpenVPN 2.7 介绍与选型指南》），它们是 hub-spoke 拓扑的成熟方案，不适合做全网状。

八、参考链接