OpenZiti

OpenZiti 是一个开源零信任网络平台，它使网络服务对未授权用户完全不可见。每一次连接——无论是来自用户、服务、设备还是工作负载——都通过加密身份进行认证，通过策略进行授权，并实现端到端加密。

OpenZiti 既适用于现有应用（通过轻量级隧道器，无需修改代码），也适用于新应用（通过嵌入式 SDK 实现最强零信任模型）。这使得它既能应对存量环境（brownfield），也能支持全新开发（greenfield）。

由 NetFoundry 创建并提供赞助。基于 Apache 2.0 许可开源。

目录

• 使用场景
• 关键能力
• 三种部署模型
• 快速开始
• 架构
• 零信任、暗服务与端到端加密
• SDK
• 社区与支持
• 参与贡献
• 采用者
• 托管解决方案

使用场景

OpenZiti 让你能够将零信任扩展到任何场景，包括非人类工作负载和工作流，跨越多个网络和第三方。以下是一些常见用例。

替换 VPN

为内部服务提供安全访问，无需 VPN 客户端、分裂隧道（split tunneling）问题或集中器瓶颈。每个服务单独授权。杜绝“一旦进入，便能访问一切”的问题。

暗 API 与服务

使 API 和服务对互联网不可见。零监听端口意味着零攻击面。授权客户端通过 OpenZiti 连接；其他人什么也看不到。

IoT 与非人类身份

为每个设备、传感器和机器分配唯一的加密身份。OpenZiti 的身份模型不仅适用于人类用户，也同样适用于非人类工作负载，为构成现代网络流量主体的机器对机器连接提供强认证。

零信任工作负载

保护跨云和跨环境的工作负载间通信。服务之间通过加密身份（而非网络位置）进行相互认证。无需共享密钥，无需 IP 白名单，无需环境隐式权限。

代理 AI

为每个 AI 参与者（包括智能体、MCP 服务器、工具端点和私有 LLM）提供加密身份，保障智能体与服务之间、智能体与智能体之间的通信安全。让私有 LLM 保持黑暗状态，不暴露任何监听端口或公共 URL。智能体使用强唯一身份进行认证，并且只能访问策略允许的资源，使得自主工作流既能获得所需访问权限，又不会对其他一切拥有隐式授权。

多云与混合连接

一个覆盖网络横跨 AWS、Azure、GCP、本地数据中心和边缘位置。无需特定云的网络工具，无需跨环境 VPN 隧道，无需复杂的对等互连（peering）安排。

自托管服务访问

从任何地方访问家庭实验室或自托管服务，如 Nextcloud、Home Assistant、媒体服务器和开发环境。无需开放路由器端口，无需动态 DNS，无需依赖第三方隧道服务。你掌控整个路径。

Kubernetes 与跨集群服务

连接 Kubernetes 集群之间的服务，无需复杂的入站规则、服务网格边车或集群间 VPN 隧道。同时支持超越 Kubernetes 的场景，可将 k8s 服务连接到虚拟机、裸金属、物联网设备或覆盖网络上的任何其他目标。

关键能力

三种部署模型

OpenZiti 支持三种零信任模型。可以在同一个网络中混合使用，并随时间推移进行迁移。

网络接入

在受信网络区域部署一个 OpenZiti 边缘路由器。流量从已认证的客户端进入覆盖网络，然后从该区域出口进入运行服务的私有网络。

• 代码修改： 无
• 服务主机上的代理： 无
• 安全模型： 网络边界的基于身份访问。类似网关，但使用加密身份和加密传输。

主机接入

在与服务相同的主机上运行 OpenZiti 隧道器。隧道器负责处理身份、认证和加密。服务只需接受来自 localhost 的连接。

• 代码修改： 无
• 设置： 安装隧道器，注册身份
• 安全模型： 信任边界在主机操作系统层面。服务对网络呈“黑暗”状态，只能通过隧道器访问。

应用接入（最强）

将 OpenZiti SDK 直接嵌入客户端和/或服务器应用。应用本身持有加密身份并就地加密流量。不存在任何监听端口，甚至 localhost 上也没有。

• 代码修改： 需要
• 安全模型： 最强。端到端加密在进程内完成。完全黑暗。身份在应用层，而非网络层或主机层。

从何入手： 许多团队从主机接入（隧道器）开始，用于现有服务。几分钟即可部署完成，无需修改代码。对于新开发或高安全要求的工作负载，应用接入（SDK）提供最强的零信任姿态。

快速开始

以下快速入门指南展示了如何搭建本地 OpenZiti 网络用于开发、测试和学习。对于生产部署，请参阅产品文档：https://netfoundry.io/docs/openziti/category/deployments/。

使用 Docker 快速开始

启动本地 OpenZiti 网络最快的方式：

wget https://get.openziti.io/dock/all-in-one/compose.yml
docker compose up

这会在单个 Compose 栈中启动一个控制器、一个边缘路由器以及 Ziti 控制台。控制台地址为 https://localhost:1280/zac/。在此处你可以创建身份、定义服务以及配置访问策略。

详细信息（包括存储选项、环境变量和 CLI 用法）请参阅 all-in-one Docker 快速入门。

使用 CLI 快速开始

从 GitHub Releases 下载最新的 ziti 二进制文件，然后：

ziti edge quickstart

这将启动一个本地开发网络：控制器、路由器以及一个默认的管理员身份。适用于测试和学习。

如需向正在运行的控制器添加 Ziti 管理控制台 (ZAC)：

ziti ops console download --location /opt/openziti/console
ziti ops console configure /path/to/controller.yml --all --location /opt/openziti/console
# 重启控制器，然后打开 https://<controller-address>/zac/

