#NSIO Next · 发行、升级与卸载生命周期

状态：产品发行与客户端生命周期实现依据。本文约束 NS App、ns daemon/CLI、平台 helper、移动端 Tunnel Extension 和企业托管安装。网络行为仍以统一架构和ns 组件规格为权威。

#1. 不变量

1. 一台设备在一个 OS 安装域内只有一个活动 ns 网络运行时。
2. NS App、CLI、系统 helper 和 MDM 都通过同一个版本化本地 API 操作该运行时，不各自创建 TUN、DNS、路由或密钥状态。
3. 桌面 user-owned 模式在同一时刻只有一个本地 OS principal 可以拥有交互控制权；系统级 TUN、DNS、Route 和 Exit 不能跨 OS 用户静默复用。
4. 发行包、更新清单和二进制都必须签名；下载成功不等于可信，安装前必须验证签名、平台、架构、版本和摘要。
5. 更新失败保留最后可启动版本和最后有效网络状态，不留下半升级的 helper、Extension 或 daemon。
6. 卸载先恢复网络，再删除程序；删除程序失败不能以“卸载完成”掩盖仍存在的系统配置。
7. 旧 NSIO 与 Next 没有运行时兼容义务；Next 自身从首版开始遵守本文件的升级纪律。

#2. 安装拓扑

#2.1 桌面与服务器

NS App ─┐
        ├─ authenticated local IPC → one ns daemon → TUN/WG/DNS/routes
ns CLI ─┘                              ↑
                                  platform helper

App 可以随安装包携带与自己验证过的 daemon artifact，但不能长期私有运行第二份 daemon。安装器发现现有 Next daemon 时按以下矩阵处理：

单实例锁必须覆盖 daemon endpoint、状态目录和平台网络所有权。锁冲突返回持有者 PID、版本和安装来源，不通过删除锁文件盲目抢占。

#2.2 多用户桌面与本地所有权

首版采用 single-active-OS-user，不在同一主机上为每个 OS 用户启动独立 daemon/TUN。RuntimeOwnerBinding 是安装级本地安全对象，至少记录 installation_id、owner_mode、平台提供的稳定 OS principal 标识摘要、状态和 revision；用户名、NSIO 邮箱、Organization 和 Network 不写入可被其他本地用户读取的占用信息。

daemon/service 可以随系统开机启动，以恢复未完成 journal、提供版本/维护接口并观察 OS session；这不等于数据面自动连接：

规则如下：

1. OS principal 是本地授权边界，不替代 NSIO 登录。一个本地所有者可以登录个人和企业 Profile；每个 Organization 仍使用独立 Device Key，runtime 一次只激活一个 Profile。
2. daemon 必须从本地 IPC 的 peer credentials 取得调用者身份，不能相信请求 payload 自报的 UID/SID。user-owned 控制命令还要验证与 owner binding 绑定的本地 client credential。
3. 非所有者只能调用脱敏的 version、ownership status 和管理员授权后的 repair/update 接口。返回 runtime_owned_by_another_local_user，不得泄露对方用户名、账号、Organization、Network、目录、配置、运行日志或流量状态，也不能 start、stop、switch、publish、configure Exit 或导出对方诊断。
4. 屏幕锁定且没有其他交互用户激活时可以保持连接。检测到 console owner 切换、并发交互会话或 owner logout 时，daemon 必须在新用户可使用该系统网络前停止转发并撤销 owner 的 TUN/DNS/Route/Exit 投影，保留加密身份和配置于静态存储，进入 owner_inactive。平台不能证明这个顺序时，user-owned 模式保持断开，不能以“快速切换”为由让另一用户经过原隧道。
5. 原所有者返回后显示“网络已因本机用户切换暂停”，由用户或管理员策略明确重连。第二个 OS 用户不能透明接管；只有原所有者显式释放，或 OS 管理员执行会清除本地 identity 的破坏性 reset 后，新的 principal 才能 claim。
6. OS 管理员拥有程序维护和网络恢复权限，不因此获得原所有者的 NSIO 会话、Device Key 或租户数据。管理员 reset 不伪装成服务端 Device revoke；离线时留下 remote_revoke_pending 事实。
7. 首版不支持多个交互用户同时使用不同 NSIO 身份共享一条系统级隧道。企业共享工作站应使用专机/单用户会话，或显式配置 managed_device 模式；后者按 Device/service identity 审计，不声称提供逐人流量归因。

#2.3 移动端

