背景

这是我个人自用的小服务器，基于openSUSE Tumbleweed Slowroll 构建，希望用 Docker 启动一个 OpenWrt 容器作为旁路由，提供代理、去广告等附加功能。常规做法是使用 macvlan 网络驱动让容器获得独立的局域网 IP，但默认情况下 Docker 的 macvlan 会阻断宿主机与容器之间的直接通信（这是 macvlan 的设计特性）。此外，NetworkManager 等网络管理工具可能会干扰手动配置的虚拟接口，导致重启后配置丢失。

本文记录了一套稳定、可持久化的解决方案：通过创建 macvlan 代理接口 + systemd 服务，让宿主机能够与 OpenWrt 容器互通，并保证重启后自动重建。（下图为部署环境，作为参考）

0. 为什么我的 Docker OpenWrt 能用旧版镜像？

先理解 Docker 的一个核心特点：所有容器共享宿主机的内核。我的宿主机是 openSUSE Slowroll，内核版本 6.19.11。因此，无论我拉取的是基于 OpenWrt 18.06 还是 24.10 的镜像，容器内部实际运行的都是 6.19.11 这个内核。

也就是说，即便你看到 sulinggg/openwrt:x86_64 对应 OpenWrt 18.06（内核 4.x），它照样能在我 6.19 的内核上跑起来。但为什么我最终选了 zzsrv/openwrt:latest？

因为后者基于 OpenWrt 24.10-SNAPSHOT，用户态工具链、LuCI 插件和软件源更新，对现代配置文件兼容性更好。而 18.06 的某些 LuCI 组件（比如 frpc 的配置界面）与新版本二进制不兼容，容易出问题。

注：zzsrv/openwrt:latest 和 sulinggg/openwrt:x86_64 本质都是 ImmortalWrt，与 OpenWrt 同源，只是维护方和更新策略不同。

1. 环境与目标

• 宿主机 OS：openSUSE Slowroll

• 物理网卡：enp1s0，局域网段 192.168.3.0/24

• 宿主机 IP：192.168.3.16（静态）

• 目标：Docker 启动 OpenWrt 容器，分配独立 IP 192.168.3.20 作为旁路由

附加需求：宿主机本身也要能访问容器（用于部署 frpc、代理等）

2. 拉取镜像并创建 macvlan 网络

docker pull zzsrv/openwrt:latest

docker network create -d macvlan \
  --subnet=192.168.3.0/24 \
  --gateway=192.168.3.1 \
  -o parent=enp1s0 \
  openwrt_net

3. 启动 OpenWrt 容器

docker run -d \
  --name openwrt \
  --network openwrt_net \
  --ip 192.168.3.20 \
  --privileged \
  --restart unless-stopped \
  zzsrv/openwrt:latest /sbin/init

部署阶段性完成

此时容器已获得独立 IP。如果你的需求仅仅是让手机、电脑等其他局域网设备能够访问 OpenWrt 的 LuCI 或代理服务，那么到这里就已经完成了，无需继续往下看。

但是，如果你希望宿主机本身（192.168.3.16）也能与容器通信（例如在宿主机上运行 frpc 将容器的服务暴露到公网，或者在宿主机上直接使用容器的网关做代理），那么 macvlan 的默认限制就会带来麻烦：Docker 的 macvlan 驱动为了安全，禁止宿主机通过其虚拟接口与容器进行二层通信。

继续往下看，我们将解决这个问题。

4. 解决宿主机 ↔ 容器通信问题

4.1 原理

创建一个同样使用 macvlan 模式的虚拟接口（称为“代理接口”），绑定到物理网卡，给它分配一个额外的局域网 IP（如 192.168.3.100），然后添加一条路由，让发往容器 .20 的流量走这个代理接口。

4.2 临时测试（手动）

ip link add macvlan0 link enp1s0 type macvlan mode bridge
ip addr add 192.168.3.100/24 dev macvlan0
ip link set macvlan0 up
ip route add 192.168.3.20 dev macvlan0

