docs: 调整NapCat设备身份迁移策略
This commit is contained in:
parent
04032cfdb0
commit
93233c44c9
@ -35,9 +35,9 @@
|
||||
2. 最小化登录事件：watchdog 恢复必须优先稳定 quick -> password，避免频繁 `docker rm -f`、重建容器、生成二维码和反复扫码。
|
||||
3. 建立 `NapCat Protocol Risk Profile`：把 NapCat/OneBot 配置、`o3HookMode` 灰度、版本 pin、IP/代理证据和自动行为降噪纳入统一 profile。
|
||||
4. 建立 `NapCat Linux Runtime Profile`：让托管 NapCat 容器在可控范围内更接近普通 Linux 桌面程序运行环境，但只作为运行卫生和漂移可观测项。
|
||||
5. 保持现有账号设备身份稳定，避免无意迁移 hostname/MAC/machine-id 触发额外新设备验证。
|
||||
5. 对现有已风控账号执行受控设备身份迁移，改为真实设备风格 hostname/MAC/machine-id 组合，并保留迁移前后证据。
|
||||
6. 提供线上自检证据：容器运行态、NapCat 配置、OneBot 配置、协议风险状态、会话行为状态都能被 API 查询或记录。
|
||||
7. 先以测试账号灰度闭环，再决定是否迁移现有账号的 hostname/MAC。
|
||||
7. 先以测试账号验证策略，再按账号批次直接迁移现有风控账号的 hostname/MAC。
|
||||
|
||||
## 非目标
|
||||
|
||||
@ -84,7 +84,7 @@ profile 分为四层：
|
||||
|
||||
1. **会话/行为画像**：处理零客户端行为、永久死在线、冷启动后立即高频响应、自动回复长期无节律的问题。
|
||||
2. **登录事件最小化**：减少 `docker rm -f`、重建、扫码、验证码、新设备验证这些登录侧风控事件。
|
||||
3. **官方建议的协议杠杆**：测试账号优先灰度 `o3HookMode=0`，同时记录 IP/代理/出口证据；换号/换设备只作为人工确认的高成本手段。
|
||||
3. **官方建议的协议杠杆**：测试账号优先灰度 `o3HookMode=0`，同时记录 IP/代理/出口证据；现有已风控账号按批次迁移设备身份。
|
||||
4. **环境/runtime 卫生**：image pin、版本 drift、shm、locale、XDG、非 root、持久目录，用于降低噪声和提高可观测性，但不承诺解决服务端会话注销。
|
||||
|
||||
Docker/Linux runtime profile 的验收标准不是“看起来更像真人机器”，而是“不引入新的登录事件、不破坏现有 entrypoint 反检测、不制造 profile drift，并提供诊断证据”。
|
||||
@ -162,23 +162,24 @@ $DATA_DIR/
|
||||
|
||||
### 新账号默认策略
|
||||
|
||||
新账号使用更接近普通 Linux/VM 的稳定身份：
|
||||
新账号使用更接近普通物理设备的稳定身份：
|
||||
|
||||
- hostname：例如 `ubuntu-pc-<stableHash>` 或 `linux-pc-<stableHash>`，不包含 QQ 号、bot、napcat、docker 等词。
|
||||
- MAC：不再默认把 `52:54:00` 作为“更真人”的目标。`52:54:00` 是 QEMU/KVM 风格前缀，只能表达 VM profile，不能证明比 Docker `02:42` 更低风险。新账号 MAC 策略必须作为可观测灰度项：保持当前稳定 MAC、稳定本地管理地址、VM 风格前缀三者择一，且记录登录结果。
|
||||
- MAC：使用真实物理设备风格的稳定 OUI 前缀策略，不使用 Docker 默认 `02:42`，也不使用 QEMU/KVM `52:54:00`、VMware、Hyper-V 等常见虚拟化前缀。实现时维护受控 OUI catalog，优先选择常见物理网卡、主板、笔记本无线网卡厂商风格的前缀，并记录所选策略、生成种子和迁移结果。
|
||||
- machine-id：继续稳定生成 32 位十六进制值并只读挂载。
|
||||
|
||||
### 现有账号迁移策略
|
||||
|
||||
现有 4 个账号已经有线上可用设备身份，本轮默认不迁移 hostname/MAC。
|
||||
用户已确认现有账号已经全部进入风控状态，本轮不再保守保留旧 Docker 风格 hostname/MAC。现有账号直接进入受控设备身份迁移：迁移目标是稳定、可审计、真实设备风格的 hostname/MAC/machine-id 组合。
|
||||
|
||||
如果要迁移，必须走单账号灰度：
|
||||
迁移按账号批次执行，不做无证据的全量并发重建：
|
||||
|
||||
1. 记录迁移前 hostname/MAC/machine-id/登录状态。
|
||||
2. 重建容器写入新 hostname/MAC。
|
||||
3. 观察是否触发新设备验证。
|
||||
4. 完成登录后记录新的 device evidence。
|
||||
5. 至少观察一个业务窗口后再推广。
|
||||
2. 生成真实设备风格 hostname/MAC/machine-id，明确避开 Docker/QEMU/KVM/VMware/Hyper-V 前缀。
|
||||
3. 按登录事件最小化规则重建目标容器，避免重复 `docker rm -f`。
|
||||
4. 允许触发新设备验证；触发后按现有新设备链路完成，不把它视为失败。
|
||||
5. 完成登录后记录新的 device evidence、登录事件和风控状态。
|
||||
6. 若单账号迁移后出现不可恢复登录失败，按迁移前 evidence 回滚该账号，不阻塞其他账号的人工判断。
|
||||
|
||||
## 会话行为 Profile
|
||||
|
||||
@ -337,7 +338,7 @@ NapCat 安全页给出的方向是换账号/设备、调整 IP/代理、必要
|
||||
|
||||
1. **`o3HookMode=0` 测试账号灰度**：低成本、可回滚，优先于大规模 Docker 环境拟真推广。
|
||||
2. **IP/代理/出口证据**：记录 QQ 相关连接的出口、地域、代理策略和变化窗口；只做证据与显式配置，不在本轮自动切换全局网络。
|
||||
3. **设备身份迁移**：成本最高，可能直接触发新设备验证；只允许单账号人工灰度，不默认迁移现有账号。
|
||||
3. **设备身份迁移**：现有账号已确认全部风控，因此直接纳入批次迁移；迁移仍按账号串行或小批次执行，保留回滚证据，避免并发制造登录事件。
|
||||
4. **换号**：属于业务/账号策略，不作为自动化修复手段。
|
||||
|
||||
实现时不能把 `o3HookMode=0` 的失败或成功归因给环境拟真；必须在同一账号、同一 image digest、同一 device identity 下对比。
|
||||
@ -614,7 +615,8 @@ Admin 第一阶段只需要只读展示：
|
||||
|
||||
- Docker create script 包含 `--init`、`--shm-size`、非 root UID/GID、locale/XDG env、cache/local-share/logs 挂载。
|
||||
- 新账号 hostname/MAC 策略不包含 QQ 号、bot、napcat、docker 等词。
|
||||
- 现有账号默认不迁移 hostname/MAC。
|
||||
- MAC 策略使用真实物理设备风格 OUI catalog，明确排除 Docker `02:42`、QEMU/KVM `52:54:00`、VMware、Hyper-V 等虚拟化前缀。
|
||||
- 现有已风控账号进入受控设备身份迁移，测试覆盖迁移前 evidence、迁移后 evidence、新设备验证链路和单账号回滚。
|
||||
- NapCat config writer 同时生成默认文件与账号级文件。
|
||||
- `o3HookMode=0` 只能通过账号级灰度配置启用。
|
||||
- OneBot config 保持反向 WS 最小配置。
|
||||
@ -626,7 +628,7 @@ Admin 第一阶段只需要只读展示：
|
||||
- watchdog 测试明确断言普通离线、OneBot WS close、密码失败重试不会触发重复 `docker rm -f`、重复生成二维码或重复扫码 session。
|
||||
- 容器重建测试明确区分人工更新登录、首次创建、profile 迁移、密码环境清理 rebuild 和 watchdog 自动恢复。
|
||||
- 非 root 测试必须验证 entrypoint 原有容器隐藏行为仍存在；若不存在，该 runtime profile 不允许通过。
|
||||
- MAC 策略测试明确断言 `52:54:00` 不是默认“真人物理机”策略，只能作为显式 VM profile 灰度。
|
||||
- MAC 策略测试明确断言不得使用 QEMU/KVM `52:54:00` 或其他常见虚拟化前缀作为目标设备风格。
|
||||
- locale 测试明确标注 `C.UTF-8` 只是编码卫生项，不能作为完整环境拟真通过条件。
|
||||
|
||||
### 线上灰度
|
||||
@ -637,9 +639,10 @@ Admin 第一阶段只需要只读展示：
|
||||
4. 启用 session behavior profile，观察 housekeeping/presence evidence，确认不会产生消息刷量。
|
||||
5. 对测试账号灰度 `o3HookMode=0`，记录 NapCat/QQNT 版本、收发结果和掉线情况。
|
||||
6. 记录 IP/代理/出口证据，确认 QQ 相关连接变化窗口。
|
||||
7. 再启用 Linux Runtime Profile 卫生项，自检 Docker inspect 与容器内 runtime evidence，重点验证非 root 不破坏 entrypoint 隐藏能力。
|
||||
8. 执行手动命令、图片命令、自动回复、复读机 smoke。
|
||||
9. 观察至少一个业务窗口，再决定是否推广。
|
||||
7. 对测试账号验证真实设备风格 OUI、hostname、machine-id 生成和新设备验证链路。
|
||||
8. 再启用 Linux Runtime Profile 卫生项，自检 Docker inspect 与容器内 runtime evidence，重点验证非 root 不破坏 entrypoint 隐藏能力。
|
||||
9. 执行手动命令、图片命令、自动回复、复读机 smoke。
|
||||
10. 按账号批次迁移现有风控账号，并逐账号记录迁移 evidence、登录事件和收发结果。
|
||||
|
||||
## 上线顺序
|
||||
|
||||
@ -647,9 +650,10 @@ Admin 第一阶段只需要只读展示：
|
||||
2. 落登录事件记录、恢复租约、watchdog quick -> password 稳定恢复和自动恢复熔断。
|
||||
3. 落 session behavior profile：冷启动窗口、housekeeping、presence capability detection、自动能力逐步恢复。
|
||||
4. 测试账号灰度 `o3HookMode=0`，同步记录 IP/代理/出口证据。
|
||||
5. 最后对测试账号启用 Linux Runtime Profile 卫生项，先验证非 root、MAC、locale 不带来负向效果。
|
||||
6. 验证登录、收发和行为 evidence 闭环。
|
||||
7. 观察稳定后再讨论现有账号 hostname/MAC 迁移。
|
||||
5. 对测试账号验证真实设备风格 hostname/MAC/machine-id 和新设备验证链路。
|
||||
6. 对现有已风控账号执行受控设备身份批次迁移，逐账号记录和回滚。
|
||||
7. 最后启用其他 Linux Runtime Profile 卫生项，先验证非 root、locale 不带来负向效果。
|
||||
8. 验证登录、收发和行为 evidence 闭环。
|
||||
|
||||
## 参考来源
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user