IPv6 覆盖网络之年

# IPv6 覆盖网络之年 来源：https://www.defined.net/blog/year-of-the-ipv6-overlay-network/ Nebula 1.10 (https://github.com/slackhq/nebula/releases/) 现已发布，带来了覆盖网络（overlay network）的 IPv6 支持、单主机多 Nebula IP 地址、全新的证书格式等功能。此次发布凝聚了长达一年多的开发心血与众多 Pull Request；完整内容可查阅 Nebula v1.10 里程碑 (https://github.com/slackhq/nebula/milestone/16?closed=1) 及更新日志 (https://github.com/slackhq/nebula/releases/tag/v1.10.0)。IPv6 覆盖网络支持是我们最古老且最受期待的功能之一 (https://github.com/slackhq/nebula/issues/6)，它终于在 2025 年 12 月落地！ 您可在以下常规渠道获取 Nebula OSS 的此版本更新： - GitHub (https://github.com/slackhq/nebula/releases/) - Homebrew (https://formulae.brew.sh/formula/nebula) - Docker (https://hub.docker.com/r/nebulaoss/nebula) - iOS 和 iPadOS (https://apps.apple.com/us/app/id1509587936)（App Store 上的 Mobile Nebula） - Android (https://play.google.com/store/apps/details?id=net.defined.mobile_nebula)（Google Play Store 上的 Mobile Nebula） - 以及多种 Linux 发行版 (https://release-monitoring.org/project/89343/)。 有关本次发布的完整功能列表，请参阅 v1.10.0 更新日志 (https://github.com/slackhq/nebula/releases/tag/v1.10.0)。 ## IPv6 覆盖网络之年 IPv6 的普及 (https://en.wikipedia.org/wiki/IPv6_deployment#Major_milestones) 历程，犹如 Linux 桌面化 (https://yearofthelinuxdesktop.net/) 一般，是一场漫长的数十年跋涉 (https://blogs.cisco.com/industries/ipv6-in-2025-where-are-we)。几乎过去十年或二十年间生产的所有设备都支持 IPv6，但遵循过时安全建议的网络管理员常会禁用该协议，而老旧网络设备也可能尚未支持 IPv6。随着 IPv4 地址耗尽 (https://en.wikipedia.org/wiki/IPv4_address_exhaustion) 问题日益严峻，加之 IPv6 提供了近乎无限的地址空间，全面支持 IPv6 已成为任何现代网络解决方案的基础标配。 ### 为什么覆盖网络需要 IPv6 支持 在 Nebula 中支持 IPv6 解锁了关键能力，使网络过渡更加平滑灵活。IPv6 庞大的地址空间消除了地址冲突，解决了在连接多个存在重叠范围的 IPv4 子网时常遇到的问题，从而让 Nebula 能够无缝连接多个作业站点。此外，在当今的覆盖网络中采用 IPv6，意味着无需等待物理网络基础设施的支持，即可提前为不可避免的 IPv6 主导型未来做好准备。 ### 升级路径 将 Nebula 升级为使用 IPv6 的过程就如同 1、2、3 般简单 (https://nebula.defined.net/docs/guides/upgrade-to-cert-v2-and-ipv6/)。该过程包括将所有人升级至 Nebula v1.10、创建 v2 证书颁发机构（CA）、在所有主机上信任该 CA，并为所有主机颁发包含 IPv6 和 IPv4 覆盖网络地址的 v2 证书。之后，一个同时支持 IPv4/IPv6 的混合覆盖网络即可部署上线。 此方案的优势在于过渡期间可同时运行两种证书格式，确保您的网络实现零停机。详细步骤请参阅我们关于如何升级 OSS Nebula 网络的全面指南 (https://nebula.defined.net/docs/guides/upgrade-to-cert-v2-and-ipv6/)。 ## 全新证书格式 为了支持 IPv6 及主机多 IP 地址分配，我们引入了全新的 v2 证书格式，底层数据序列化从 Protocol Buffers (https://protobuf.dev/) 转向了 ASN.1 (https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One)。原有的 v1 格式 (https://github.com/slackhq/nebula/blob/v1.10.0/cert/cert_v1.proto) 缺乏真正的标准序列化表示法，且仅支持 IPv4 地址。新的 v2 格式 (https://github.com/slackhq/nebula/blob/v1.10.0/cert/cert_v2.asn1) 彻底解决了这些问题。Nebula v1.10.0 通过统一接口同时支持这两种格式，允许主机在过渡期同时携带两种类型的证书，从而实现无缝迁移。 技术细节方面，Protobufs 并非规范化的序列化格式。这意味着任何负责处理网络传输格式的组件，在反序列化时都可能与 CA 签名时的序列化结果不一致，从而导致签名失效。该问题在实际应用中虽从未爆发，但在开源初期（slackhq/nebula#14 (https://github.com/slackhq/nebula/issues/14)）就已引起重视。 这主要源于我们在握手阶段会将公钥从证书中提取出来，因为 Noise 协议头已包含该信息，从而节省了网络传输带宽。接收方从 Noise 头中提取公钥，将其重新放入证书结构体并进行序列化，随后验证签名。如果 Protobuf 对结构体的序列化方式随版本发生变化，就会导致证书无效。 ASN.1 支持多种序列化方法，但我们采用了规范化（canonicalized）的一种。此外，我们将公钥移出了详情信封区，因此不再需要像以前那样重新序列化证书的详情部分。最终成果是一种更具前瞻性的格式。 ### 单主机多 IP 地址 v2 证书格式还支持为单个主机分配多个覆盖网络地址，包括同时配置 IPv4 和 IPv6，或配置多个同类型地址。这对于需要在 Nebula 网络内跨多个子网可达的主机非常有用。 ``` # 签发同时包含 IPv4 和 IPv6 覆盖网络地址的 v2 证书 nebula-cert sign -name "myhost" -networks "10.10.0.1/24, fd00:10:10::1/64" -ca-crt ca.crt -ca-key ca.key ``` `-networks` 参数中的每个地址都会成为该主机的一条可路由覆盖地址，为您在覆盖网络内进行子网划分和服务组织提供灵活性。 ## 破坏性变更与重要更新 ### 防火墙行为变更 **已弃用：**`firewall.default_local_cidr_any` (https://nebula.defined.net/docs/config/firewall/#firewalldefault_local_cidr_any) 默认值现改为`false`。此变更提升了安全性，要求针对`tun.unsafe_routes` (https://nebula.defined.net/docs/config/tun/#tununsafe_routes) 的防火墙规则必须显式声明`local_cidr`。该配置项将在后续版本中被移除。 **变更说明：** - **旧行为** (`true`)：除非显式限制，否则所有防火墙规则均应用于所有配置的 unsafe_routes - **新行为** (`false`)：仅当显式指定`local_cidr`时，规则才应用于 unsafe_routes 此变更使防火墙规则的行为更加可预测，并防止意外访问 unsafe_routes。 **这对您的影响：**如果您正在使用`tun.unsafe_routes` (https://nebula.defined.net/docs/config/tun/#tununsafe_routes)（通常用于访问 Nebula 网络之外的资源），则需要更新防火墙规则以使其更具体。以下是变更示例： ``` # 旧行为（隐式，可能存在安全风险） firewall: default_local_cidr_any: true # 旧默认值 inbound: - port: 22 proto: tcp groups: ["ssh-access"] # 此规则将应用于 ALL unsafe_routes # 新行为（显式，更安全） firewall: default_local_cidr_any: false # 新默认值 inbound: - port: 22 proto: tcp groups: ["ssh-access"] local_cidr: "192.168.1.0/24" # 显式指向此 unsafe_route ``` ## 其他新功能 ### 企业级安全增强 **P256 密钥的 PKCS#11 支持** (PR#1153 (https://github.com/slackhq/nebula/pull/1153), PR#1482 (https://github.com/slackhq/nebula/pull/1482))：当使用`pkcs11`标签构建 Nebula 时，现在支持存储在硬件安全模块 (HSMs) (https://en.wikipedia.org/wiki/Hardware_security_module) 或智能卡 (https://en.wikipedia.org/wiki/Smart_card) 中的 P256 椭圆曲线密钥。这使得企业部署能够满足严格的密钥管理要求，确保私钥永远不会以明文形式存在于软件中。更多详情请参阅 `pki.key` PKCS#11 支持文档 (https://nebula.defined.net/docs/config/pki/#pkcs11-support)。 要使用 PKCS#11 支持： ``` # 使用 PKCS#11 支持编译 Nebula make bin-pkcs11 ``` ``` # 使用 PKCS#11 密钥引用进行配置 pki: ca: ca.crt cert: host.crt key: "pkcs11:token=MyToken;object=MyKey" # PKCS#11 URI 格式 ``` ### 高级路由功能 **unsafe_routes 的 ECMP 支持** (PR#1332 (https://github.com/slackhq/nebula/pull/1332))：等成本多路径路由 (Equal-Cost Multi-Path routing) (https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing) 现已适用于 unsafe_routes，为每个订阅该 unsafe_route 的主机提供基础负载均衡与冗余能力。您现在可以为同一主机的相同路由配置多个网关，并可选择性地设置权重以实现非均衡负载分配。更多详情请参阅 `tun.unsafe_routes` ECMP 配置文档 (https://nebula.defined.net/docs/config/tun/#ecmp-support-for-unsafe_routes)。 ``` unsafe_routes: # 多个网关，权重相等（默认权重为 1） - route: 192.168.100.0/24 via: - gateway: 10.0.0.1 - gateway: 10.0.0.2 # 多个网关，自定义权重 - route: 192.168.101.0/24 via: - gateway: 10.0.0.1 weight: 10 - gateway: 10.0.0.2 weight: 5 ``` 该实现采用哈希阈值映射 (hash-threshold mapping) (https://tools.ietf.org/html/rfc2992)（类似于 Linux 内核机制），基于数据包哈希来分发流量。当某个网关不可达时，流量会自动故障转移至剩余的可用网关。不过，在这种基础负载均衡机制下，直到故障网关恢复之前，流量分布可能会变得不均匀。 ### Linux 网络集成 **SO_MARK 套接字选项支持** (PR#1331 (https://github.com/slackhq/nebula/pull/1331))：在 Linux 系统上，Nebula 现在可以使用 `SO_MARK 套接字选项` (https://www.man7.org/linux/man-pages/man7/socket.7.html#:~:text=SO_MARK%20(since%20Linux,Linux%205.17)%20capability.) 对数据包进行标记，以启用高级路由场景。这对于在不使用复杂的网络命名空间 (network namespaces) (https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html) 的情况下实现完整子网路由（包括 `0.0.0.0/0`）尤为有用，允许管理员通过自定义路由表转发 Nebula 流量。更多详情请参阅 `listen.so_mark` 文档 (https://nebula.defined.net/docs/config/listen/#listenso_mark)。 ``` # 使用防火墙标记 4242 标记 Nebula 数据包（选择与 Nebula 关联的数字即可） listen: so_mark: 4242 ``` ### 增强的库集成能力 **面向嵌入使用的可配置日志记录与版本控制** (PR#1239 (https://github.com/slackhq/nebula/pull/1239))：以库的形式集成 Nebula 并结合用户态网络的项目，现在可以配置日志记录器与构建版本号。这对于希望保持日志模式一致或在遥测数据中跟踪特定 Nebula 版本的应用程序尤其有用。 过去在将 Nebula 作为库集成时，调用 `service.New(config *config.C) (*Service, error)` 无法配置日志记录器或构建版本。现在，`service.New` 要求先通过 `nebula.Main` 构造 Nebula 控制对象，该控制对象允许传入自定义构建版本和日志记录器，然后再将控制对象传入 `service.New(control *nebula.Control) (*Service, error)`。 --- Nebula v1.10 已准备就绪，迎接网络的新纪元！我们对覆盖网络引入 IPv6 支持感到无比兴奋，也希望您同样如此。无论您是运营小型团队网络，还是管理大规模基础设施，此次发布都为您提供了构建面向未来、灵活且安全的网络的工具。 准备好升级了吗？请查阅升级指南 (https://nebula.defined.net/docs/guides/upgrade-to-cert-v2-and-ipv6/)，开始在你的 Nebula 网络中使用 IPv6。如果您对参与 Nebula 的未来发展感兴趣，GitHub 仓库 (https://github.com/slackhq/nebula) 始终欢迎 Pull Request 与反馈。