@earpiece5631 老板最后给到的就是 75v2 了，这个版本已经足够让 AI 去处理剩下的工作了，主要就是利用 /etc/log/naixi/compat/boot.sh 这个固化的启动脚本，每次启动以后清理掉会自动下载的东西，就是一个干净的 root 环境了，你要跑啥程序都行。

图片/视频推送也是属于 32k 的限制吗？

## 我做了什么

### 1. 修复了 Docker 的持久启动链

这台机器不是普通 Linux 根盘，而是 `RAM root`。很多运行时文件重启后会丢，所以不能把修复写在 `/tmp` 或 `/usr` 的 RAM 层，必须写到持久层。

我把最小修复落在：

```text
/etc/log/naixi/compat/boot.sh
```

作用是：

- 开机时把 `/etc/log` 挂成 Docker 的持久工作盘映射
- 自动补 `/docker` 和 `/usr/sbin/docker`
- 如果系统恢复了原来的 `docker_server`，就走原链路
- 如果重启后只恢复了 `docker-bin`、没恢复 `docker` 脚本包，就直接用 `dockerd` fallback 起引擎

## 2. 清掉了高风险包和自恢复链

已删除并持续阻断的对象包括：

- `pmd`
- `cre`
- `ik_rc_client`
- `ik_host`
- `shell`
- `pre_cdn_stats`
- `ikaudit`
- `monitor_process.sh`

对应的持久包、运行目录、入口文件和 RAM root 自恢复脚本都已经清理，并写进了开机清理逻辑。

## 3. 封死了高风险云拉取 / 外联链

现场最危险的链路是：

```text
update_hosts.sh
-> 从 302.ikuai8.com 获取主机列表
-> submit.lua 拉取 submit3
-> 本地直接执行
```

这条链现在的处理方式是：

- 开机强杀 `update_hosts.sh` / `submit.lua` / `async.lua`
- 删除 `/tmp/iktmp/ik_hosts` 和 `/tmp/iktmp/submit`
- 把 `/usr/ikuai/script/utils/update_hosts.sh` 改写成 no-op
- 把 `/usr/ikuai/script/utils/submit.lua` 改写成空壳

同时保留 `Naixi cloud level 2` 的原有阻断：

- `/etc/hosts` 将一批 `ikuai8.com` 云域名 sinkhole 到 `127.0.0.1`
- `iptables OUTPUT` 对多个 `iKuai` 云 IP 做 `DROP`

## 4. 现场验证结果

本次整改后，我已经做过两次 reboot 后现场复核，确认以下结论成立：

- `Docker` 第二次 reboot 后已能自动起来
- `docker info` 正常
- 高风险的 `update_hosts.sh` / `submit.lua` / `async.lua` 没有复活
- `pmd/cre/ik_rc_client/ik_audit/monitor_process` 相关进程没有复活
- `/tmp/iktmp/ik_hosts` 和 `/tmp/iktmp/submit` 没有复活
- `netstat -anp | grep ESTABLISHED` 现场未看到新的云端已建立连接

@lcy630409 codex “帮我去 [email protected] 看看 /tmp/ikpkg/下面我同事设置的 docker 自动启动的条件是什么，我忘了。”

/tmp/ikpkg 里面的包是 /etc/log/packages 里面开机解压的

@lcy630409 这玩意真像病毒，想尽一切办法给自己保活。禁止写/tmp/ikpkg 不知道行不行。

继续反馈一下：我刚才升级了 v75v2 ，默认登录进去，wg/docker 都是没有的（我原来 iso 全新安装，没有给硬盘分区）。

然后我给硬盘分区，重启以后，发现/tmp/ikpkg 下载了一些软件:

app_show docker docker-bin ik_host netboard nginx_conf pmd pre_cdn_stats shell

ik_host 里面有可以遥测增加的 IP：
cre_host
dis.ikuai8.com:1853
59.110.171.18:1853
47.94.237.123:1853
59.110.171.18:2016
47.94.237.123:2016
pmd_host 里面有：
cat pmd_host
123.57.179.21:1863
123.57.179.21:15602
pkgmanager.ikuai8.com:15602
59.110.6.135:1863
59.110.6.135:1560

shell 里面看来是个云备份工具
下载的 docker 也没有搞清楚怎么运行起来（因为后台是云平台操纵启用的，我没有绑定云平台）

@Nyarime 牛逼，互联网精神与你同在。

@lcy630409 做到小米那种 root 模式我觉得就好了，尽量不要对原来的系统功能覆盖太多，自己用 AI 编程跑几个服务在上面，减少一些外部机器的依赖。我看来 ikuai 原来的缺点就是不能跑高权限的 docker ，不能跑 wireguard 服务器端（付费的可以跑客户端）。我用 ikuai 不用 openwrt 的原意就是 openwrt 的升级/依赖/dns/端口映射/防火墙这些搞得我很不爽。

@lcy630409 你这个 ikuai 有绑定他们云平台吗？

早前装完 compat 以后我的确也没见到 9090 起来。
现在我在干净的系统装了 v73 ，clean 了云平台，阻断了 2 ，挂久一点看看会不会被改啥，谢谢。
另：开机会连接 packages.ikuai8.com ，为什么 hosts 没有加这个域名呢？@Nyarime