执行后 ping 192.168.3.20 应该能通。但重启后会丢失，需要持久化。

4.3 持久化：使用 systemd 服务（通用方案）

openSUSE 默认的网络管理工具是 wicked，但我的系统并没有安装它；rc.local 也不存在。因此采用最通用的 systemd 服务 方法。

创建脚本：

cat > /usr/local/bin/macvlan-setup.sh << 'EOF'
#!/bin/bash
PROXY_IFACE="macvlan0"
PHYS_IFACE="enp1s0"
PROXY_IP="192.168.3.100/24"
CONTAINER_IP="192.168.3.20"

if ! ip link show $PROXY_IFACE &> /dev/null; then
    ip link add $PROXY_IFACE link $PHYS_IFACE type macvlan mode bridge
    ip addr add $PROXY_IP dev $PROXY_IFACE
    ip link set $PROXY_IFACE up
fi
ip route add $CONTAINER_IP dev $PROXY_IFACE 2>/dev/null || true
EOF

cat > /usr/local/bin/macvlan-teardown.sh << 'EOF'
#!/bin/bash
PROXY_IFACE="macvlan0"
CONTAINER_IP="192.168.3.20"
ip route del $CONTAINER_IP dev $PROXY_IFACE 2>/dev/null
ip link delete $PROXY_IFACE 2>/dev/null
EOF

chmod +x /usr/local/bin/macvlan-setup.sh /usr/local/bin/macvlan-teardown.sh

创建 systemd 服务单元：

cat > /etc/systemd/system/macvlan-setup.service << 'EOF'
[Unit]
Description=Setup macvlan proxy for OpenWrt container
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/macvlan-setup.sh
ExecStop=/usr/local/bin/macvlan-teardown.sh

[Install]
WantedBy=multi-user.target
EOF

启用并启动：

systemctl daemon-reload
systemctl enable macvlan-setup.service
systemctl start macvlan-setup.service

验证：systemctl status macvlan-setup.service 应显示 active。重启后配置自动生效。

此方案理论上适用于所有基于 NetworkManager 或 systemd 的 Linux 发行版，不限于 openSUSE。

5. 修复 frpc 导致 LuCI 卡顿的问题

OpenWrt 软件源中的 frpc 版本较旧，且其配置文件格式与新版 luci-app-frpc 存在不兼容。如果你直接 opkg install frpc，然后通过 LuCI 配置，可能会遇到整个 Web 界面加载极慢甚至完全卡死的情况。

解决方法：先用包管理器安装全套 frpc 工具链（包括 LuCI 界面），然后用最新版 frpc 二进制文件覆盖。

5.1 进入容器

docker exec -it openwrt /bin/bash

5.2 安装 frpc 及 LuCI 界面

opkg update
opkg install frpc luci-app-frpc

此时 LuCI 中会出现 frpc 配置页面，如果此时直接完成配置并启动，可能会因二进制版本过旧而卡顿。

5.3 手动替换 frpc 二进制（以 x86_64 为例，里面的frp版本需要根据实际GitHub Release为准）

cd /tmp
wget https://github.com/fatedier/frp/releases/download/v0.61.2/frp_0.61.2_linux_amd64.tar.gz
tar -xzf frp_0.61.2_linux_amd64.tar.gz
cp frp_0.61.2_linux_amd64/frpc /usr/bin/frpc
chmod +x /usr/bin/frpc

确认版本：frpc --version

5.4 重启服务

/etc/init.d/frpc restart
# 或者直接退出容器后
docker restart openwrt

此时再打开 frpc 服务， LuCI 的 WebUI 会保持流畅。

6. 华为路由器用户的特殊注意事项（重要）

如果你的宿主机在部署过程中出现了 IP 莫名丢失、无法联网 的现象（例如 openSUSE 的 192.168.3.16 突然消失），除了前面提到的取消 NetworkManager 对 enp1s0 的管理外，还需要检查 路由器后台的局域网防火墙。

