#NSIO Next · 统一 L3 + L4 商业产品架构

状态：产品与系统架构基线。本文只定义 NSIO Next 的目标形态，不表示所有能力已经实现。

用户从登录到每项能力成功、失败和撤销的完整流程见产品闭环与功能实现规格；每个产品对象、组件责任、交互状态和端到端预演以产品能力目录与实现闭环为检查总账。注册的两台状态机、数据结构、API、错误码和配额事务以注册、准入与配额协议为权威。

#0. 一句话定义

NSIO Next 是一个以统一节点网络为基础、以命名服务和企业网关为增值层的零信任连接平台：

• 像 Tailscale 一样，让个人和小团队先把设备连起来；
• 保留 NSIO 已有的 L4 命名服务、细粒度服务授权和自定义域名能力；
• 通过基础 Relay Plane 保证困难网络可连接，通过 NSGW 提供区域/专属中继、公网入口、应用连接、固定出口和互联网出口；
• 通过 NSD 提供组织、身份、策略、审计、合规和私有部署。

它不是“把 NSC 和 NSN 拼成一个二进制”，也不是“用 L3 替换 L4”。目标是一个统一客户端、两个互补的数据平面和一个统一的策略系统。

统一 NS 客户端
├── 基础能力：L3 节点组网
├── 增值能力：L4 命名服务与服务级授权
├── 增值能力：子网路由、应用连接、Gateway Egress、Gateway Exit
├── 增值能力：公网入口与固定企业出口
└── 企业能力：组织、SSO、策略、审计、私有部署与合规

#0.1 全新产品边界

NSIO Next 不是旧 NSIO 的升级版本或兼容运行时，而是一套从零开始的产品与协议：

• Organization、User、Group、Device、Network、Node Membership、地址、Service、Grant、Entitlement 和 Audit 全部在 Next 原生创建；
• 不读取或导入旧 Realm、Machine、Auth Key、Policy、VIP、状态目录、私钥或审计记录；
• 不提供旧 NSC/NSN 与 Next NSD、Next ns 与旧 NSD 的交叉连接；
• 不做 v1/v2 双写、双投影、原地升级、兼容窗口或按 Organization 灰度迁移；
• Next 的首个协议版本从 v1 开始，各协议面以后按自身版本独立演进；
• 可以复用旧代码中经过重新审查、满足 Next 契约和测试的算法或模块，但这种工程复用不形成数据、协议或行为兼容承诺；
• 旧 NSIO 继续在原仓库和原部署中独立维护，Next 的变更不得要求旧产品同步升级。

#1. 设计目标与不做的事

#1.1 产品目标

#1.2 必须守住的边界

1. 基础 L3 不依赖付费或专属 NSGW。 节点优先直连；直连失败使用免费托管或社区自建的最小 Relay Plane。用户不购买企业网关，基础节点网络仍然完整可用；这不等于真实 NAT 环境可以完全没有公共中继。
2. L4 不是 L3 的别名。 服务拥有独立身份、名称、VIP、后端、健康状态、发布者同意和 ACL，不退化成一个 IP:port 备注。
3. 企业默认不全互通。 个人空间可以用简单模板获得“我的设备互通”；企业空间默认拒绝，按用户组、节点标签、服务和网段授权。
4. 私钥不出节点。 NSD 保存公钥、身份、策略和路由元数据，不保存节点私钥或会话明文。
5. NSGW 不是超级节点。 中继默认只转发密文；公网入口或代理终结必须被显式配置、显式授权并可审计。
6. 旧产品与 Next 完全隔离。 旧 NSIO 在原仓库独立维护；Next 不引入兼容层，也不要求旧产品改变发布节奏。
7. L3 默认使用系统 L3 虚拟接口。 Windows、macOS、iOS 和 Android 使用 TUN/VPN API；Linux 可使用 TUN 或内核 WireGuard 接口。Next 的 L4 Service 可以复用同一 TUN，也可以在明确支持的平台提供本地 Proxy 数据面。
8. 一个安装只有一个网络运行时和一个本地控制所有者。 NS App、CLI 和 helper 都通过本地 API 控制唯一 ns daemon。桌面 user-owned 模式同一时刻只允许一个 OS principal，切换用户前撤销系统级网络投影；无头/MDM 节点使用独立 managed-device 模式。具体 IPC、接管、卸载与真机门遵守发行生命周期。
9. 商业承诺必须有运营证据。 SLA、状态页、采购、备份、数据权利和认证分别以服务运营、采购计费、备份恢复和信任合规为权威。

#1.3 首期明确不做

• 不把 NSD 放进业务数据路径；
• 不让管理员绕过节点本地同意，远程凭空发布任意本地端口；
• 不让所有加入同一企业的设备默认横向互通；
• 不承诺任意数量、任意重叠地址池的 Network 都能同时安装系统路由；首版一个运行实例只激活一个控制 Profile；
• 不用一个“大而全”的 NS 二进制替代 NSGW；
• 不以 Auth Key 作为普通员工的主要登录体验。

#2. 目标能力与工程复用边界

#2.1 可复审复用的实现材料

#2.2 真正需要重构的部分

Next 不建立同时承担设备、网络成员、运行进程和产品角色的 Machine 聚合对象，而是从第一版拆开：

Device：这台真实设备是谁、归哪个用户、姿态如何
Node Membership：这台设备加入了哪个 Network、拿到哪个 Node IP 和密钥
Capability：这次运行启用了哪些能力
Service Endpoint：这台节点具体发布了哪些服务

这样同一台笔记本可以既访问另一台机器的 L3 地址，又发布本机开发服务；一台服务器可以同时是节点、服务发布者和子网路由器，而不需要换二进制。

#3. 总体系统架构

#3.1 组件职责

#3.2 统一 ns 的模块形态

ns 是一个运行时，不再按访问端/发布端分成 NSC 和 NSN。它由能力模块组成：

能力是集合，不是互斥角色。一台节点可以同时拥有 endpoint + service_host + subnet_router。

#3.3 NSGW 为什么仍然独立

NSGW 具有公网监听、多租户、NAT、证书、WAF、固定公网 IP 和高可用等高权限职责，安全边界与员工终端完全不同。把它合进 ns 会扩大终端攻击面，也会让“基础节点能力”和“运营级边缘基础设施”无法独立升级。

基础 Relay Plane 可以复用 NSGW 的密文中继实现或使用受限的社区 Relay 部署，但它只有 relay capability，不自动获得租户 Service 目录、Ingress、Egress、Exit、证书终结或管理权限。商业 NSGW 销售的是区域质量、容量、SLA、专属隔离和边缘增值能力，不是“能否联网”的开关。

因此只合并 NSC/NSN，不合并 NSGW。

#4. 商业对象模型

#4.1 对象定义

#4.2 Device 与 Node 为什么必须分开

一台电脑是一个 Device，但可以有多个 Network Membership：例如个人网络、公司网络和客户项目网络。每个 Membership 都有不同的 Node IP、Node Key、策略和生命周期。

