V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Gipserr  ›  全部回复第 1 页 / 共 2 页
回复总数  30
1  2  
11 小时 47 分钟前
回复了 Nyarime 创建的主题 OpenWrt 在 iKuai 爱快软路由上原生运行 OpenWrt 软件包
@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.终端用户会在启动后上报一次,然后就不再更新了,可能是启动过程中抢先上报了.
已经很有曙光了,以后再慢慢研究.
过了五六分钟以后又全量终端信息上报到云平台了。看来隔绝的还没搞定。
汇报一下 v70v5 的那个 bin 的使用情况。
yun.ikuai8.com 的后台还能看到路由器在线
但是信息(客户端)上报的情况停留在系统启动 5 秒以内。
1  2  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   3256 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 15ms · UTC 11:57 · PVG 19:57 · LAX 04:57 · JFK 07:57
♥ Do have faith in what you're doing.