OpenZiti 介绍与选型指南

一、环境信息

本文为 OpenZiti 的认知与选型篇，信息以官方公开资料为准，检索与核对日期为 2026-10-20。

OpenZiti 的版本迭代节奏较快：v1.0 于 2025 年发布并带来生产级 HA 控制器；官方博客《Announcing OpenZiti v2.0》（更新于 2026-06-30）宣布 v2.0 正式可用，当前主线为 2.0.x 系列并持续发布补丁版本（2.0.8 为 2026-10-08 构建的最新稳定版）。

二、软件概述

OpenZiti 是一个 开源的零信任网络覆盖层（zero trust network overlay）。它的核心思路与传统 VPN 不同：不是把用户"接入网络"，而是把应用程序之间的连接作为一等公民来管理——应用通过身份证书接入覆盖层，按服务名拨号到目标服务，全程 mTLS 端到端加密。

从运维视角看，OpenZiti 带来三个与传统组网工具的本质差异：

1. 服务端不需要开放监听端口。服务不被发布成 IP:端口，而是作为 overlay 中的"服务对象"存在。只有持有合法身份且被策略授权的客户端才能发起连接，网络扫描器根本看不到服务端口（官方称之为 dark services / 零信任暗服务）。
2. 身份即防火墙。访问控制基于证书身份 + 服务级策略（谁可以 dial 谁可以 bind），而不是 IP 地址和网段。客户端换网络、换 IP 不影响授权。
3. 两种接入形态。既可以用 Tunneler（隧道器，如 ziti-edge-tunnel，通过 TUN 设备 + 本地 DNS 拦截实现无改造接入），也可以用 OpenZiti SDK（Go/C/Java/Rust 等语言）直接改造应用，实现身份注入到进程级别。

OpenZiti 由 NetFoundry 发起并持续投入，采用 Apache-2.0 协议开源，主体为 Go 编写（v2.0.8 使用 Go 1.27 构建，本地实测 ziti version -v 可见），同时提供面向嵌入场景的多语言 SDK。

三、核心架构

OpenZiti 采用 controller / router / tunneler 三角色架构，组件间用 mTLS 通信：

服务（Service） 是贯穿整个体系的中心抽象。管理员先定义服务，再用三类策略把"身份"与"服务"连接起来：

• Service Policy：授予身份对服务的 Dial（访问）或 Bind（托管）权限；
• Edge Router Policy：授予身份可使用的边缘路由器；
• Service-Edge-Router Policy：限定服务经由哪些边缘路由器可达。

实测提示：v2.0 起不再默认创建面向 #all 的 Edge Router Policy 与 Service-Edge-Router Policy，手工部署后必须显式创建这两类策略，否则隧道器拨号会报 NO_EDGE_ROUTERS_AVAILABLE。这是 v2 与 v1 部署差异最大、也最容易踩坑的一点（本专栏安装篇有完整排障实录）。

托管（Bind）与拦截（Intercept） 是服务流量的两端：

• 服务端在 host.v1 配置中声明"本路由器/隧道器把流量转发到本机 127.0.0.1:端口"；
• 客户端在 intercept.v1 配置中声明"访问 服务名.svc.ziti:80 时劫持进 overlay"。

整个链路为：客户端应用 → ziti-edge-tunnel（TUN 拦截）→ edge router（mTLS 接入）→ overlay 寻址 → 承载端 edge router / tunneler → 本地后端服务。

身份与认证：所有组件（含路由器、隧道器）都以 X.509 证书作为身份，通过 enrollment token（JWT）注册获取客户端证书；v2.0 默认走 OIDC/JWT 认证流，并支持 MFA、外部 JWT Provider、posture check（终端安全状态检查）等扩展。

v2.0 的重要变化（官方博客，2026-06-30 更新）：

• 控制器集群（多副本 Raft）达到生产就绪状态，可整体暴露为单一高可用控制面；
• 全新权限模型（beta）支持更细粒度的操作授权；
• SDK 客户端认证默认切换到 OIDC，支持 JWT 注册；
• 控制器 API 可绑定在 overlay 之上（管理面也可以走 overlay 访问，实现"暗管理面"）；
• CLI 重组：ziti edge 下的常用实体命令提升为顶层命令（如 ziti list、ziti create），原 ziti edge list 等仍可用但属过渡形态；ziti controller init 被移除，改为 ziti agent cluster init。

四、功能特性

1. 零暴露面：被保护服务不监听公网端口，扫描不可见；控制器与路由器只暴露 mTLS 端点，拒绝未持证书的连接。
2. 服务级访问控制：以服务为最小授权单元，支持按属性（#标签）、按身份名（@名称）通配编排；配合 posture check 可要求终端合规后才可访问。
3. 端到端加密 + 双重 TLS：客户端到边缘路由器一段 TLS，overlay 内部 xgress 再加密一段，中间节点无法窥探明文。
4. 高可用控制面：v2.0 基于 Raft 的多控制器集群，官方部署指南给出从单节点到三节点的扩展路径（ziti agent cluster add）。
5. 多形态接入：Linux/Windows/macOS 图形与命令行隧道器、Docker/Kubernetes 发行形态、多语言 SDK，可按"不改应用 / 少改应用 / 深度改造"三档投入选型。
6. DNS 与路由自动化：隧道器默认接管 100.64.0.0/10 网段与服务名解析；Ubuntu 上与 systemd-resolved 集成（本专栏实测通过 systemd-resolved 全局解析链路验证）。
7. 可观测与运维：策略顾问（ziti edge policy-advisor）可一键诊断"某身份为何访问不了某服务"；ziti agent 子命令支持集群运维；REST API 与 Web Console 皆可管理。

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