iOS/Android 不发布独立 CLI daemon。NS App 是产品入口，Packet Tunnel Provider/VpnService 是受平台管理的 ns runtime。App 与 Extension 通过平台允许的共享容器和消息接口交换最小配置、operation 和 status；私钥只进入系统安全存储与 Extension 可访问范围。

关闭 App 不等于断开 VPN。Extension 被系统回收后按平台恢复模型重建，不依赖 App 前台存活。

#3. 本地 API 与版本握手

App/CLI 建立本地连接时交换：

{
  "client": {"name": "ns-app", "version": "1.4.0", "api_range": [1, 2]},
  "daemon": {"version": "1.3.2", "api_range": [1, 1]},
  "installation_id": "ins_01",
  "runtime_instance_id": "run_01",
  "managed_by": "system-package"
}

本地 transport 必须先取得不可伪造的 OS peer credential，再做 owner authorization 和版本协商。协商只选择双方共同支持的本地 API major。没有交集时只能调用 version、脱敏 diagnostics 和 update; 不允许绕过版本或 owner 检查直接写配置。App 的展示缓存不能代替 daemon 状态。

#4. Artifact 与供应链

每个发行 artifact 有不可变记录：product、platform、architecture、version、build commit、build provenance、SBOM digest、artifact digest、signing key ID、not-before/not-after 和 channel。CI 只从受保护 tag 构建；发布服务不能接受开发者本机上传的任意二进制成为 stable。

签名层：

• 平台签名：Apple codesign/notarization、Windows Authenticode、Android signing、Linux repository metadata；
• NSIO release manifest 签名：为跨平台 updater 和审计提供共同权威；
• key rotation：新旧 release key 有明确交叉窗口，撤销 key 的 manifest 由仍受信任的 offline root 签发；
• artifact mirror：镜像只缓存字节，不成为签名权威。

#5. 发行通道

同一 Installation 只能跟随一个通道。切换到更不稳定通道必须明确确认；从高版本降到低版本仅允许发布系统标记为 rollback_safe 且状态 schema 可回读时执行。

#6. 更新发现与安装

更新 manifest 至少包含：latest、minimum-supported、minimum-secure、rollout cohort、channel、artifacts、release notes、known issues、rollback target、required OS、local API 范围和 Runtime Control 范围。

流程：定期或手动检查 → 验签 manifest → 确认 cohort/channel → 下载临时文件 → 验签 artifact/SBOM 摘要 → 预检查磁盘、权限、状态 schema 和活跃操作 → 写升级 journal → drain 新连接 → 安装 → 启动并完成健康检查 → 提升 active slot → 清理旧 slot。

升级不得默认断开正在工作的隧道。必须重启 runtime 时，App/CLI 展示原因、预计影响和 maintenance window；企业管理员可以计划窗口。安全紧急更新可以设置 deadline，但在 deadline 前持续告警并提供审计证据。

#6.1 平台更新路径

#7. 兼容窗口与强制升级

Next stable 服务端默认支持当前 Runtime/Enrollment major 与前一 stable major，前一 major 自后一 major 全量可用起至少保留 90 天。新增 major 前必须：

1. 所有受支持平台已有可安装 stable artifact；
2. 企业 MDM/offline 包已经可获取；
3. 状态页和管理端能统计受影响客户端但不暴露个人网络信息；
4. App/CLI 对“可更新”“即将不支持”“已因安全撤销停止”使用不同状态；
5. 回滚路径或前向修复路径已经演练。

严重安全事件可以缩短窗口。minimum-secure 低于当前版本时，控制面拒绝新敏感操作；是否继续现有数据面由漏洞影响和已签发 lease 决定，必须形成单独安全事件和用户说明，不能借“升级”静默改变授权。

#8. 灰度、暂停与回滚

灰度按稳定随机 cohort，不按账号价值或流量内容选择。每一阶段观察 crash-free rate、daemon 启动、TUN 成功、DNS/route restore、登录、enrollment、直连/Relay 和 uninstall cleanup。任一硬门越界自动暂停放量。

回滚分两种：

• 分发回滚：停止向新设备提供问题版本，恢复上一 artifact；
• 已安装恢复：只有状态向后兼容时降级，否则发布 forward-fix。不得让旧二进制读取它不理解的新私钥或 journal schema。

协议 major 和数据库/本地状态 schema 版本相互独立，不能因为控制协议升级就假定本地状态可降级。

#9. 移动应用商店发布门

商店要求会变化，每次提交前必须由发行 owner 重新核对官方政策并保存审查快照。