以我使用的 华为路由 BE3 Pro 为例：

• 打开“智慧生活”App → 设备 → 安全防火墙 → 局域网防火墙 → 点击右上角“四点”菜单 → 关闭。

华为路由默认开启的局域网防火墙会阻止某些“非标准”的 ARP 包或二层通信，导致你手动创建的 macvlan 代理接口或 Docker 的 macvlan 网络与宿主机通信时被拦截，进而造成宿主机 IP 地址被“踢出”网络。

关闭这个选项会有安全风险吗？
一般家庭内网环境，只要你的 Wi-Fi 密码不是弱密码，没有把端口直接暴露在公网，关闭局域网防火墙基本不会带来实质性的攻击面。如果你实在不放心，可以先关闭该选项，等所有配置稳定后，再尝试在路由器后台将宿主机和容器的 MAC 地址与 IP 进行固化绑定，然后重新打开局域网防火墙（此方法我尚未测试，但理论可行）。

调侃一句：如果你真的因为关闭了这个选项导致家庭网络被攻击，那大概率不是这个选项的锅，而是你家里接了什么不该接的设备（比如某款智能插座或摄像头自带后门）。建议先检查内网拓扑，而不是甩锅给防火墙。

7. 最终验证清单

• 局域网其他设备可访问 http://192.168.3.20（OpenWrt LuCI）

• 宿主机 ping 192.168.3.20 成功

• 宿主机重启后 macvlan0 接口自动出现，路由自动添加

• OpenWrt 容器能正常上网（检查网关、DNS）

• frpc 配置页面不卡顿，服务正常运行

8. 总结

说实话，这个折腾的过程一言难尽，一方面是OpenWRT绝大部分人并不会将它部署在Docker中，反而是直接部署在物理机上，而且有成熟的iStoreOS作为国内的高度可选项，部署docker版OpenWRT的人就更少了，所以资料也参差不齐。

好消息是，坑已经踩过了，而且是带着可恢复选项踩的，如果这个过程有一丝一毫的问题，我直接带着snapper快照回退就行。

坏消息是，这只是其中一种方法，如果真要针对容器OP这一个点，理论上可以延伸出：

• 飞牛/FnOS + Docker QWRT：飞牛系统底层也是Debian/ARMbian Linux，同样可以用docker跑QWRT，但飞牛的NetworkManager策略和防火墙规则更“魔改”，如果不是飞牛应用商店安装，而是直接在常规Linux上装，那坑也是一抓一大把。

• LXC OpenWRT + Linux Bridge：用LXC（Linux容器）跑OpenWRT，配合手工创建的bridge-utils桥接，宿主机与容器天然互通，不需要macvlan绕路。但LXC的配置比docker复杂，且需要内核开启namespace支持，openSUSE上默认ok，但管理工具lxc/lxd的文档不如docker丰富，而且有可能会直接把底层干炸。

• KVM虚拟化：学PVE直接把OpenWRT装在QEMU里，网卡透传或virtio，稳定性最高，资源占用也高，且需要CPU虚拟化支持。

• podman + macvlan：podman号称“无守护进程的docker”，但macvlan的行为基本一致，同样有宿主机互通问题，解法类似。

所以说，我记录的这个方案仅仅是“在docker+macvlan+systemd场景下的一种可复现解法”。如果你用的是其他发行版、其他容器运行时、或者就是想玩LXC，那配置逻辑可能完全不同。但核心思路不变：理解macvlan的设计局限 + 代理接口 + 持久化。

如果你懒得折腾，直接物理机装iStoreOS，插个U盘做旁路，一劳永逸。但如果你跟我一样，手头只有一台服务器，不想浪费资源再起一个VM，那么docker+macvlan+frp这套组合拳，已经是被我验证过、能稳定跑数周的生产级方案。

最后送一句：玩软路由，快照是你最好的朋友；没快照，别乱改网络配置。