方式一（推荐，5 分钟体验）：官方一键 quickstart。在完成安装（见站内《Ubuntu 22.04 安装 OpenZiti 指南》）后，执行官方文档给出的体验命令：

# 官方 quickstart：单机拉起 controller + router，并自动完成注册（官方文档流程，2026-10-20 查询）
ziti edge quickstart

quickstart 会打印默认管理员口令与控制台地址，随后即可在控制台里定义服务。

方式二（本专栏实测的最小闭环）：手工安装 controller + router + ziti-edge-tunnel 三件套后，按以下顺序创建第一个服务（完整命令与实测回显见安装篇）：

# 1. 登录控制面
ziti login https://127.0.0.1:1280 -u admin -p '你的口令' -y

# 2. 定义服务（host.v1 托管本机 8000 端口，intercept.v1 拦截 webtest.svc.ziti:80）
ziti create config webtest-host host.v1 '{"protocol":"tcp","address":"127.0.0.1","port":8000}'
ziti create config webtest-int intercept.v1 '{"protocols":["tcp"],"addresses":["webtest.svc.ziti"],"portRanges":[{"low":80,"high":80}]}'
ziti create service webtest -a webtest -c webtest-host,webtest-int

# 3. 授权：路由器承载（Bind）、终端身份访问（Dial）、路由器可达（v2 必须显式创建）
ziti create service-policy webtest-bind Bind --service-roles "#webtest" --identity-roles "@ziti-er1"
ziti create service-policy webtest-dial Dial --service-roles "#webtest" --identity-roles "#dialers"
ziti create service-edge-router-policy all-serp --edge-router-roles "#all" --service-roles "#all"
ziti create edge-router-policy all-erp --edge-router-roles "#all" --identity-roles "#all"

# 4. 客户端侧通过 ziti-edge-tunnel 接入后，直接访问服务名即可
curl http://webtest.svc.ziti/

在 Ubuntu 22.04 参考环境中，以上闭环实测结果为 overlay 拨号: HTTP 200（连续三次访问稳定，端到端时延约 0.04s），验证了"服务端零端口暴露 + 客户端按服务名访问"的核心体验。

六、适用场景与限制

适用场景

• 替代端口发布式远程访问：将内部 Web、数据库、SSH 等服务收编进 overlay，替代"NAT + 防火墙白名单"模式；
• 跨组织/跨云互联：多 VPC、多办公网、IDC 混合组网，路由器 mesh 互联后按服务授权；
• 应用级零信任改造：愿意引入 SDK 的团队可以把身份与授权下沉到进程级别，获得最完整的零信任语义；
• SaaS 化私有接入：服务商向多个租户安全暴露独立服务实例，天然多租户隔离。

限制与成本

• 组件与学习成本高：controller、router、tunneler、四类策略、证书体系是完整心智模型，入门显著高于 WireGuard/Tailscale 类"装完即用"工具；
• v2.0 生态过渡期：大量 v1 教程与脚本使用了已移除的 ziti controller init、ziti edge create identity <type> 等命令，照抄会失败；第三方集成需确认对 2.0.x 的兼容声明；
• 需要自建控制面：开源版需自行部署与维护控制器集群（NetFoundry 同时提供商业托管控制面）；
• 性能开销：双重加密与 overlay 寻址会带来可感知的时延与吞吐损耗，对吞吐敏感的纯内网大流量场景应先压测。

七、同类选型对比

OpenZiti 常与 Nebula、Tailscale（及自托管的 Headscale）、WireGuard、Firezone 放在一起比较。它们的共同点是"身份驱动的加密组网"，差异在授权粒度与部署形态：

选型建议：

• 团队要的是"像访问内网一样按服务访问，且服务端不开端口"，并能接受较高的平台建设成本——OpenZiti 是唯一同时具备服务级授权与应用级 SDK 的选择；
• 团队只想要"把几台机器连成加密网，管理 IP 和组就够了"——Nebula 更轻，见站内 《Nebula VPN 1.11.2 介绍与选型指南》；
• 追求开箱即用的 SSO 办公网或已有 Tailscale 生态——选 Tailscale/Headscale；
• 需要多网段路由型组网 + 管理后台，Firezone 提供了介于两者之间的形态，见站内 《Firezone 1.6.3 介绍与选型指南》。

社区活跃度方面，OpenZiti 主仓库 4.4k stars（2026-10-20，shields.io），issue/PR 响应在同类自托管项目中属活跃水平；官方提供 Discourse 论坛与每周社区 call。它背后有 NetFoundry 商业公司支撑，长期维护风险低于纯社区项目。

八、参考链接

1. OpenZiti 官网与文档：https://openziti.io
2. GitHub 仓库 openziti/ziti（releases）：https://github.com/openziti/ziti/releases
3. 官方博客《Announcing OpenZiti v2.0》（更新于 2026-06-30）：https://blog.openziti.io/announcing-openziti-v2-0
4. HA 引导初始化文档（agent cluster init）：https://openziti.io/docs/reference/ha/bootstrapping/initialization/
5. 控制器证书与信任域文档：https://netfoundry.io/docs/openziti/reference/ha/bootstrapping/certificates
6. 站内实操篇：《Ubuntu 22.04 安装 OpenZiti 指南》、《OpenZiti 2.0.8 配置参数详解》、《OpenZiti 2.0.8 常用 CLI 命令详解（ziti CLI）》
7. 站内同类组件：《Nebula VPN 1.11.2 介绍与选型指南》、《Firezone 1.6.3 介绍与选型指南》