跳转到内容

仓库说明

NSIO 由若干独立仓库组成。本页列出每个仓库负责什么、产出什么、依赖谁,以及本站对应的页面。内容按 2026-10-02 各仓库的工作树核实;分支与版本会变化,以各仓库自己的 docs/ 为准。

仓库远端一句话产物本站
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-quick-relayNSGW
nsplanegithub.com/dotns/nsplane数据面库(原 nstun)Rust crate;nsplane-cli 开发工具nsplane
nssharedgithub.com/dotns/nsshared(公开;原 git.pvv.cc/nsiod/ns-shared)跨组件共享的通用协议与工具Rust crate,按 tag 发布(v0.6.0)nsshared
docsgit.pvv.cc/nsiod/docs本站与跨仓库的设计记录Astro / Starlight 静态站点—
deploy../deploy(本地未检出)部署:Ansible playbook 与 DEV / TEST / PROD inventory部署流程—

依赖方向:

ns ──► nsplane(tag `v0.14.0`:账户模式与 Quick 都在引擎上,每个 membership 一个本地身份)
ns ──► nsshared(tag `v0.5.0`:`nsshared-proto`、`nsshared-telemetry`、测试用 mock;`control` 等 v1 副本留到 M6)
nsgw ──► nsshared(旧布局 `main` 的 path 依赖,CI 按 commit 固定)
nsd ── 契约另一端,类型目前在 nsd 内定义
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/。
  • 不负责:节点与网关的运行时行为,只通过投影描述它们应当如何运行。
  • 负责:两个独立二进制。
    • 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;按 tag 发布(v0.8.0–v0.14.0),接口见 nsplane 架构与接口。nsplane-cli 只是 Linux / macOS 开发工具。
  • 不负责:控制面、配对、身份与地址分配、路径规则(由 ns 决定);会合信箱客户端、应用会话接口与应用协议(由 ns 实现)。
  • 负责:两个以上组件都要编解码或执行的通用协议与工具:身份与派生、NodeRecord、relay 报文 v2、会合协议消息、编码工具、tracing 初始化;另有给 ns 测试用的模拟服务。详见 nsshared。
  • 主要 crate:nsshared-proto、nsshared-telemetry,以及不发布的 nsshared-mock-relay / nsshared-mock-rendezvous / nsshared-mock-server(当前 v0.6.0;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通用的”校验 · 启动 · 更新”加载器:校验应用包的完整性与发布者身份后启动、监管并热更新目前无依赖