首期产品交互突出一个主 Network，降低普通用户理解成本。同一账号可属于多个 Organization/Network，但运行时只激活一个控制 Profile；切换时重新投影地址、DNS、路由和 Exit。

#4.3 用户、设备和服务主体

权威 principal 分为三类：User、MachinePrincipal 和 ExternalPrincipal。Group、批准的 Tag 与 self 是选择器或集合，不是新的身份类型；NodeMembership 是编译后的运行时身份。Device 只作为来源设备、所有权、管理状态与 posture 条件，不能直接作为 AccessGrant subject。

节点所有者有三种：

1. User-owned：员工或个人的笔记本、手机，跟随用户离职和登录状态；
2. Tagged/Service-owned：服务器、容器、CI、路由器，不绑定某个员工；
3. Externally shared：来自其他 Organization 的受邀用户或共享节点，权限只对明确资源生效。

服务主体不能伪装成人类用户。服务账号与 Workload Identity 都建模为 MachinePrincipal，凭据类型决定认证方式；服务节点用标签、MachinePrincipal 和 Enrollment Key 管理，管理员离职不会让生产服务器失去归属。

#4.4 User、Group 与 Network 的关系

Organization 中有 1,000 个员工，不代表 1,000 人都自动进入每个 Network。关系分成两层：

1. Network Principal Membership 决定一个 User/Group 是否属于该 Network，以及是 Member、Network Admin 还是 Auditor；
2. Grant 决定已经属于该 Network 的主体能访问哪些 Node、Service、Route 或 Exit。

Group 本身是 Organization 级身份集合，因此 developers 可以同时被分配到开发网络和共享工具网络；不同 Network 对同一个 Group 使用不同 Grants。创建 Group 本身不授予任何 Network 或资源访问权。

外部协作者优先使用资源分享，而不是把其加入整个 Organization：

• 分享 Node：只创建该 Node 的跨组织 Grant；
• 分享 Service：只创建该 Service 的跨组织 Grant；
• 邀请进入 Network：适合长期承包商，需明确角色、到期时间和审批人；
• 任何分享都不暴露未授权的用户、节点、服务或完整策略图。

现有运营后台或管理仓库中的 application 表示平台运营/管理入口时，不得直接复用为本章的受保护业务 Application。Next 中对员工开放的应用必须以权威 Service 为底座，二者在命名、ID 和存储上分离，避免 M2 组织模型落地时发生概念碰撞。

#4.5 跨 Organization 分享协议

跨组织分享不是把两个目录合并，也不是让一方 NSD读取另一方完整策略。首版使用双边确认的 Share：

1. 资源方是资源授权权威。 资源方 Organization 创建 ShareOffer，绑定具体 Node 或 Service、允许动作、目标 Organization、到期时间和不可枚举的随机 share_id；
2. 接收方是主体与姿态权威。 接收方接受后创建 ShareBinding，只把本地明确的 User/Group/Device 绑定到该分享，并对本地身份、设备姿态和离职状态负责；
3. 有效权限取交集。 resource Grant ∩ ShareOffer ∩ ShareBinding ∩ posture ∩ validity 全部成立才签发短期访问租约，任何一方不能单方面扩大另一方的边界；
4. 撤销双向生效。 资源方撤销资源或接收方撤销主体都会停止续租并推送撤销；默认撤销 SLA 不超过 5 分钟，高敏网络可配置更短租约；
5. 审计双写但最小披露。 两边都记录同一个 opaque share ID、动作、结果和时间。资源方只看到外部主体的稳定别名与必要姿态结论，接收方只看到被分享资源的展示信息，不互相复制目录；
6. 跨 NSD 信任显式建立。 双方 NSD 通过组织级 federation key 验证短期声明，key 轮换、吊销和重放保护独立于普通 Network key；未知组织、未知分享和已删除分享对外统一返回不可用，不泄漏存在性。

首版优先支持“分享一个 Service 给外部用户/组”。跨组织 Node 分享和 Network-to-Network 路由会扩大 L3 信任面，放在独立阶段，不由 Service 分享隐式开启。

#5. 身份、登录与设备加入

人类身份、登录入口、账号绑定、会话、MFA、撤销和部署差异以身份、登录与会话实现基线为权威；本节只保留架构关系和首次加入摘要。

#5.1 客户端要不要登录账号

答案是：人类设备默认必须登录；无人值守节点不要求交互登录。

Auth Key 改名为 Enrollment Key（注册密钥），明确它只用于首次加入。用户设备不要求管理员手工生成 key 再复制粘贴。

邮箱不是登录的统一前置条件。只有邮箱密码和被用户主动选择的企业 SSO 发现流程需要邮箱；Google、GitHub 直接进入各自流程。Passkey 主登录后续以 Connector 增加。登录成功仍只证明用户身份，不直接创建 Device、Membership 或数据面 Grant。

#5.2 密钥层级

任何私钥都不进入 NSD 配置下发。管理员能撤销 Device 或 Membership，但不能导出其私钥。

#5.3 个人首次使用

1. 安装 NS App，点击“登录并连接”；
2. 系统浏览器展示并列登录方式；用户选择邮箱密码、Google 或 GitHub 完成认证；
3. 若账号没有空间，自动创建个人 Organization 和默认 Network；
4. App 创建绑定 Staging Device Key 的 Enrollment Request；
5. Personal Policy 自动批准，客户端在线轮询时取得短期 Grant 并原子 commit Device 与 Node Membership；
6. App 显示设备名称并申请 TUN 权限；
7. 节点获得稳定 Node IP 与名称，进入“已连接”；
8. 第二台设备重复登录后，个人模板允许同一用户自己的设备互访。

用户不需要先进入网页创建 Network ID，也不需要复制节点 ID。控制台适合管理，不是完成第一次连接的前置条件。

#5.4 企业员工首次使用

1. 管理员配置企业域名、OIDC/SSO、默认 Network、用户组同步和设备审批策略；
2. 员工从企业软件中心安装 App；
3. 员工点击“使用企业 SSO”，再输入企业邮箱或组织域名发现 Identity Authority 并跳转企业 IdP；私有部署已绑定单一 IdP 时可直接跳转；
4. NSD 将 User 映射到 Group，Enrollment Request 进入评估或审批，不提前创建 Device/Membership；
5. 根据策略自动批准，或等待管理员/MDM/Posture 通过；
6. 在线客户端取得短期 Grant，并在一个事务中创建 Device/Membership；
7. NSD 下发最小 peer map、DNS 和 Grants；
8. App 只显示员工可见的设备、服务和出口。

#5.5 服务器加入

管理员先创建带约束的 Enrollment Key：所属 Network、允许标签、能力上限、是否预批准、有效期和使用次数。服务器执行：

ns up --enrollment-key nsk_... \
  --name prod-api-01 \
  --tags server,prod \
  --capabilities endpoint,service-host

节点不能通过 key 自行增加未被 key 允许的标签或能力。

Enrollment Key 只完成一次注册，不能作为永久远程管理凭据。若注册策略允许受管配置，节点在本地派生并保存一份带 Organization/Network、管理签名方、能力范围、revision 和撤销状态的 ManagedConfigAuthorization；后续 desired manifest 必须同时满足该本地授权与当前 Network 策略。节点所有者可本地撤销该授权，撤销后新的受管变更回落为待确认请求并产生审计，不能继续静默写入本地 Service/Route manifest。

