引言：当「折腾」需要回归工程本质

引言：当「折腾」需要回归工程本质

作为常年泡在 PVE 和 Docker 堆栈里的基础设施控，我曾是 OpenWrt 原教旨主义者——从内核编译到 iptables 规则，享受每一次手搓配置文件的快感。但 production 环境的残酷在于：当家里的网络需要在「可玩性」与「稳定性」之间做权衡，当家人因为你升级内核导致断网而投来质疑的目光，我们不得不承认，软路由的终极形态不是炫技，而是可靠的工程化交付。

iStoreOS 的出现，本质上是对 OpenWrt 生态的一次「工程化封装」。它并非简单的皮肤替换，而是在保留 OpenWrt 底层灵活性的同时，通过预置 iStore 应用商店、优化 Docker 集成、标准化分区管理，将软路由的部署门槛从「编译内核级」降低到「Docker Compose 级」。本文将从架构拆解、虚拟化部署、网络栈配置到容器化实践，完整复盘一次基于 iStoreOS 的软路由重构过程。

一、架构解构：iStoreOS 的工程化改进

1.1 基于 OpenWrt 21.02+ 的内核优化

iStoreOS 并非 fork 一个全新的发行版，而是基于 OpenWrt 21.02（后续版本跟进 22.03/23.05）进行深度定制。其关键改进在于：

  • 分区方案重构：默认采用 Overlay 文件系统，但预留了可扩展的 /overlay 分区逻辑，解决了原生 OpenWrt 在 Docker 重度使用下根目录爆满的痛点。
  • 内核模块预编译：针对 x86/64、ARM64（RK3568/RK3588 等）平台，预置了常用的 kmod-usb-net、kmod-fs-ext4 等模块，避免了因内核版本 mismatch 导致的 opkg 安装失败。

1.2 iStore 应用商店的包管理哲学

不同于原生 OpenWrt 依赖 opkg 命令行，iStoreOS 提供了图形化的应用商店，但其底层仍遵循 OpenWrt 的包依赖逻辑。值得注意的是：

  • 元数据标准化：iStore 中的每个应用都附带 architecture 和 depends 字段，系统会自动检测当前架构（如 x86_64 vs aarch64_cortex-a53）并过滤不兼容包，这比手动浏览 OpenWrt 软件源更防呆。
  • Docker 应用封装：对于 AdGuard Home、Home Assistant、Jellyfin 等现代应用，iStore 并非直接编译为 ipk 包，而是通过封装 Docker Compose 模板实现。这意味着你可以在 Luci 界面一键部署容器，同时保留在命令行 docker exec 调试的灵活性。

二、部署实战：从 PVE 虚拟化到物理机 Bare Metal

2.1 虚拟化方案选型：PVE vs VMware vs Hyper-V

根据实测环境，iStoreOS 在虚拟化层面的兼容性表现如下：

虚拟化平台 镜像格式 网卡直通建议 备注
Proxmox VE qcow2/img VirtIO（半虚拟化） 推荐，支持 PCIe 直通物理网卡
VMware ESXi/vSphere VMDK E1000e 或 VMXNET3 需转换镜像格式，注意固件类型选 UEFI
Microsoft Hyper-V VHD/VHDX 合成网络适配器 需关闭安全启动，建议第二代虚拟机

硬核建议：如果你计划将 iStoreOS 作为主路由，且宿主机具备多网口（如 4x 2.5G 或万兆光口），务必采用 PVE 的 PCIe 直通（PCI Passthrough）将物理网卡直接分配给 iStoreOS 虚拟机，而非使用虚拟网桥。这能显著降低虚拟化层带来的网络延迟（实测可降低 0.3-0.5ms），并避免宿主机内核的软中断瓶颈。

2.2 物理机 Bare Metal 安装：分区陷阱与解决方案

