[Feature] 增加 TUN 服务安装模式，避免 GUI 以管理员权限常驻

[Firefly0619sec]

背景

目前使用 TUN 模式时，v2rayN 需要以管理员权限运行整个 GUI。这带来两个问题：

1. 攻击面放大：主程序（以及它加载的配置、订阅、解析逻辑）长期处于高权限上下文，任何一处被利用都直接是管理员权限；
2. 使用成本：每次启动都要过 UAC，用户容易习惯性点“是”。

建议：TUN 服务安装模式（可选）

参考服务化方案，把“需要特权的动作”收进一个独立服务，GUI 保持普通用户：

• 安装一个最小权限的本地服务（专用账户，或仅在创建 TUN 时使用 LocalSystem 能力），只负责：
  • 创建/销毁 TUN 设备；
  • 添加/删除对应路由；
  • 查询状态。
• GUI 以普通用户运行，通过受限 IPC（命名管道）请求“开/关 TUN”；
• 服务端只暴露最小接口（start / stop / status），不接受任意命令或任意路径；
• IPC 必须做调用方鉴权：命名管道 ACL 限定当前用户、校验客户端签名/进程路径，拒绝其他用户；
• 服务与 GUI 的二进制都应签名，安装/卸载走标准服务安装流程。

期望效果

• 免管理员启动 GUI；
• GUI 或渲染/解析层被利用时，拿不到管理员权限；
• UAC 只在“安装服务”时出现一次，而不是每次启动。

需要注意

• IPC 鉴权是重点：如果服务端不校验调用方，只是把攻击面从 GUI 转移到了服务，甚至更糟；
• 服务本身要最小化：不解析用户配置、不访问网络，只做 TUN/路由操作；
• 保留现有“管理员直接跑 TUN”的方式作为兼容选项，服务模式作为可选增强；
• 安装/卸载、服务异常退出后的清理（残留 TUN 设备/路由）要有明确处理。

参考

Clash Verge 的服务模式（clash-verge-service）是同类思路：GUI 普通权限运行，特权操作交给服务。

[Caesar-Victory]

这是一个很好的建议，不过优先级可能不高。我在安装 MySQL 的时候就发现，它在服务里面注册了一个服务，服务使用的是一个单独的账号，这样就把权限给隔离开了。但是不知道Linux下是怎么去实现的，可能要单独创建一个用户。

[Caesar-Victory]

连ChatGPT都不需要开启全局代理了，因此tun模式这几个月几乎都没用过。

[Firefly0619sec]

感谢回复，理解优先级。补充两点实现细节，供以后排期时参考。

1. Windows 下不需要新建本地用户

SCM 支持虚拟服务账户：注册服务时把账户写成 NT SERVICE\v2rayNTun（名称随服务名），系统会自动创建、无密码、无需管理本地用户。也可以直接用 LocalSystem，但更推荐前者或 LocalService——前提是把“需要特权的动作”压到最小。

关键是：TUN 设备创建/路由修改本身需要管理员能力，所以服务账户不可能真正“低权”；能做的是：

• 服务只做 TUN/路由，不解析配置、不联网、不读用户目录；
• GUI 以普通用户运行，通过命名管道请求 start/stop/status；
• 管道 ACL 限定当前用户 + 校验调用方进程签名/路径。

这样高权限只存在于一个小服务里，而不是整个 GUI。

2. Linux 侧也不用 root 全权

systemd 可以用：

[Service]
DynamicUser=yes
AmbientCapabilities=CAP_NET_ADMIN

或专用用户 + CAP_NET_ADMIN，不需要 User=root。这和 Windows 的“最小服务”是同一个思路。

3. 关于“TUN 用得少”

理解，功能优先级可以低。但服务模式解决的不只是 TUN 便利性：

• 现在 TUN 需要管理员 ⇒ 整个 GUI 以管理员常驻 ⇒ 任何 GUI 侧问题都直接是管理员权限（评分上就是 S:C）；
• 服务模式把 GUI 降回普通用户，等于把“应用漏洞”和“系统权限”隔开。

即使短期不做，建议先做一个低成本缓解：

• 启动时检测是否以管理员运行，非 TUN 场景提示“无需管理员”；
• TUN 启动失败时明确提示“需要管理员/服务模式”，而不是静默失败。

如果以后排期，我可以按上面的最小接口写一版设计草案（服务端接口、IPC 鉴权、安装/卸载流程）。

[2dust]

此问题讨论过多次了，我们目前的方式已经是从安全性和便利性的妥协方案了。

[2dust]

我们技术水平一般，无法把控服务模式产生的安全漏洞。
且本 应用一直是已便携为目标，安装方式不是我们想要的。

[Firefly0619sec]

理解，也尊重“便携 + 不引入难以把控的服务”这个取舍。下面不是要求改架构，只是把三件事说清楚，供以后参考。

1. 严重程度：不是“TUN 好不好用”，而是“GUI 是否整体提权”

现在 TUN 需要管理员 ⇒ 整个 GUI 以管理员运行 ⇒ GUI、渲染层、配置解析、订阅处理，任意一处被利用，拿到的都是管理员权限。

这在评分上是影响域的变化（S:C：影响越出应用、落到操作系统）。TUN 是一个功能，管理员常驻是一个攻击面——两者不在同一个权衡层级。

2. 服务模式其实更方便（但不回避便携冲突）

• UAC 只在安装/启用时一次，之后启动 GUI 不再提权；
• TUN 崩溃/重启时，不需要用管理员权限重新拉起整个 GUI；
• 更新 GUI 本身不需要管理员；
• 日常使用时，即使 GUI 被利用，也拿不到系统权限。

但“便携”确实是冲突点：注册服务要写系统、要安装，这与“绿色便携”的定位不一致。

3. 如果不想做服务，有一个“便携友好”的替代：按需 helper

不是常驻服务，而是按需启动的特权 helper 进程：

• GUI 以普通用户运行；
• 用户开启 TUN 时，GUI 启动一个高权限 helper（UAC 一次）；
• helper 只做创建 TUN 设备、增删路由，TUN 关闭或 GUI 退出就结束；
• 不注册服务、不写系统目录、不常驻，符合便携；
• GUI 与 helper 用命名管道通信，接口只有 start / stop / status，并校验调用方（管道 ACL + 进程签名/路径）。

这仍然比“整个 GUI 管理员常驻”的攻击面小得多，也不需要维护一个常驻服务；代价只是每次开 TUN 时一次 UAC。

4. 最低成本：不做 helper，也建议做提示

• 启动时检测是否以管理员运行，非 TUN 场景提示“无需管理员”；
• TUN 启动失败时提示“需要管理员”，而不是静默失败；
• 文档里标注“TUN 需管理员”的风险，以及服务/helper 是后续方向。

5. 如果这些都不做

希望至少记录为“已知风险、维护者接受”。

我们会在审计报告里如实写：该风险已被提出，维护者基于便携性与服务复杂度的取舍选择接受——不夸大，也不隐瞒。