上述注册方式共享同一个 Enrollment Request/Grant 状态机。证明材料不同不允许产生另一条更宽松的提交路径，完整规则见注册、准入与配额协议。

#5.6 NSD 发现与私有部署登录

客户端需要知道“去哪个 NSD 登录”，但不要求用户手工输入长 URL：

• 云托管用户从统一账号入口登录，Directory API 返回其 Organization 和 Network；
• 企业私有部署可通过 ns://join/<code>、企业下载包、MDM 配置或邮箱域名发现 NSD；
• CLI 可以显式使用 --control-server，适合自动化和测试；
• App 把每个控制端保存为独立 Profile，证书、Organization ID 和登录会话不跨 Profile 复用；
• 一个 Network 只能有一个逻辑控制权威。高可用 NSD 集群共享同一数据库、签名域和一致版本，不能由两个独立 NSD 同时写同一 Network。

Next 首版一个 ns 运行实例只激活一个控制 Profile。一个 Organization 可以包含多个 Network，账号也可以属于多个 Organization，但用户切换主 Network/Profile 时必须先完成路由、DNS、Exit 和未完成操作检查。多独立 NSD 同时激活不属于首版协议、交互或验收范围。

登录页不按地区分叉，也不要求所有人先输入邮箱。云托管首版提供邮箱密码、Google、GitHub 和企业 OIDC；私有部署只展示客户实际配置的方式。未来 Passkey、微信、企业微信、飞书、钉钉等只作为 Identity Authority Connector 增加，不能产生新的 User、Device 或 Grant 类型。

#6. 地址、命名与 DNS

#6.1 三类地址必须分开

Next 对外只展示稳定 Node IP 和 Service VIP；TUN 内部栈地址、传输地址和物理 Endpoint 不进入普通产品 UI，也不得被当作节点身份。

#6.2 名称设计

一个节点只有一个节点名，但可以发布多个服务：

因此“一台机器里有五个服务”时，仍然只有一个 Node IP/节点域名，但有五个 Service 名称和五个独立授权资源。

短名称不是可以猜测的解析规则：Node 与 Service 同名时，该短名记录必须 withheld，DNS 不得随机解析到任一对象；UI 同时显示“节点/服务”类型及各自 FQDN，CLI 必须使用完整 FQDN。多个 Profile/Network 提供同一短名时使用相同的 fail-closed 规则。完整交互见产品闭环 §3.2。

#6.3 地址池

• Next 默认把 RFC 6598 100.64.0.0/10 划成互不重叠的用途池，例如 Node IP 使用 100.64.0.0/11，Service VIP 使用 100.96.0.0/11；具体边界由协议常量固定并纳入契约测试，不能由各 NSD 随意解释；
• 每个 Network 在对应用途池中获得明确子段，NSD 保证稳定且唯一；切换到另一控制 Profile 前，客户端必须检测本机已有路由冲突并 fail-closed；
• IPv6 使用每 Network 的 ULA /48，Node 分配稳定 /128；
• 自定义地址池必须在创建 Network 时校验本地路由和其他已激活 Network 的重叠；

Service VIP 集中化是 服务名 → 稳定 Service VIP 在多设备间一致的前提。地址池规划必须按 Node 与 Service 的峰值、保留期和不可立即复用窗口分别计算。

首发规模基线为单 Network 10,000 个 active Node Membership、5,000 个 Service 和 50,000 条 active authored GrantRule；schema、分页、投影分块和地址模型不得在达到 100,000 Node、50,000 Service、500,000 GrantRule 的设计上限前要求破坏性重构。设计上限不是已验证能力或 SLA，完整对象/时延目标与当前验证状态见产品能力目录 §19.5。

单 Network 预计超过 20,000 个 active Node + Service，或 IPv4 地址块计入隔离/保留后达到 75% 时，控制面必须阻止无计划扩容并要求 IPv6-first、追加 IPv4 块或客户自定义池的显式容量方案；没有容量方案不能形成销售承诺或 API 成功结果。

#6.4 DNS 行为

NS App 默认安装按域 DNS：

1. *.node.ns.io 返回 Node IP；
2. *.svc.ns.io 和显式批准的自定义 Service 域名返回 Service VIP；
3. 企业自定义域名按最长后缀匹配进入 split DNS；
4. 未命中查询继续走系统原 DNS，不改变普通互联网解析；
5. 浏览器 DoH 绕过系统 DNS 时，企业策略可通过受管浏览器配置或本地代理接管。

#7. L3 节点网络

#7.1 用户体验

连接后，用户可以直接：

ping dev-pc
ssh dev-pc
curl http://nas:5000

这类访问面向“节点”，目标程序监听在哪个端口由目标机器自己决定。它适合个人、小团队、远程桌面、SSH、文件共享和开发环境。

#7.2 数据路径

启用 L3 时，Windows、macOS、iOS 和 Android 默认使用系统 TUN/VPN API：把 Node IP 配到虚拟接口，并把被授权的 Node/Route 前缀安装到该接口。Linux 桌面可同样使用 TUN；服务器可选择内核 WireGuard 接口以降低开销，但必须消费同一份 netmap/grants/routes 并执行相同策略，不能形成“内核模式默认放宽”的旁路。

TUN 是 L3 的默认数据面，不是整个产品唯一数据面：Next 可以为明确支持的平台提供本地 Proxy 服务访问模式；同时启用 L3 与 L4 时，Service VIP 进入同一 TUN，但仍按 Service Grant 而不是 Node Grant 授权。

应用访问 Node IP / 节点名
  → OS 路由进入 NS TUN
  → 本地策略检查目的节点与端口
  → 选择直连 WireGuard；失败则选择密文中继
  → 目标节点再次执行入站策略
  → 注入目标 TUN
  → 目标本机应用收到原始 L3/L4 连接

NSD 不转发业务包。NSGW 作为中继时只看连接元数据和密文包，不拥有会话明文密钥。

#7.3 L3 也必须有 ACL

L3 不代表“加入网络就全部互通”。方便性来自策略模板，不来自取消授权。

#7.4 Peer map 裁剪与双端执行

NSD 不应把整个 Network 的节点、地址和公钥都发给每台设备。它根据 Grant 计算可见 peer map：

• 未授权节点尽量不可见，减少元数据暴露；
• 源节点先做出站判定，避免无效连接；
• 目标节点做最终入站判定，防止旧配置或恶意客户端绕过；
• 策略撤销后推送 delta，节点在租约到期前不得无限使用旧策略；
• 离线容忍和撤销时限由企业策略选择，敏感网络可以要求短租约。

#7.5 子网路由

Node 可以发布传统网段，例如 10.20.0.0/16，但必须经历：节点声明 → 管理员批准 → Route 资源创建 → Grant 授权 → 客户端安装路由。

地址重叠时不做随机选择：相同 Network 内按 route domain、优先级和健康状态确定；无法唯一决定则拒绝安装并给出明确冲突。