#9.1 Apple

• 使用 Packet Tunnel Provider/Network Extension 正式 entitlement 和受支持 API；
• 发行主体使用 Organization 开发者账号；
• 在用户购买或使用前，于 App 内明确披露 VPN 相关数据收集、用途和共享边界；
• 隐私政策、App Privacy、审核备注、演示账号和区域许可信息与实际行为一致；
• 真机验证 App、Extension、升级、休眠、网络切换和卸载配置。

当前依据：Apple App Review Guidelines §5.4 与 Network Extensions Entitlement。

#9.2 Google Play

• VpnService 必须属于产品核心 VPN/远程访问能力，并完成 Play Console declaration；
• 商店页面和 App 内显著披露用途；涉及个人/敏感数据时取得明确同意；
• 设备到 tunnel endpoint 的数据保持加密，不用 VPN 流量做广告或流量变现；
• 提交可复现的连接与披露演示，Data Safety 与实际 telemetry 一致；
• 使用 internal/closed/staged rollout，并保留暂停发布能力。

当前依据：Google Play VpnService policy 与 staged rollout。

#10. 卸载与重置

#10.1 用户选择

卸载向导区分：

1. 仅删除 App UI：桌面仍保留 daemon/CLI 和网络连接，明确提示后台服务仍存在；
2. 删除程序并断开网络：停止 runtime、恢复系统网络、删除程序，保留 Device identity 以便重装恢复；
3. 从此设备彻底移除：在可达时先请求撤销 Device/Membership，再恢复网络并删除密钥和本地数据；离线时生成待撤销记录并提示管理员仍需远程撤销。

移动端由平台删除 App/Extension；服务端 Device 不因本地卸载自动消失，管理端显示离线并允许撤销。

user-owned 桌面上只有 runtime owner 可以选择“仅删除 App UI”或发起带远端撤销的完整移除。其他普通 OS 用户不能停止、删除或撤销该 owner 的运行时。OS 管理员/MDM 可以执行程序移除与网络恢复，但不能解密或使用 owner identity；需要删除密钥时必须明确标记为 destructive reset，并把未完成的服务端撤销显示为待处理。

#10.2 网络清理顺序

停止新流量 → 撤 capture/Exit → 撤 owned route → 恢复 DNS/proxy → 删除 TUN/adapter → 停 helper/daemon → 复验公共网络 → 删除程序。只删除带 Installation ID、owner marker 和 journal 证据的对象；发现外部对象冲突时停止清理并提供 ns cleanup --diagnose，不猜测删除。

卸载器必须在 App 文件删除后仍可完成恢复，因此 cleanup helper 是独立、签名、一次性执行的组件。失败保留 recovery journal 和离线修复命令，不显示成功。

#11. 企业托管

企业策略可配置通道、允许延期天数、维护窗口、是否允许用户退出 beta、是否允许自更新和最低版本。管理员看到设备版本、更新状态、失败码和最后检查时间；看不到用户访问的域名或业务流量。

MDM 卸载、人员离职和 Device revoke 是不同事务。离职可以撤销 Membership 而保留 Organization-owned Device；MDM wipe 可以删除本地 identity；普通用户卸载不能伪装成服务端安全撤销。

#12. 错误与恢复

#13. 发布完成门

• App、CLI、daemon 并行操作证明只有一个 runtime；
• Windows/macOS/Linux 真机覆盖两个 OS 用户、快速用户切换、并发登录和 owner logout：非所有者看不到租户数据、不能控制 runtime，且没有一包流量复用原所有者隧道；
• 冷启动时 user-owned runtime 在 owner 登录前不建立控制/数据面；managed-device 在无人登录时按策略恢复，二者不能因同一个“开机自启”设置混淆；
• user-owned 与 managed-device 两种模式不能互相静默转换，管理员 reset 与服务端 revoke 的结果分别可审计；
• 每个平台完成全新安装、覆盖升级、跨 major 提示、暂停灰度、forward-fix 和卸载；
• 升级中断于下载、安装、首次启动各阶段均可恢复；
• 外部 VPN、DNS、route 和防火墙对象不会被卸载器删除；
• 删除 App 后网络正常，残留 helper/service/Extension/driver/route/DNS 为零；
• MDM pin、maintenance window、minimum-secure 和审计可验证；
• App Store/Play 政策清单由真实发行 owner 签字并附当次官方链接；
• 注入签名错误、版本冲突和 cleanup 失败时，相应测试必须失败。