跳转到内容

仓库说明

NSIO 由若干独立仓库组成。本页列出每个仓库负责什么、产出什么、依赖谁,以及本站对应的页面。职责清单保留原始架构背景;当前依赖与进度已按 2026-10-20 远端分支核对,见分支依据。

仓库远端一句话产物本站
nsgit.pvv.cc/nsiod/ns端侧节点:CLI 与 libnsns 二进制、libns(C ABI)NS
nsdgit.pvv.cc/nsiod/nsd控制面:身份、策略、配置分发,不承载业务流量nsd、nsdctl、管理 Web、SDK、Terraform providerNSD
nsgwgit.pvv.cc/nsiod/nsgw数据网关与 Quick relaynsgw-server、新线 nsgw-relayd(旧线 nsgw-quick-relay)NSGW
nsplanegithub.com/dotns/nsplane数据面库(原 nstun)Rust crate(0.17 起含 nsplane-ether、nsplane-dns);nsplane-cli 开发工具nsplane
nssharedgit.pvv.cc/nsiod/nsshared;另有公开仓库 github.com/dotns/nsshared跨组件共享的通用协议与工具Rust crate;基础 tag v0.6.0,main 95f1688(2026-10-25)重组为按契约划分的 crate,M6 / L8 另按 revision 推进nsshared
docsgit.pvv.cc/nsiod/docs本站与跨仓库的设计记录Astro / Starlight 静态站点—
deploy../deploy(本地未检出)部署:Ansible playbook 与 DEV / TEST / PROD inventory部署流程—

依赖方向:

ns ──► nsplane(main pin v0.19.1,含 nsplane-dns;每个 membership 一个本地身份)
ns ──► nsshared(固定 revision 3c48566b:重组前的 proto、Service Control、telemetry 与 mock 门面;R3 分支另有 L8 候选)
nsgw ──► nsplane v0.19.1、nsshared 95f1688(重组后的定义 crate;next / R3 按各自 revision 固定,开发交付与生产验收分开)
nsd ──► nsshared(proto、Service Control;其余 L8 producer family 逐项推进)
nsgw、nsd 发布 ──► deploy
  • 负责:节点运行时与 ns CLI;账户模式(登记到 NSD,tun / dns-vip / proxy 呈现,服务发布、子网路由、出口)与 Quick 模式(无账户的配对与 relay);应用(ns send 等,设计中);libns 嵌入接口与各平台边界(macOS、Windows、iOS、Android 宿主)。
  • 主要 crate:ns(运行时与 CLI:node_engine、account_engine、engine::memberships、key_chain、policy、quick、app_channel)、ns-ffi(libns)、overlay(覆盖网核心)、控制侧残余 nat(路由模型)、proxy、acl(策略编译),共享副本 control、common、telemetry,以及 secure-storage、posture、updater、privdrop、certstore 等平台能力。
  • 方向:账户模式(2026-10-03)与 Quick 模式(2026-10-04)都已只运行在 nsplane 引擎上,旧数据面 crate 已删除;2026-10-12 起按决策 2026-10-11-node-memberships 以平等的 membership 同时连接多个 NSD 与 Quick(ns network join / leave),身份由设备密钥链派生,账户 Node 改为身份对端(需要 NSD 配套);ns 侧于 2026-10-13 完成并通过多节点互通套件。按 新架构 分为覆盖网核心、呈现与功能模块,进度见迁移计划 §4.1;control 等 v1 副本留到 M6。
  • 不负责:relay 与网关(nsgw)、控制面服务端(nsd)。
  • 负责:唯一的强一致状态源;签发身份与令牌,合成并分发策略与配置(配置流与 envelope API,经 SSE / Noise / QUIC),管理账户、Network、Node、Service、网关、公网入口、证书与用量;从不承载业务流量。
  • 主要 crate:nsd(主程序)、nsd-api、nsd-distribute(签名事件与分发)、nsd-policy(ACL 合成与投影)、nsd-registry、nsd-store(SQLite / PostgreSQL)、nsd-auth、nsd-admin、nsd-telemetry、nsd-cli(nsdctl)、nsd-noise-proxy、nsd-quic-proxy、nsd-proto-bridge(预留给共享线上类型)。另有 web/(管理界面)、sdks/(Go、Python、TypeScript)、terraform-provider-nsd、migrations/。
  • 不负责:节点与网关的运行时行为,只通过投影描述它们应当如何运行。