#8. L4 命名服务平面

#8.1 为什么必须保留

L3 解决“连接到哪台机器”，L4 Service 解决“访问哪个业务能力”。服务平面提供 L3 无法自然表达的能力：

• 名称不随承载节点变化；
• 一个服务可有多个健康后端；
• 可按用户/组直接授权服务，不必暴露整台机器；
• 可提供自定义域名、Service VIP、协议和端口；
• 发布者保留本地同意，管理员不能凭空扩大后端；
• 可接公网入口、Gateway Egress、审计和应用门户。

#8.2 服务生命周期

1. 节点本地声明服务：名称、协议、后端地址、端口、健康检查和可选域名；
2. ns 校验后向 NSD 上报 Service Endpoint；
3. NSD 创建或关联逻辑 Service，分配 Service VIP 和名称；
4. 管理员审批目录可见性和 Grants；
5. 消费者只收到被授权服务的 DNS/VIP/路由；
6. 流量到达发布节点后，本地 manifest 与 ACL 再次判定；
7. Endpoint 下线不会删除 Service，健康路由切换到其他 Endpoint。

#8.3 谁可以发布服务

• 桌面 App 可以发布本机服务，适合个人开发、临时演示和小团队；
• CLI/config 适合服务器和稳定环境；
• API/Operator 适合 Kubernetes、CI 和自动化；
• 企业可以要求管理员审批后才进入共享目录；
• “发布权限”和“访问权限”是两种不同动作，不能因用户能访问某服务就允许其发布同名服务。

#8.4 App 发布交互

服务 → 发布服务 → 选择来源
├── 本机端口：127.0.0.1:3000
├── 本机局域网地址：192.168.1.10:443
└── 自定义后端域名：internal.example.com:443

填写：名称、协议、端口、健康检查、可选自定义域名
预览：最终服务名、谁可以访问、是否需要管理员审批
确认：写入本地声明，再向 NSD 上报

首版不自动扫描并公开本机端口。可提供“检测到可发布服务”建议，但必须由用户确认。

#8.5 L3 与 L4 是否冲突

不冲突，因为入口和授权资源不同：

企业可完全禁止员工间 L3 横向访问，只开放 L4 服务目录；个人网络则可主要使用 L3，只有需要稳定名称或共享时才发布 Service。

#9. 分层策略与授权模型

Next 不使用一张“万能 ACL”同时管理内部流量、节点能力、公网访客和控制台管理员。四个策略平面共享规范化选择器、条件、版本、审计和稳定错误，但拥有各自资源、动作和执行器：

Entitlement 只决定某项商业能力或额度能否准入，不授予访问权限。ServiceEndpoint、Connector、Relay、Gateway 是承载者；ShareOffer、ShareBinding、Lease 是委托和租约对象，都不得伪装成普通 AccessGrant 目标。

#9.1 AccessGrant 结构

GrantSet（用户编辑与审批对象）
├── subjects：user / group / machine-principal / tag / self / all
├── source_conditions：device / membership / network / posture / time / via
├── resources：node / service / route / exit-profile
├── actions：connect / invoke / use-route / use-exit
├── constraints：protocol / port / path / via / time / posture / source-network
└── effect：allow（默认拒绝，无 deny 规则）

GrantRule（编译与审计对象）
├── grant_set_id
├── 一个 subject_selector
├── 一个 resource_selector
└── actions / constraints / revision

继续使用 allow-only 是为了让多层策略合并保持可预测。需要表达“某组不能访问”时，应缩小 allow 范围，而不是叠加顺序敏感的 deny。数组只属于 API/UI 的批量创作体验；持久化和编译层使用规范化的单主体、单资源 GrantRule，这样每次允许都能准确归因到一条规则。Device 限制写入 source condition，例如 user:clark + device:corp-mac + managed:true，不能写成 subject=device:corp-mac。

#9.2 常见策略示例

grants:
  - subjects: [user:self]
    resources: [nodes:owned]
    actions: [connect]

  - subjects: [group:developers]
    resources: [service:git, service:dev-database]
    actions: [invoke]
    constraints:
      posture: managed-device

  - subjects: [group:network-ops]
    resources: [tag:production-server]
    actions: [connect]
    constraints:
      protocol: tcp
      ports: [22]

  - subjects: [group:travelers]
    resources: [exit:hong-kong]
    actions: [use-exit]

#9.3 管理权限与网络权限分离

能访问节点不代表能编辑节点；能使用出口不代表能配置 NSGW。AdminRoleBinding 至少支持 Organization Owner、Billing Admin、Network Admin、Security Admin、Service Publisher、Edge Admin、Auditor 和 Member，并把动作细分为成员、设备、Network、策略、Service、Route、Gateway、PublicApplication、审计、账单等资源的 read/create/update/approve/revoke/export，而不是一个宽泛的 administer。

发布能力也不属于 AccessGrant。CapabilityPolicy 先判断节点是否有资格申请 service_host、subnet_router、app_connector、exit_provider 或 relay_candidate，再由逐实例 CapabilityActivation 完成批准、配额占用、计量、审计和短租约签发。策略允许“符合条件自动批准”，但自动分支仍执行同一事务，不能绕开 Managed Resource 计费触发点。

#9.4 策略编译

Grant 的选择器、规范化、命中、最小投影、撤销与测试以Grant 与策略编译实现规格为权威。

NSD 保存人类可读 Grant，编译成每节点最小配置：

• 可见 peers 与公钥；
• 节点入站/出站 ACL；
• 可见 Services 与 Service VIP；
• 可用 Routes、Exit 和 Gateways；
• DNS 记录与自定义域；
• 版本号、租约和签名。

编译失败、读取失败或签名失败时不得下发空集合冒充“没有授权”；应返回显式错误并保留上一份未过期的已验证配置。

#9.5 Grant 创作、规范化与归因

控制台允许管理员一次选择多个主体和多个资源，但服务端必须把一次人类操作保存为一个 GrantSet，并规范化为可独立命中和审计的 GrantRule：

1. 创建或编辑时先生成影响预览和 canonical digest，确认后在一个事务中写入新 revision；
2. 每条 GrantRule 只有一个规范化主体选择器和一个资源选择器，数组只存在于创作 API，不进入编译语义；
3. 批量修改始终以显式 grant_set_id 为边界，不根据名称或相似条件猜测哪些规则属于一组；
4. 审计同时记录人类操作的 grant_set_id 和真正命中的 grant_rule_id；
5. 回滚创建新的 revision 并引用来源 revision，不重写历史快照；
6. 编译器只读取已发布的 canonical revision，读取或签名失败时保留上一份未过期配置，不下发空授权。

#10. NSD 控制面

#10.1 资源层级

Platform
└── Organization
    ├── Users / Groups / Roles / Billing
    ├── Network A
    │   ├── Node Memberships
    │   ├── Services / Endpoints
    │   ├── Routes / DNS / Grants
    │   └── Gateways / Audit
    └── Network B