在 N5105/N100 等 x86 小主机或 RK3568 ARM 软路由上直接刷写 iStoreOS 时，最常见的坑是Overlay 分区空间不足：

  • 现象：通过 df -h 查看，发现 /overlay 分区仅有几十 MB 或几百 MB，安装几个 Docker 镜像后即报 no space left on device。
  • 根因：iStoreOS 默认的固件分区表基于最小化设计，未充分利用大容量 eMMC 或 SSD 的剩余空间。
  • 工程化解决方案：
    1. 在线扩容（推荐）：使用 iStoreOS 内置的「系统」-「磁盘管理」-「扩容根分区」功能，该工具实质是调用 parted 和 resize2fs 命令，自动将未分配空间合并到 Overlay 分区。
    2. 离线重建分区：对于极端场景（如需要单独划分 /opt 或 /var/lib/docker），需在刷机前使用 gdisk 手动编辑固件的 img 文件，调整分区表后再写入磁盘。

三、网络栈配置：从 PPPoE 到 VLAN 单线复用

3.1 多拨与 IPv6 前缀委托的底层逻辑

iStoreOS 作为家庭网络的核心网关，其 WAN 口配置需处理国内复杂的宽带环境：

  • PPPoE 多拨：在「网络」-「接口」-「WAN」中，通过创建多个虚拟接口（如 wan1, wan2）并绑定同一物理网卡，利用 macvlan 驱动实现单线多拨。需注意，多拨的负载均衡需配合 mwan3 包使用，并在「策略」中配置基于源 IP 或目的端口的流量分配规则，否则可能出现流量仅走单条链路的「假多拨」现象。
  • IPv6 PD（Prefix Delegation）：国内运营商通常下发 /60 或 /56 的 IPv6 前缀。iStoreOS 需在 WAN6 接口的「高级设置」中勾选「请求 IPv6 前缀」，并在 LAN 口的「IPv6 设置」中选择「中继模式」或「服务器模式（SLAAC）」。坑点在于：若内网设备无法获取 IPv6 地址，通常是因为 iStoreOS 的防火墙「区域转发」规则未允许 LAN 到 WAN 的 IPv6 转发，需在「通信规则」中显式放行。

3.2 VLAN 单线复用：IT 宅男的终极网络拓扑

对于弱电箱到客厅仅有一根网线的户型，或需要将 IPTV、宽带上网、管理网络物理隔离的场景，iStoreOS 的 VLAN 配置能力至关重要：

典型场景：光猫桥接模式，iStoreOS 主路由位于客厅，需同时承载：

  • VLAN 10：PPPoE 上网（untagged 或 tagged）
  • VLAN 20：IPTV 组播（供机顶盒使用）
  • VLAN 30：管理网络（用于访问弱电箱的交换机）

配置步骤：

  1. 物理接口绑定：在「网络」-「接口」-「设备」中，找到 WAN 口对应的物理网卡（如 eth0），点击「配置」，启用 VLAN 过滤（802.1q）。
  2. 创建 VLAN 接口：为每个 VLAN 创建虚拟接口，如 eth0.10（PPPoE）、eth0.20（IPTV）。在「桥接设备」设置中，确保 VLAN ID 与光猫或上级交换机的配置严格一致。
  3. IPTV 组播代理：若 IPTV 需跨 VLAN 播放，需在 iStoreOS 安装 igmpproxy 或 omcproxy，并在防火墙设置中放行 UDP 1900 端口（SSDP）及组播地址段（通常是 224.0.0.0/4）。

避坑指南：部分用户的 IPTV 机顶盒会检测 VLAN 标签，若 iStoreOS 的 LAN 口直接连接机顶盒，需将该端口配置为「Untagged」模式，并在「交换机」设置中指定 PVID（Port VLAN ID），否则机顶盒可能因无法识别 802.1q 标签而无法获取 IP。

四、容器化实践：Docker 在软路由上的正确打开方式

4.1 iStoreOS 的 Docker 架构解析