或者在不修改控制器配置的情况下本地提供 ZAC 服务：

ziti run console --version latest
# 打开 https://127.0.0.1:8443。从浏览器指向任何控制器即可。

了解更多

架构

OpenZiti 的覆盖网络运行在现有基础设施之上：任何 IP 网络、任何云、任何组合。核心组件：

控制器

控制器是管理平面。负责：

• 身份管理：为网络中的每个参与者颁发并验证加密身份（x509 证书）
• 策略执行：定义哪些身份可以通过哪些边缘路由器访问哪些服务
• 网络状态：跟踪路由器、服务和拓扑；提供 REST API 和基于 Web 的管理控制台

边缘路由器

边缘路由器构成数据平面，是一个网状结构，承载端点之间的加密流量。

• 公共路由器 可从互联网访问，作为网络的入口点
• 私有（“黑暗”）路由器 部署在私有网络内部，仅建立出站连接

路由器自动发现彼此，形成网状连接，并使用智能路由根据延迟、吞吐量和成本选择最佳路径。

端点：SDK 和隧道器

端点是应用和用户连接到 OpenZiti 网络的方式：

• SDK（Go、C、Python、Node.js、Java、Swift、C#）：将零信任直接嵌入应用。应用本身持有身份并处理加密。无需边车、无需代理、无需监听端口。

• 隧道器（Linux、Windows、macOS、iOS、Android）：轻量级应用，为未修改的软件提供 OpenZiti 连接。流量被透明地拦截并通过覆盖网络路由。无需修改代码。

零信任、暗服务与端到端加密

零信任与应用分段

OpenZiti 网络中的每个参与者（例如用户、服务、设备、工作负载）都携带一个由 x509 证书支持的唯一加密身份。当发起连接时，OpenZiti 验证：

1. 身份有效且已注册
2. 存在允许该身份访问请求服务的策略
3. 连接通过已授权的边缘路由器

如果任何一项检查失败，连接被拒绝。如果之后访问被撤销，活跃连接会立即终止。不存在基于网络位置的隐式信任。除非策略明确允许，否则在同一个 LAN 上并不比在互联网上拥有更多访问权限。

这一模型实现了零信任应用分段：每个服务独立授权。获取对一个服务的访问权限并不会授予对任何其他服务的访问权限。

暗服务

“暗”服务没有任何开放端口。它不在任何网络接口上监听入站连接。相反，服务（或其旁边的隧道器）向 OpenZiti 边缘路由器发起一个出站连接并注册自身。客户端只能在认证和授权之后，通过 OpenZiti 结构来访问它。

这在实践中意味着：

• 端口扫描一无所获：没有任何监听端口可供发现
• 零攻击面：你无法利用你无法触及的东西
• 抗 DDoS：没有公共端点可以被淹没
• 对未授权用户不可见：只有具有匹配策略的身份才能知道该服务存在
• NAT 和防火墙友好：所有连接都是出站方向，因此不受 CG-NAT、双层 NAT 以及限制性防火墙的影响

边缘路由器也可以变成黑暗状态。私有路由器只发起出站连接，因此在你的私有网络中无需任何入站防火墙规则。

端到端加密

使用 OpenZiti SDK 时，流量从发送应用加密到接收应用：数据路径使用 libsodium，身份认证使用 mTLS。即使路由器或中间网络被攻破，流量也无法被解密或篡改。

使用隧道器时，加密覆盖从隧道器到隧道器（或隧道器到 SDK）的路径，实现无需更改应用的机器对机器加密。

SDK

将零信任网络直接嵌入你的应用：

所有 SDK 均列在 OpenZiti GitHub 组织 下。

安全

OpenZiti 是一个以安全为导向的项目。负责任地披露漏洞有助于我们保护平台及其用户的安全。

报告漏洞： 如果你发现安全问题，请查阅我们的漏洞披露政策了解完整细节。敏感问题应报告至 [email protected]。非敏感问题可以在相应仓库中作为 GitHub issue 提交。你应在 7 天内收到回复。

我们如何处理漏洞： 我们的产品安全事件响应流程描述了如何对报告的漏洞进行分类、记录和解决——包括如何协调 CVE 发布与修复。

安全港： OpenZiti 和 NetFoundry 不会对善意研究和报告漏洞的任何人提起法律诉讼。我们鼓励安全研究，并会在公告和发布说明中将报告的发现归功于报告者。

社区与支持

OpenZiti 拥有一个活跃且不断壮大的社区：

• Discourse 论坛：提问、分享项目、从社区和维护者那里获取帮助
• YouTube：教程、演示和深度解析
• 博客：项目更新与技术文章
• Twitter/X：新闻与公告

参与贡献

OpenZiti 项目欢迎各种贡献，包括代码、文档、错误报告和反馈。

主要仓库

从源码构建

构建说明请参阅本地开发教程。

开发者文档

• 开发者概览
• 本地开发
• 本地部署
• 控制器 PKI
• 发布说明

采用者

OpenZiti 已在生产环境中被多个组织使用，包括 DeltaSecure（托管 SOC）、Resulticks（营销自动化）、Chirp Wireless（物联网/电信）、GIGO Dev（云开发环境）、OSMIT（托管 IT/GDPR 合规），以及开源项目如 zrok 和 BlueBubbles。

完整列表请见：ADOPTERS.md。你正在使用 OpenZiti？我们很乐意将你加入列表——请提交 issue 或 PR。

托管解决方案

如果你不想自己管理基础设施，NetFoundry 提供完全托管、全球分布的 OpenZiti 网络即服务，包含 SLA、企业支持以及全球边缘路由器矩阵。

OpenZiti 由 NetFoundry, Inc 开发并开源。