Organization 是商业和管理边界，Network 是地址与信任边界。一个 Organization 可以有开发、生产、实验等多个 Network。

#10.2 控制面事件

Next 使用版本化的 snapshot + delta：

每个事件都有 Organization/Network 作用域、类型化目标（Device、Membership、Gateway 或 Client Session）、epoch、版本、有效期和签名；消费者拒绝跨作用域/目标重放、回滚版本和过期配置。首版事件命名和载荷见Runtime Protocol v1。

#10.3 控制面不可用时

• 已建立的直连数据通道可在策略租约内继续；
• 新节点、策略变更和新服务不可发现；
• 高敏企业可以配置短租约，牺牲离线可用性换取快速撤销；
• NSD 恢复后从最后确认版本补 delta，无法补齐则发完整 snapshot；
• NSD 不可用不得导致节点把流量自动改走未授权公网路径。

#10.4 资源生命周期

删除流程必须先计算影响：用户拥有的设备、节点发布的服务、Route、共享和自动化凭据都要列出，再由管理员选择转移所有权、停用或删除。生产 Service 不因某个员工离职而被误删。

Activation、Availability、Projection 和 Runtime 是独立状态轴：节点离线只令 availability=unavailable，不改变 active/suspended/revoked；管理员暂停一个正好离线的能力时，两轴同时成立。suspended 保留受管资源占位和计费，保证恢复不会因额度被他人占走而失败；只有显式 revoked 才释放。暂停可选设置审计化 auto_revoke_at，但不存在全局“暂停 N 天自动撤销”。

#11. 数据面与连接选择

#11.1 统一连接阶梯

同局域网直连 WireGuard
  → 公网 UDP 打洞直连 WireGuard
  → 免费托管或社区自建 Relay 密文中继
  → 专属/区域 NSGW 密文中继
  → WSS/TLS 中继（受限网络兜底）

控制面只提供候选和策略，节点根据实时网络质量选择。切换路径不改变 Node IP、Service VIP 或上层连接身份。

#11.2 中继隐私

中继 NSGW 只能看到短期轮换的 opaque route/session ID、包长、时间和中继流量，不获得稳定 Membership/Node/WireGuard 身份，也不持有 WireGuard 明文密钥。NSD 与端点保留稳定身份到 opaque lease 的映射用于授权和审计；Relay 不能跨租约关联。需要 L7 终结的公网入口、HTTP 代理、WAF 等是另一种显式模式，必须单独展示其信任边界。

#11.3 移动和网络切换

• 网络接口变化触发候选重探测和路由/DNS 对账；
• 先建立新路径，再切换活动发送器，避免长时间中断；
• 外部 VPN 路由冲突显式报告，不抢占不属于 NS 的路由；
• Exit 的 fail-closed 状态不能被普通连接自动覆盖，恢复本地直出需要用户或企业策略明确决定；
• Windows、macOS、Linux、iOS、Android 都以原生 TUN/VPN API 为 L3 基础。

#11.4 NAT 穿透与 Relay Plane

NAT 穿透是基础 L3 的独立核心子系统，不是“调用 WireGuard 后自动获得”的能力。至少包含：

• 本地接口、局域网地址、公网观察地址和 IPv6 endpoint 的持续发现；
• STUN/控制面观察、候选上报、候选配对和经过认证的路径探测；
• cone NAT、CGNAT、双端 symmetric NAT、UDP 封锁、端口重映射和 NAT rebinding；
• Wi-Fi/蜂窝/有线切换时 endpoint 漫游、keepalive、路径健康、抖动抑制和无效候选淘汰；
• Path MTU 探测、分片规避、IPv4/IPv6 优先级和 Happy Eyeballs；
• 直连不可行时，在可预测时间内切到 Relay；网络恢复后可无损回到更优直连路径；
• Relay 选择、区域延迟、容量、速率限制、滥用防护、密钥隔离和可观测性。

控制面只协调候选和签名，不进入业务包路径。路径探测消息必须绑定 Node Membership、目标 peer、epoch 和 nonce，防止第三方伪造 endpoint 或把节点诱导到未授权地址。

#11.4.1 基础 Relay 与商业 NSGW 的边界

完整的个人 L3 体验不能假设双方都处于友好 NAT。基础套餐因此包含一个只转发端到端密文的 Relay Plane：

同一代码可以复用 relay transport，但 capability、配置、凭据和部署清单必须分离；“能中继密文”不能成为读取 Service 目录或启用网关 NAT 的通行证。

Vendor Community Relay 的“公平使用”必须是可执行策略，而不是营销用语：

• 以 Organization 为单位计算持续带宽、并发 Relay 会话、滚动周期流量和异常连接频率；个人 UI 只展示可理解的当前用量与恢复时间；
• 接近软阈值时告警并优先引导恢复直连；超过软阈值可限速新 Relay 会话，但不影响直连、控制面、Service ACL 或自建 Relay；
• 超过硬阈值时拒绝新的 Community Relay 会话，已有会话保留有限 grace period 后自然到期，客户端必须显示 community_relay_quota_exceeded，不能伪装成节点离线；
• 明确的滥用或安全事件可立即撤销 Relay 租约，但必须独立于商业超额处理并产生审计；
• Team/Business/Enterprise 可以购买更高配额或 Managed NSGW Relay，个人也可切换自建 Relay；基础协议和直连能力不得因托管配额用尽而被关闭。

#11.4.2 NAT 验收门

Phase 2 不能只在同局域网或单边公网环境宣布完成。自动化与真机矩阵至少覆盖：

1. 同 LAN 直连、普通家用 NAT、CGNAT；
2. 双端 symmetric NAT，必须在时限内进入 Relay；
3. UDP 完全封锁，必须走 WSS/TLS Relay；
4. 一端从 Wi-Fi 切蜂窝、休眠唤醒、端口重映射；
5. 双栈、纯 IPv4、纯 IPv6、MTU 较小链路；
6. Relay 故障切换与恢复直连；
7. 未授权 peer 即使知道 endpoint 也无法完成数据面握手。

首版性能目标从“控制面已下发双方有效候选”开始计时，使用 p95 而不是单次最好结果：

这些是 Phase 2 的初始验收门，真机数据可以收紧目标，但不能在没有版本化基准、测试网络说明和 p95 证据时放宽。超时必须报告停在哪个阶段：发现、探测、握手、Relay 选择或策略安装。

这部分应单独立项、预算和验收；它与统一 ns、Grant v1 并行推进，但没有通过上述矩阵之前，不能把“像 Tailscale 一样简单连接”作为已完成能力。

Relay attach/frame、L3 candidate/roaming、ServiceFlow、RouteFlow、ExitTunnelLease 与各 generation 过渡的唯一线协议见数据面协议。架构层只决定信任边界，不允许各组件自行发明 token claims 或关闭语义。

#12. NSGW 增值能力

#12.1 能力矩阵

#12.2 能力隔离

一个 NSGW 必须按 Organization、Network 和 Capability 显式分配。中继能力不能自动获得 Public Ingress 权限；Exit 网关不能自动读取 Service 目录；公网入口只获得被发布 Service 的最小后端集合。