iStoreOS 并非简单地将 Docker CE 移植到 OpenWrt，而是针对嵌入式环境的资源限制做了特定优化：

  • 存储驱动：默认使用 overlay2（需内核支持 CONFIG_OVERLAY_FS），而非性能较差的 vfs。若你的 iStoreOS 运行在 SD 卡或低速 eMMC 上，建议在「Docker」-「配置」中调整「数据根目录」至外接 USB 3.0 固态硬盘，避免闪存磨损。
  • 网络模式：iStoreOS 的 Docker 默认使用 bridge 模式，但创建了名为 docker0 的网桥与 LAN 口隔离。若容器需要被局域网直接访问（如 Home Assistant 的 mDNS 发现），需在容器创建时指定 --network host，或在「端口映射」中将宿主机的 LAN IP 绑定至容器端口（如 -p 192.168.1.1:8123:8123）。

4.2 高阶场景：AdGuard Home 与 PassWall 的共存架构

在 iStoreOS 上同时运行「去广告（AdGuard Home）」与「科学上网（PassWall/Surge）」是高频需求，但两者都涉及 DNS 劫持，极易产生冲突：

工程化部署方案：

  1. DNS 分层解析架构：

    • 第一层（AdGuard Home）：监听默认 DNS 端口 53，负责局域网设备的 DNS 查询、广告过滤、缓存加速。上游 DNS 设置为 iStoreOS 本地的 PassWall 监听端口（如 7913）。
    • 第二层（PassWall）：监听 7913 端口，负责分流国内/国外流量。对于国内域名，直接返回本地 DNS 结果；对于国外域名，通过代理隧道（如 Xray/V2Ray）转发至远程 DNS（如 8.8.8.8）。

  2. IP 路由分流：

    • 在 iStoreOS 的「网络」-「防火墙」-「自定义规则」中，确保 PassWall 的 iptables 规则优先级高于 AdGuard Home，避免去广告规则将代理 IP 误判为广告域名并拦截。

  3. 容器化部署细节：

    • AdGuard Home 建议通过 iStore 商店一键安装（实质是拉取 adguard/adguardhome 镜像），其工作目录映射至 /mnt/sata1-1/AdGuardHome（外置存储），防止容器重启后规则丢失。
    • 在 AdGuard Home 的「设置」-「DNS 设置」中，关闭「使用 127.0.0.1 作为上游 DNS」（避免回环），显式指定 PassWall 的本地端口。

避坑实录：若发现开启 AdGuard Home 后 PassWall 无法代理，99% 是因为 DNS 解析被 AdGuard 缓存了国内 CDN 结果，导致流量未进入代理隧道。此时需在 AdGuard Home 的「过滤器」-「DNS 重写」中，将代理域名（如 google.com）强制解析为伪造 IP（如 198.18.0.1），触发 PassWall 的域名规则匹配。

结语：软路由的终极形态是「透明的基础设施」

iStoreOS 的价值不在于它提供了多少一键安装按钮，而在于它在 OpenWrt 的灵活性与商业路由器的易用性之间找到了工程化的平衡点。通过标准化的分区管理、开箱即用的 Docker 支持、以及深度优化的 VLAN 与 IPv6 协议栈，它让我们得以将更多精力从「调试配置文件」转移到「设计网络架构」上。

当然，iStoreOS 并非银弹。对于追求极致内核定制（如自定义 netfilter 模块）或依赖特定硬件 offload（如 Intel QuickAssist）的场景，原生 OpenWrt 或 Debian 系路由系统（如 RouterOS、pfSense）仍是更优解。但在 90% 的家庭及小型工作室场景中，iStoreOS 已经证明了其作为「透明基础设施」的可靠性。

你在使用 iStoreOS 时遇到过哪些棘手的网络架构问题？或者在 Docker 化部署过程中发现了哪些性能瓶颈？欢迎在评论区分享你的踩坑实录与调优方案。 毕竟，软路由的乐趣从来不在于「不折腾」，而在于「有章法地折腾」。

Licensed under CC BY-NC-SA 4.0