以下列旧线职责供迁移对照;当前新线 R1 relay v2 开发已交付,R3 机制实现中,见网关进度。

  • 负责:两个独立二进制。
    • nsgw-server:账户模式的网关。终结或盲转发 WireGuard(wg-relay、terminate、wss-relay),经 Envoy 提供 HTTP / TCP / UDP 公网入口与外部认证,GatewayEgress / GatewayExit,向 NSD 登记、订阅配置流并上报。
    • nsgw-quick-relay:Quick 模式的免账户 relay(UDP 与 /keynet/v1 WSS 载体)、/quick/v1 短码会合(将由与应用无关的 /rendezvous/v1 会合服务 取代)、relay 区域(成员网状连接、复制、owner 栅栏)。
  • 主要 crate:nsgw-server、nsgw-control、nsgw-wg、nsgw-wss、nsgw-envoy、nsgw-api、nsgw-routing、nsgw-gateway-egress、nsgw-quick-relay。
  • 依赖:nsshared v1 工作区(本地副本,归档于 tag archive/v1-20261002)的 control、common、acl、tunnel-ws、telemetry、keynet-proto、keynet-quick;仍用 crates.io boringtun 0.7.1 做用户态 WireGuard 回退。
  • 不负责:任何应用语义(relay 与应用无关)、节点侧的路径选择规则。
  • 负责:节点的数据面引擎:WireGuard、多传输与路径策略机制、报文过滤链(ACL、翻译、计量)、netstack、TUN;以及应用会话所需的机制(会话对端、隧道内连接、ACL 命名空间与 pinhole)。每个节点一个引擎。源自 cloudflare/boringtun(BSD-3-Clause),原名 nstun。
  • 主要 crate:nsplane-noise(noise 核心)、nsplane-packet、nsplane-core(无 I/O 状态机)、nsplane(tokio 驱动)、nsplane-tun、nsplane-netstack、nsplane-acl、nsplane-nat、nsplane-wss、nsplane-uapi,0.17 起另有 nsplane-ether(以太网适配器)与 nsplane-dns(通用 DNS 服务);按 tag 发布(v0.8.0–v0.19.2),接口见 nsplane 架构与接口。nsplane-cli 只是 Linux / macOS 开发工具。
  • 不负责:控制面、配对、身份与地址分配、路径规则(由 ns 决定);会合信箱客户端、应用会话接口与应用协议(由 ns 实现)。
  • 负责:两个以上组件都要编解码或执行的通用协议与工具:身份与派生、NodeRecord、relay 报文 v2、会合协议消息、编码工具、tracing 初始化;另有给 ns 测试用的模拟服务。详见 nsshared。
  • 主要 crate:main 95f1688(2026-10-25 重组)为 nsshared-codec、nsshared-identity、nsshared-relay、nsshared-rendezvous、nsshared-control、nsshared-telemetry,nsshared-proto 与 nsshared-service-control 为弃用门面,另有不发布的 nsshared-testkit 与 nsshared-mock-relay / nsshared-mock-rendezvous / nsshared-mock-server(tag v0.6.0 时为 nsshared-proto、nsshared-telemetry;v0.1.0 为 nsshared-wire、nsshared-rendezvous)。v1 工作区(control、common、acl、tunnel-ws、telemetry、keynet-proto、keynet-quick)归档于 tag archive/v1-20261002,nsgw 仍消费它的本地副本。
  • 不负责:数据面、应用会话、产品逻辑、NSD 服务端、网关运行时。
  • 负责:面向使用者与开发者的系统文档(本站)、跨仓库的设计页(例如 新架构、会合协议),以及 docs/ 下的任务、计划与 changelog。
  • 结构:website/(Astro + Starlight,bun run build 含类型检查与链接检查);侧边栏在 website/src/shared/site.ts。
  • 规则:描述现状的页面写明对应的仓库 commit;设计页标注”设计阶段”。各仓库自己的 docs/ 记录实现细节与任务,本站记录组件之间的关系。
  • 负责:网关等组件的部署:共享的 Ansible playbook(如 playbooks/nsgw.yml)、DEV / TEST / PROD inventory、由 nsgw CI 在稳定 tag 上调用的 TEST 部署流程。
  • 说明:本地工作区没有检出,内容依据 nsgw 的 README 与 CI 引用;PROD 部署为手动。

这些仓库是 dotns 的独立开源工具,不是 NSIO 的组成部分,也不被 NSIO 代码依赖。

仓库是什么与 NSIO 的关系
nsl本地开发反向代理:为本地服务提供稳定的 *.localhost 名字nsd 的本地开发流程使用
certoACME DNS-01 的 TXT 记录管理服务(兼容 lego httpreq 与 acme-dns),在线服务 dnsall.com目前无依赖;新架构 计划用 DNS-01 为 relay.ns.io 与 n.ns.io 签证书,可作候选
lode通用的”校验 · 启动 · 更新”加载器:校验应用包的完整性与发布者身份后启动、监管并热更新目前无依赖