@Nyarime 我重新做了一个 3.7.17 的干净系统，不配置 wan ，只配置了 lan ，用 v72v4 更新进入系统,版本号是 3.7.19 ，各项配置都正常，也能重新用 v72v4 的 bin 再次升级，没有报 “无法识别这个文件“ 。 证明 ikuai 肯定做了手脚。

@Nyarime 不确定，我是挂了一晚，回来看到你有更新，更新了以后出现这样的结果。不知道是不是爱快已经提前做了手脚了。因为更新 v72v4 以后我马上刷了爱快云，这个服务器还是显示在线和有客户端的。因为昨天抓包提示启动的时候会访问 packages ikuai com 抓一个 /cre/3/cre_123.3.x86_64.ikp ，它也可以抓其他东西。

测试了一下爱快命令行的重置功能，重置以后的结果是：
1.重置以后要重新设置 web 密码/IP
2.进去以后在 web 内外网还是无法配置
3.ssh 连接要重新启用，要自己设置 sshd 的密码，不能共用 web 的了
4.ssh 上去以后，naixi 的系统和配置还在
5.还是无法上传 bin 更新系统

@Nyarime 爱快牛逼，更新了这个版本，安装 naixi-compact 重启以后，我爱快的配置全丢了。
云绑定被解除，内外网配置的配置页面打不开，一片空白，网卡绑定刷新一下配置页面就变回空白，重启以后也是这样。
然后再上传 bin 提示：错误: 无法识别这个文件。
是不是被爱快遥测干掉了配置。还好是个用来测试的系统。

@lcy630409 可能可以内置一个 dns ，这个是写到 resolv 的 dns 。

手工重启抓包:

按时间顺序

1. 21:48:14
192.168.2.250 先向 223.5.5.5:53 查 packages.ikuai8.com 的 AAAA/A 。
随后连 113.113.100.48:443 ，我从 ClientHello 里弱提取到了 SNI=packages.ikuai8.com 。
2. 21:48:51
再次向 114.114.114.114:53 查 packages.ikuai8.com 。
随后明文访问 113.113.100.48:80 ，这个是这次最硬的证据：
GET /cre/3/cre_123.3.x86_64.ikp HTTP/1.1
Host: packages.ikuai8.com
3. 21:48:52 到 21:48:56
连续多次向 114.114.114.114:53 查 dis.ikuai8.com 。
紧接着发起了 6 次到 47.94.237.123:1853 的短 TCP 会话，都是几百字节到一千多字节的二进制 payload ，时序上很像跟 dis.ikuai8.com 同一条链路。
这一条我判断为“高疑似爱快自家调度/分发链路”，但域名和目标 IP 没法在这份 WAN 侧样本里完全坐实。
4. 21:48:52
查了两次 time6.aliyun.com ，随后向 203.107.6.88:123 发了两次 NTP 请求。
这条更像标准时间同步，不像异常验证。
5. 21:48:58 到 21:49:04
连续多次向 114.114.114.114:53 查 downloads.openwrt.org 。
随后建立了 6 次到 146.75.114.132:443 的 TLS 连接，我从 ClientHello 里弱提取到了 downloads.openwrt.org 。
这条可以认为是爱快主动访问 OpenWrt 下载源。
6. 21:49:01
有 1 次到 123.57.179.21:1863 的短 TCP 二进制会话，payload 约 952 字节。
这条没有直接域名证据，只能标成“未知自定义连接”。
7. 21:49:35
向 114.114.114.114:53 查 www.ip138.com ，随后访问 120.39.215.140:80：
GET / HTTP/1.1
Host: www.ip138.com
User-Agent: Mozilla/5.0 (Linux; iKuaiOS; x86) AppleWebKit/537.36 (KHTML, like Gecko)
8. 21:50:05
同样又来了一次 www.ip138.com 检测，请求内容和 User-Agent 一样。
9. 21:50:13
只有 1 个到 220.202.27.130:443 的单独 RST 包，没有看到这次抓包内对应的建连过程，这条不能拿来下结论。

这次能坐实的主动外发

- packages.ikuai8.com
证据最强，既有 DNS ，也有 TLS SNI ，还有明文 HTTP GET /cre/3/cre_123.3.x86_64.ikp
- downloads.openwrt.org (这个可能是你的 opkg 升级)
有 DNS ，也有 TLS SNI
- www.ip138.com
有 DNS 、明文 Host ，还有明确的 iKuaiOS User-Agent
- time6.aliyun.com -> 203.107.6.88:123
标准时间同步

这次最值得盯的可疑点

- dis.ikuai8.com 查询后，连续打 47.94.237.123:1853
- 123.57.179.21:1863 的单次二进制短连接


(ip138.com 是我测活的 http 设定)

@lcy630409 重启马上去 yun 看是在线的,过一会才离线.

@Nyarime 谢谢.目前最新版本的状况:
1.yun 还是显示这个路由器在线
2.终端用户会在启动后上报一次,然后就不再更新了,可能是启动过程中抢先上报了.
已经很有曙光了,以后再慢慢研究.

过了五六分钟以后又全量终端信息上报到云平台了。看来隔绝的还没搞定。