Public Ingress 由 PublicApplication(host/path) + EdgeAuthPolicy + IngressBindingLease 显式绑定到一个 Service。外部访客形成 EdgeIdentity/ExternalPrincipal，只在 Edge 请求中有效，不获得 Network Membership；NSGW 以受限 Gateway 身份和 Binding Lease 访问后端。内部 Service AccessGrant 与公网 EdgeAuthPolicy 是两条独立路径，收紧其中一条不会暗中改变另一条，控制台必须交叉展示并提示影响。

#12.3 自建与托管

• 个人/开源部署可自建 NSD 和基础中继；
• 企业可自建 NSGW，仍由 NSD 统一策略和审计；
• 云服务销售托管 PoP、固定 IP、自动证书、WAF、HA、流量日志与 SLA；
• 协议不应故意锁死自建，但托管服务通过运营质量和合规能力收费。

#13. 客户端产品交互

#13.1 信息架构

NS App 的主导航建议只有五项：

1. 连接：当前 Network、连接状态、路径、Node IP；
2. 设备：我可见且可访问的节点；
3. 服务：我可访问的服务，以及我发布的服务；
4. 网络：子网路由、应用连接、互联网出口；
5. 设置：账号、组织、诊断、更新和高级网络项。

不把 NSC/NSN 暴露给用户。服务发布是“服务”页的动作，不要求用户切换成某种节点模式。

#13.2 首页状态

已连接到 Acme / Production
此设备：dev-mac · 100.80.12.34
路径：直连 dev-pc · 托管中继 1 条

可访问：8 台设备 · 23 个服务
互联网出口：未启用

状态必须区分“控制面连接”“L3 数据面”“服务目录”“Exit”。不能用一个绿色圆点掩盖其中某一层失败。

#13.3 设备访问

设备列表展示名称、所有者、OS、Node IP、在线状态、直连/中继路径和用户被授权的操作。点击设备可复制名称/IP、Ping、SSH/RDP 或查看允许端口；未授权端口不展示成可用动作。

#13.4 服务目录

服务列表按应用名称展示，不要求员工理解承载节点。点击 Web 服务直接打开；TCP/UDP 服务提供复制地址和命令示例。服务详情可展示健康后端数量，但普通成员看不到未授权 Endpoint 和完整 ACL 图。

#13.5 Network 切换

账号可以属于多个 Organization/Network。普通用户界面突出一个主 Network；切换主 Network 时先校验地址、DNS、未完成连接和 Exit 状态。首版一个运行实例只激活一个控制 Profile，切换是显式动作，不在本机合并多个独立控制权威的路由与 DNS。

#13.6 Exit 交互

互联网出口是连接设置，不是单独的首页产品模块：

• 设置中打开“使用互联网出口”，自动要求 TUN；
• 首次连接后取得候选，若多于一个则弹出单选列表；
• 保存选择后重连进入 Exit；断开不清除选择；
• 关闭开关只停用，不删除保存选择；
• 选择失效时不自动换另一个网关；
• 已进入捕获后失败，按运行时 capture 事实说明流量是否被阻断，并让用户选择“重新选择”或“关闭出口”；
• IPv6 由其他 VPN 管理时必须明确显示“IPv6 未经过公司出口”。

#14. 管理控制台交互

#14.1 个人空间与 Organization 成长

首次登录不要求用户先创建 Organization、Network 或选择套餐：

1. 系统事务性创建一个真实的 Personal Organization、默认 Network 和个人安全模板；
2. UI 只称为“个人空间”，引导连接第一台设备并实时等待上线；
3. 第二台设备加入后，默认模板允许同一用户自己的设备互访；
4. 用户可以继续发布 Service、配置完整访问权限、邀请成员或添加服务器；
5. Personal 配额内邀请成员不改变套餐；只有用户明确启用试用、主动升级或使用当前 entitlement 不包含的企业能力时，才进入团队/企业升级向导；
6. Personal 在 Next 内升级商业档位时沿用同一 Organization、Network、Device、Node IP、Service、Grant 和审计历史，不重建资源；
7. 只有用户明确需要独立账单、法律实体或安全边界时，才创建另一个 Organization。

升级向导收集组织展示名称、Owner/账单联系人、安全模板、成员来源和套餐，并在提交前预览 Grant 变化。右侧可使用交互式产品预览，让用户填写名称和模板时立即看到导航、成员与资源如何变化，但预览不能替代真实状态。

#14.2 企业管理导航

Organization
├── Overview
├── Users & Groups
├── Networks
│   ├── Devices / Nodes
│   ├── Services
│   ├── Routes & Connectors
│   ├── Gateways & Exit
│   ├── Access Policies
│   ├── DNS
│   └── Audit
├── Identity & Security
├── Billing & Entitlements
└── Integrations

#14.3 应用门户

企业员工门户只显示该用户被授权的 Services。Web 服务可直接打开，TCP/UDP 服务显示连接方式。应用门户不是简单书签：每一项必须关联权威 Service ID 和 Grant，不能只保存一个任意 URL 后宣称已受 NSIO 保护。

#15. 商业能力轴

本节只定义能力如何分类和如何强制。具体套餐、价格、配额数字和首版强制范围见 商业模型与 Entitlement——那些数字会随市场调整，不应写进架构文档。

Effective Entitlement 分四个桶，新增键按后两列判定归属，不靠直觉：

每个 quota 携带 enforcement ∈ {block, warn, meter}：block 拒绝新增或扩大且存量不动，warn 允许但产生告警事件，meter 只计量。执行模式是签名声明的一部分，不是代码分支——把一项能力从观察切到强制是签发新声明，不是发版。

商业原则：Personal 与企业套餐使用同一套 Node、Service、Route 和 Grant 安全模型。个人用户可以发布服务、配置节点/端口/服务 ACL、分享设备并使用自建或获授权的 Gateway 能力；主体、资源、动作、协议/端口、时间和到期等核心 Grant 维度在所有档位一致。posture 作为 Grant 条件依赖 MDM、设备证明和组织治理，因此属于相应企业能力，不把这一企业治理条件包装成 Personal 已具备。套餐差异来自资源数量、托管流量、可用区域、身份治理、审计保留、合规、专属基础设施和 SLA，而不是删除个人用户的核心安全控制或故意让基础网络不可用。

#15.1 Entitlement 的权威与执行点

Entitlement 是商业能力声明，不替代 Grant，也不能成为数据面安全授权。执行分三种部署模型：

签名 entitlement 至少包含 organization/deployment ID、单调递增的 entitlement revision、feature set、quota、issued_at、expires_at、grace period、key ID 和签名。具体规则：

