计算与网络
YaoVPN
站点互联与分类访问配置
YaoVPN 将站点、中心节点、代理出口和客户端策略写入同一份拓扑，生成原生引擎配置与可导入的客户端材料。Common 提供普通访问，Internal 另有专用私网站点入口。配置生成、本地网络启用与目标真正响应分别核对，便于维护多站点网络。
为站点与个人终端提供不同访问路径 站点 Gateway 经 Hub 互联；普通终端使用 Common 策略，获准进入私网站点的终端使用 Internal。客户端通过自己的访问入口取得权限，不接收站点 WireGuard 私钥。
用拓扑连接角色与策略
YaoVPN 面向一位受信管理员维护的网络。一份拓扑说明出口代理、站点网关（Gateway）、中心节点（Hub）、可选远端接入节点和受管主机之间的关系，准备过程只读取所选角色真正需要的事实。
从客户端看，主要区别在于目标是否属于私网站点。Common 与 Internal 共享普通访问规则，Internal 另有独立的站点入口和凭据；导入配置不等于目标已经可达，连通性仍要用实际请求验证。
Xray、Hysteria2 与 Mihomo 承担代理协议、路由和 DNS 解析，内核 WireGuard 提供站点间链路。YaoVPN 生成这些原生引擎可直接使用的材料，并管理获准的本地网络操作与配置发布，无需另一个常驻自研 VPN 代理。
按使用者取得恰当的原生材料
站点管理员维护各角色的位置、站点网段、对端和必需凭据；个人终端取得的则是能够导入客户端的 Common 或 Internal 配置。两类输入服务于不同任务：站点材料建立互联，客户端材料选择出口及获准的私网路径。
完整交付应让接收者知道由哪个原生引擎加载材料、需要哪些已有网络条件、以及如何观察实际目标。文档发布只是材料分发，不把发布链接当作对所有终端的即时控制通道。
| 接收者 | 所需内容 | 后续核对 |
|---|---|---|
| 站点 Gateway / Hub | 对应角色的 WireGuard 对端、精确路由与原生服务配置。 | 本地资源、对端关系与真实站点流量。 |
| Common 客户端 | 普通出口与直连策略；声明的站点网段不开放。 | 客户端实际采用的策略与普通目标响应。 |
| Internal 客户端 | 普通访问策略，加独立私网入口及对应凭据。 | 站点目标走获准私网入口，且回程能到达原客户端。 |
站点互联有明确的本地资源范围
中心节点连接各站点网关，网关保留原有局域网（LAN）地址与站点网络。准备结果指定 WireGuard 对端、精确路由和必要来源地址；站点间流量保留原来源地址，不做源地址转换（SNAT）。远端私网接入节点则使用独立返回路径与条件地址转换。
网络启用和停止是有限操作，只取得并清理该角色拥有的接口、地址、路由与条件 NAT。冲突对象不能因同名而被接管。启用完成表示本地结果已建立，不表示对端持续可达；LAN、全局转发、防火墙与返回路由仍需管理员提供。
| 角色 | 承担的工作 | 保持独立的责任 |
|---|---|---|
| 中心节点 / 站点网关 | 站点对端与指定路由 | 现有 LAN、转发策略与外部返回路径。 |
| 代理出口 | 按普通或私网用户策略转发 | 原生引擎运行与管理员授权。 |
| 配置发布服务 | 提供客户端配置与固定规则文件 | 公共 DNS、TLS、入口和缓存管理。 |
普通访问与私网访问使用不同配置
面向普通访问的 Common 配置与允许访问站点的 Internal 配置，共享普通出口和直连规则。Common 拒绝声明的站点和回程网段；Internal 为站点目标选择独立私网入口，采用 VLESS 协议和不同于普通出口的凭据。两类客户端都不包含 WireGuard 私钥。
站点与类别规则先于普通直连（DIRECT）例外，防止直连规则扩大私网权限。站点网关使用自身局域网与 WireGuard 路径。Linux 配置使用引擎自带的备用出口选择，导入客户端的配置通过选择组确定出口；失败中的既有请求不会因此自动重发。
| 客户端 | 普通出口 | 私网站点 |
|---|---|---|
| Common | 可用：共享普通规则 | 拒绝站点及回程网段 |
| Internal | 与 Common 使用相同规则 | 独立入口与独立凭据 |
Internal 的站点流量经独立入口、Hub 和 Gateway。两类客户端均不持有站点 WireGuard 私钥。
生成、运行和发布分别完成
准备过程生成各角色的原生配置、程序绑定和服务依赖。修改配置源不会立即改变运行中的网络；替换 WireGuard 计划之前，需要结束依赖它的本地使用者，并完成旧资源的清理。未完成的清理仍保留实际责任。
配置发布服务独立提供可导入客户端的 Common、Internal 配置和两份固定规则文件，启动时载入完整目录。导入链接更新后，旧路径可以失效，但已经下载的服务器凭据和外部缓存不会因此撤销。公开入口、传输保护与凭据变更需要管理员协调。
声明
维护拓扑、角色输入和明确的访问类别。
生成
产出原生配置、服务材料与客户端文档。
启用
由原生服务建立其明确拥有的运行资源。
观察
分别核对本地状态、实际数据通路与文档访问。
更新拓扑时，同时处理运行状态与已分发凭据
拓扑变化先产生新材料，再由获准的操作应用到实际角色。涉及 WireGuard 计划替换时，先结束依赖旧计划的本地使用者，再清理原接口、路由等已拥有资源；清理尚未结束，就保留原责任并阻止冲突替换。
客户端材料更新还要考虑旧副本：删除导入路径不能撤回已下载的凭据，外部缓存也可能继续提供内容。撤销访问应落实到服务器端凭据和实际准入策略，再检查旧凭据不能继续取得相应路径，而不是只检查网页链接已失效。
可以确认：目标收到沿选定路径发出的请求
结合实际对端与路由观察，可以支持该部署下所测试通路的结论。
不能推断：配置可导入即所有流量都已受控
原生引擎加载、宿主网络条件与具体目的地址仍各有范围，不能扩展成通用隔离保证。
继续核对：本地启用已完成
还需检查远端、返回路由与真实请求；本地资源建立不表示对端持续可达。
让实际流量证明通路
配置可解析、服务已启动、接口已出现与目标能收到请求是不同结果。设计中的验证从原始拓扑生成材料，观察实际 WireGuard 对端与路由，再通过代理、DNS 解析和虚拟网络接口（TUN）路径取得独立目标响应，并在停止后检查无关资源仍保留。
这些场景没有承诺通用流量捕获、吞吐指标或所有目的地址隔离。客户端应用自身的 VPN 生命周期、宿主网络策略与外部服务仍有各自前提；具体部署应以相应的运行观察判断完成程度。