树莓派5使用KVM虚拟机安装iStoreOS：单网口旁路由与Nikki透明代理配置

前面已经在树莓派5的 Debian 13 宿主机上，通过 KVM/QEMU/libvirt 跑起了 Home Assistant OS。

这次继续折腾，把 iStoreOS 也装进 KVM 虚拟机，做成一个单网口旁路由。

最终效果是：

主路由继续负责 DHCP，默认不会让全家设备自动经过旁路由。

只有手动把设备的网关和 DNS 改成：

这台设备才会经过 iStoreOS 和 Nikki 透明代理。

这种方式对现有网络改动最小，即使旁路由停机，其他没有手动改网关的设备也不受影响。

下面记录完整安装和排障过程。

1. 网络结构

iStoreOS 采用单网口旁路由结构：

2. 环境说明

基础旁路由使用 1GB 内存已经够用。安装多个代理、Docker 或其他大型插件时，可以再增加到 2GB。

3. 先创建隔离网络

iStoreOS 首次启动时，不能确定它是否会向局域网发送 DHCP，所以先接入 libvirt 的 default 隔离网络。

我这里原本是：

启动并设置自动启动：

确认：

正常类似：

在还没有虚拟机接入时，virbr0 显示 DOWN 是正常的。

4. 准备iStoreOS磁盘镜像

从 iStoreOS 官方固件目录下载 ARM64 通用 EFI 镜像，文件类型选择：

下载后保存为：

检查文件：

我这里出现：

但镜像可以完整解压，后续 qemu-img 检查也正常，因此没有影响使用。

创建镜像目录：

解压为 RAW 镜像：

转换为 QCOW2：

扩容到 8GB：

设置权限：

检查：

正常应包含：

转换成功后删除 RAW 文件：

5. 复用HAOS已经验证过的UEFI

我这里是：

6. 创建iStoreOS虚拟机

新版 virt-install 会强制要求 --osinfo。iStoreOS 没有专属条目，使用通用的：

创建成功后检查：

我这里的虚拟网卡 MAC 是：

7. 在隔离网络中完成首次配置

进入串口控制台：

按几次回车进入 Shell。退出控制台使用：

检查网络：

这个镜像默认配置已经比较适合旁路由：

也就是说，IPv4 地址会自动获取，而且默认没有开启 LAN DHCP。

为了保险，再明确忽略 DHCP 服务：

暂时关闭 LAN IPv6 客户端：

最终关键配置：

然后关机：

8. 把虚拟网卡切换到家庭局域网

确认虚拟机关机后：

编辑虚拟机：

找到：

只把：

改成：

MAC 地址不要改变。

启动并设置开机启动：

9. 获取家庭局域网地址

进入控制台：

检查：

我这里自动获得：

测试网络：

三项都成功，说明 VirtIO 网卡、DHCP、默认路由和 DNS 均正常。

随后在主路由中做 DHCP 静态租约：

10. 配置单网口旁路由NAT

检查防火墙：

默认已经有：

因为单网口旁路由的流量从 br-lan 进入，又从同一个 br-lan 发给主路由，所以需要在 LAN 区域开启 NAT：

检查：

正常应看到：

10.1 清理fw4警告

我这里重启防火墙时出现：

这是旧式 fw3/iptables 配置项，fw4 会忽略它。

只删除无效字段：

删除后警告消失，Docker 的实际 NAT 规则仍然保留。

11. 禁用ICMP Redirect

客户端与主路由、旁路由都在同一网段，Linux 可能向客户端发送 ICMP Redirect，让客户端绕过 iStoreOS 直接访问主路由。

创建持久配置：

立即应用：

检查：

正常：

12. 检查iStoreOS DNS

这个镜像没有预装 ss，可以使用 BusyBox 的 netstat：

我这里看到：

说明 dnsmasq 已经监听家庭局域网地址。

Debian 宿主机安装 DNS 测试工具：

测试 UDP 和 TCP DNS：

返回地址并显示：

13. 用Windows验证旁路由链路

先只选择一台 Windows 电脑测试。