1. UI 不是强制点；API 和存储事务必须阻止未授权的新建、扩容或能力启用；
2. NSGW/托管 Relay 不相信客户端自报套餐，只接受 NSD 基于有效 entitlement 签发的短期 capability lease；
3. entitlement 读取或验签失败必须返回明确错误，不能伪装成“该套餐没有此功能”；可在最后已验证声明的 grace period 内继续；
4. 商业 entitlement 到期默认阻止新增和扩大，不应立即切断已建立的安全业务流量。安全撤销、欠费处置和合同到期是三种不同事件；
5. Grant 始终是最终访问授权：购买 Gateway Exit 不代表任何用户自动获得 use-exit；
6. 自建客户可以修改其掌控的开源二进制，因此架构不把本地 license 检查描述为不可绕过的安全边界。真正的硬约束只存在于供应商控制的托管服务，企业自建价值主要来自合法授权、更新、支持、合规包和 SLA。
7. 每个 organization/deployment 的 entitlement revision 必须单调递增并持久化已接受高水位；签名合法但版本回退的声明仍须拒绝，灾难恢复只能走签发权威批准并可审计的 recovery/reset 流程。

商业状态、安全撤销和控制面故障不得压成一个 entitlement 布尔值：

基础 Node/Service Grant 的安全撤销不受商业 grace period 延迟；商业系统也不能通过“欠费”事件绕过审计，直接伪装成安全撤销。

该分层让“协议和社区基础能力开放”与“托管服务和企业运营能力收费”同时成立，不靠破坏基础网络制造付费点。

#16. 安全模型

#16.1 信任边界

#16.2 Fail-closed 规则

• 无 Grant 不建立 L3/L4 转发；
• 配置读取失败不伪装成空授权；
• peer map 版本回退、签名错误、跨 Network 数据全部拒绝；
• Service 的远端授权与本地声明取交集；
• Route 客户端凭据与 Connector 精确目的地投影取交集，任一侧缺失或 digest 不匹配不转发；
• Edge 读取故障不当作 deny，Anonymous 也不能跳过显式 EdgeAuthPolicy/WAF/审计；
• Route/Exit 未批准或健康材料不足不安装；
• Exit 已捕获但转发未就绪时保持阻断，除非用户明确关闭；
• 控制面失联只允许使用未过期的最后已验证配置。

“Exit 捕获后不自动恢复本地直出”和“读取失败不折叠为空授权”是 Next 的原生安全基线，必须通过反向注入测试证明：重新注入自动恢复或把读取故障当无候选时，测试必须失败。

#16.3 企业治理

• SSO/OIDC、SCIM、MFA 和管理员角色分离；
• 企业 IdP 的 amr/acr/auth_time 只有经过 Federation Binding 显式映射后才能满足 NSIO assurance；强度不足时执行本地 step-up，不机械重复企业已完成的 MFA；
• 普通 logout、登录方式解绑、SCIM deprovision 和 Device 撤销是四种不同事务；只有确认离职/停用的 SCIM 或管理员动作撤销 Organization Membership，普通退出登录不让设备掉线；
• 默认身份撤销 SLA 不超过 5 分钟；Organization-owned Device 在员工离职后保留，只撤销该员工 Membership 并等待重新指派；
• 设备审批、密钥轮换、到期、远程撤销和姿态条件；
• 配置审计、网络流量元数据、Webhook/SIEM 导出；
• 策略版本、模拟、变更审批、回滚和 canary；
• 私有部署、数据地域、密钥托管边界和专属网关。

#16.4 多租户隔离与审计

• 所有持久化资源必须带 Organization/Network 作用域，查询在仓储层按作用域收窄，不能依赖前端过滤；
• API 返回外部 ID 时不泄漏跨 Organization 的存在性和归属信息；
• 跨 Organization Share 只暴露 opaque share ID 与最小展示别名；有效权限是资源方 Grant 与接收方 Binding 的交集，任一方撤销都在租约 SLA 内生效；
• 跨组织审计双写但不复制对方完整用户组、设备姿态明细、节点目录或策略图；
• NSGW 多租户会话按 Network、Capability 和配置版本隔离，公共中继不获得租户 Service 目录；
• 审计记录主体、动作、资源 ID、结果、配置版本、来源和时间，不在普通事件中记录完整邮箱清单、密钥或业务负载；
• 流量日志默认是元数据，内容采集属于单独的高敏能力，必须显式启用并受保留期和地域策略约束。

#17. 存储与协议演进

#17.1 建议的新核心表

这些是 Next 的原生表，不从旧 machines、Realm、AuthKey、Policy 或状态目录导入数据。Enrollment、Entitlement 和 Quota 的完整字段、状态和事务以注册、准入与配额协议为权威。表结构和协议从首个 Next release 开始遵守 additive 演进与未知字段策略；这只保证 Next 版本之间的前向演进，不表示与旧 NSIO 兼容。

#17.2 协议版本轴

以下版本轴独立推进，禁止通过一个版本号推断另一个协议面的能力：

跨面依赖通过经过认证的 Capability Manifest 明确协商。能力声明只能关闭双方不共同支持的可选功能，不能降低签名、Device Key 绑定、确认页防钓鱼、授权或 fail-closed 基线。HTTP well-known 只用于预检，认证握手才是最终权威。

#18. 仓库边界

各仓库的内部模块、接口、状态与测试要求以组件实现规格和实施蓝图为准；本节只定义所有权。

仓库名中的 -next 是产品线隔离标识，不代表迁移层。产品名和二进制统一为 NS App 与 ns；是否重命名仓库是独立的工程管理决策。

#19. 分阶段实施路线

#Phase 0：全新契约与测试基建

• 建立 Next 原生 schema v1、独立事件版本、能力枚举和真实序列化契约测试；
• 定义 Enrollment、Device、Network Membership、Grant、Service、Entitlement 和 Audit 的权威边界；
• 建立跨平台原生网络测试实验室；
• 复用代码前逐模块证明其满足 Next 契约，不读取旧状态目录或数据库。

退出条件：新 Organization 可以从空数据库完成登录、注册、授权和配置投影；协议契约、错误分类与 fail-closed 反向测试全绿。

#Phase 1：统一 ns 与 L4 Service

• 发布一个 ns 二进制和一个 NS App；
• 用 Capability 表达 endpoint、service_host 和受管网络能力；
• App/CLI 都可发布和消费 Next Service；
• NSD 只保存和编译 Next 原生对象。

退出条件：同一新注册节点可以同时访问服务并发布服务，Service Grant 与 Node Grant 独立生效。

#Phase 2：基础 L3 节点网络

• Device、Network Membership、稳定 Node IP、Node DNS；
• 桌面/移动端默认 TUN/VPN API，Linux 服务器可选内核 WireGuard；
• endpoint discovery、STUN/路径探测、漫游、MTU、直连 WireGuard；
• 免费托管/社区 Relay 与 UDP 封锁时 WSS/TLS 回退；
• 个人默认模板与企业默认拒绝；
• peer map 裁剪与双端 ACL。

退出条件：个人两台设备在同 LAN、普通 NAT、CGNAT、双端 symmetric NAT 和 UDP 封锁场景下，都达到 §11.4.2 的 p95 首次可用目标，并通过直连或 Relay 按名称互访；企业未授权节点不可见、不可达；网络切换在目标时限内恢复且 Node IP 不变。

#Phase 3：统一策略与服务目录

• Grant v1 同时表达 Node、Service、Route 和 Exit；
• GrantSet/GrantRule 规范化、策略版本、模拟、审批和审计归因；
• Service HA、多 Endpoint、健康路由；
• App 服务发布和企业应用门户；
• SSO/SCIM/Posture/审计对齐新对象。

退出条件：企业可以关闭员工横向 L3，只通过服务目录开放应用。

#Phase 4：子网、应用连接与 NSGW 商业化

• Subnet Router、App Connector；
• 区域/专属 Managed Relay、Public Ingress、Gateway Egress、Gateway Exit；
• 区域 PoP、固定 IP、证书/WAF、SLA、流量与审计导出。

退出条件：基础 L3 在没有付费/专属 NSGW 时仍能通过直连或基础 Relay 工作，购买 NSGW 后只增加区域质量、SLA 和被授权的边缘能力。

#Phase 5：企业治理与规模化

• SSO/SCIM/MDM、设备姿态、审批工作流与策略模拟；
• PostgreSQL HA、区域部署、审计/SIEM 导出和 SLA；
• 批量 Enrollment Reservation、资源用量对账和 Entitlement 运维工具；
• 协议按独立版本轴演进，并验证旧一版 Next 客户端的 additive 行为。

退出条件：企业身份、策略、审计、规模和 entitlement 事务在生产拓扑下达到记录的撤销、性能和隔离目标。

#Phase 6：商业交付与运营成熟

• 签名安装包、商店/MDM/package-manager 发行、灰度升级和完整卸载；
• Product Catalog、Quote/Order/Subscription、付款、发票、dunning 和 entitlement 对账；
• 分服务 SLI/SLA、状态页、事故响应、支持和隐私激活漏斗；
• Hosted/Self-hosted 备份、restore epoch、RPO/RTO 和 key recovery 演练；
• Trust Center、数据清单、导出/删除、Legal Hold 和合规证据路线。

退出条件：产品可以被安全安装和移除、可以收款开票、可以公开解释事故、可以从空环境恢复，并能完成数据权利请求；任何商业或运营故障都不被压成网络授权事实。

#20. 验收矩阵

#20.1 产品验收

• 新个人用户不进控制台即可完成两台设备互通；
• 企业员工通过 SSO 加入后只看到被授权资源；
• 服务器可用短期 Enrollment Key 自动加入；
• 同一 ns 节点可同时访问 L3、消费 Service、发布 Service；
• 关闭 L3 横向授权不影响 L4 Service；
• 无 NSGW 时直连/社区中继可用；有 NSGW 时增值能力按授权出现。
• 切换 Organization/Network/Profile 时明确显示影响，首版不合并多个独立 NSD 的系统路由与 DNS。

#20.2 安全验收

• 未授权节点不进入 peer map，伪造包仍被目标端拒绝；
• Service 远端授权不能突破节点本地 manifest；
• 跨 Network、跨 Organization 的 ID 重放失败；
• 跨 Organization Share 任一方撤销都在租约 SLA 内生效，双方 API 不可枚举对方目录；
• Enrollment Key 泄露的影响受标签、能力、次数和到期限制；
• NSGW relay 无法解密端到端流量；
• Exit/Route 故障不发生静默本地直出；
• 删除用户、Membership 或 Grant 在规定撤销 SLA 内生效。
• 同机另一 OS 用户不能读取或控制 runtime owner 的 Profile、目录、密钥和网络；快速切换不会复用前一用户的系统隧道。

#20.3 协议与演进验收

• Next 新增可选字段时，旧一版 Next 客户端按 schema 规则忽略或明确降级；
• 新增必需语义时提升对应协议面的 major version，不联动提升其他版本轴；
• 未知 major、签名错误、回滚 revision 和无法解析的安全状态必须显式拒绝；
• Capability Manifest 不能触发更宽松的授权或确认流程；
• 真实序列化结构必须通过发布的 schema，不能只验证 fixture 自洽；
• 旧 NSIO 的二进制、数据库和状态目录不能被 Next 误识别或自动读取。

#20.4 真机验收

• Windows、macOS、Linux、iOS、Android 的 TUN、DNS、休眠唤醒和网络切换；
• Tailscale/ZeroTier/企业 VPN 共存与路由冲突；
• 普通 NAT、CGNAT、双端 symmetric NAT、UDP 封锁、NAT rebinding、直连与 Relay 切换；
• IPv4/IPv6 双栈、子网重叠、Exit fail-closed；
• App、CLI、服务进程和 MDM 安装升级。
• Windows/macOS/Linux 两个 OS 用户快速切换、并发会话、owner logout 和冷启动；user-owned 模式在 owner 出现前不建网并先撤网络再交出 console，managed-device 模式可无人值守恢复且不被交互用户接管。
• 商店/官网/包管理器安装，签名更新中断恢复与卸载后网络清理；
• Hosted region 故障、公开状态通报、SLA bucket 与空环境灾难恢复；
• 账号/Organization 导出删除、Legal Hold 和备份恢复后不复活。

#21. 关键架构决策

#22. 竞品借鉴与 NSIO 差异

#22.1 从 Tailscale 借鉴

• 用户登录后自动创建/加入私有网络；
• 每节点稳定私有 IP 与 DNS 名称；
• 人类身份与节点身份分离，服务器使用 Auth Key/Tag；
• 控制面不承载业务流量，优先 P2P；
• peer 可见性与连接权限分开；
• Grants 可按用户、组、标签、IP、端口和姿态表达；
• Subnet Router、Exit Node、App Connector 是网络能力，不是另一套客户端。

#22.2 从 ZeroTier 借鉴

• Organization → Network 的清晰层级；
• Network 创建、第一台设备加入和授权的交互式引导；
• 设备即使没有登录账号，也可通过 Network/Enrollment 凭据加入；
• 控制面中断后，已建立数据连接在租约内继续；
• 层级 RBAC、服务账号和 API 适合 MSP/大型组织。

#22.3 NSIO 必须保留的差异

1. L4 Service 是一等资源，不只是节点端口规则；
2. 服务发布者本地声明是安全底线；
3. Service VIP、命名、自定义域名和应用门户形成完整应用访问体验；
4. Gateway Egress 面向“从特定网络/IP 访问应用”，Gateway Exit 面向“互联网默认出口”，两者不混用；
5. NSGW 提供可自建也可托管的企业增值边缘，而基础 L3 不被网关绑架。

#23. 参考资料

#Tailscale 官方资料

• What is a tailnet?
• Tailscale identity
• Device visibility
• Grants syntax
• Tailscale Services
• App connectors

#ZeroTier 官方资料

• Quickstart
• New Central API and resource hierarchy
• Enterprise deployment
• SSO / OIDC

#24. 最终产品判断

NSIO Next 不应成为“Tailscale 的另一个实现”，而应成为：

Tailscale 式的简单节点网络 + NSIO 已经具备的服务级零信任 + 可独立部署的企业边缘。

个人用户先得到简单的节点互联；企业在同一客户端和同一策略体系上继续获得服务目录、最小权限、应用连接、固定出口、公网入口、审计和私有部署。L3 扩大产品入口，L4 与 NSGW 构成商业差异和收入层，两者必须同时成立。