保存后执行：

我这里 tracert 的前两跳是：

说明链路已经变成：

Windows 的 IPv6 需要暂时关闭，否则系统可能继续使用主路由通过 IPv6 下发的 DNS，造成 DNS 绕过 iStoreOS。

14. 安装Nikki透明代理

先更新软件源：

安装依赖：

注意，iStoreOS 这版 opkg 不支持：

会提示：

添加 Nikki 软件源：

刷新并安装：

重启 LuCI：

15. 添加订阅

进入：

填写：

订阅名称要手动输入。灰色的 default 可能只是占位符，如果没有真正输入，日志会显示：

正常应该显示：

订阅链接属于敏感凭据，不要截图或公开。

16. Nikki代理配置

在“代理配置”中：

这里的入站接口必须选择：

不是 br-lan。

lan 是 OpenWrt 逻辑网络接口，底层设备才是：

16.1 只代理一台设备

测试阶段在访问控制中添加：

这样只有 Windows 测试机进入 Nikki。

16.2 手动改网关的设备全部可代理

最终我没有让主路由统一下发旁路由网关，而是继续采用手动方式。

在 Nikki 中删除只匹配 192.168.110.209 的限制，改成“全部”模式；如果界面是逐条规则，就添加一条匹配字段全部留空、只开启 DNS 和代理的规则。

这样所有到达 iStoreOS 的局域网流量都可以进入 Nikki。

但设备是否真正经过 iStoreOS，仍由设备自己的网关决定：

这种方式不用修改主路由 DHCP，控制最灵活。

17. 首次启动卡在GeoIP和GeoSite下载

Nikki 的配置检查已经通过，但首次启动一直卡住：

最后报：

原因是 iStoreOS 无法直连 GitHub 下载 GeoIP 数据。

17.1 手动下载geoip.metadb

检查：

复制到 Nikki 工作目录：

17.2 手动下载GeoSite.dat

复制并保持日志要求的大小写：

目录中至少应包含：

18. 手动测试Mihomo配置

iStoreOS 没有预装 timeout，所以不要使用：

否则返回码 127 只表示找不到 timeout。

直接执行：

看到：

不代表卡死，首次载入规则需要等待一段时间，不要立即按 Ctrl+C。

正常最后应为：

如果 Nikki 已经在运行，再手动使用同一个运行目录测试，可能看到：

这通常是运行中的核心和手动测试同时访问缓存文件。此时先检查进程，不要重复测试。

19. 检查Nikki是否成功运行

不要只依赖可能卡住的：

可以直接检查：

成功后会看到：

核心日志可以查看：

20. 节点返回429和503

透明代理已经成功后，日志中出现：

例如：

这反而证明：

真正的问题是当前代理节点被限流、过载或服务异常。

进入 Nikki 面板，对节点测速，手动切换到一个延迟正常的具体节点，不要继续使用返回 429/503 的节点。

如果全部节点都失败，就需要更新订阅、等待服务商恢复或更换线路，而不是重装旁路由。

21. 最终使用方式

主路由继续保持原样：

需要经过旁路由的设备手动设置：

不需要经过旁路由的设备继续保持 DHCP 自动配置。

建议始终直连主路由的基础设施：

尤其是 Debian 宿主机不要依赖运行在自己上面的 iStoreOS VM 作为默认网关，避免形成启动依赖。

HAOS 后续可以手动改成：

这样安装应用和拉取 Docker 镜像速度就快了。

22. 常用管理命令

查看虚拟机：

进入控制台：

启动、关闭和开机启动：

检查路由：

检查防火墙：

检查 Nikki：

检查 DNS：

23. 总结

至此，树莓派5上的虚拟化结构变成：

最终网络策略：

这种方式不需要修改主路由的全局 DHCP，不会一次性影响所有设备。

即使 iStoreOS 虚拟机停机，Debian 宿主机和其他未改网关的设备仍能正常使用主路由。

记录一下，给同样在树莓派5上使用 Debian、KVM、HAOS 和 iStoreOS 的朋友做个参考~