求大佬帮忙分析下 NAS 的诡异网络问题

[dewreg]

看看有没有大佬专家有兴致帮忙分析一些诡异的家庭 NAS 的网络问题，诡异在于：

现状：
1. 一个 x86 Ubuntu （作 Linux NAS ），一个 Mac Mini M4 （作桌面端）
2. Ubuntu 上的服务：
- 照片服务
- QB 下载
- 透明代理（ mihomo/clas ，虚拟机或者 Docker 方式）
- Nginx 反代（ ipv6 ddns ，反代照片服务到公网，虚拟机或者 Docker macvlan ）


理想目标：
- 不想用 VirtualBox 虚拟机，Docker 更轻量简单
- Ng 通过 Docker macvlan 反代，隔离机器和服务
- 透明代理也能通过 Docker 方式，给家里其他设备做透明代理网关使用
- 其他服务正常


问题：
- 使用 Docker macvlan ，宿主机和容器不能通信，有自己搞桥接口的 trick 方法，为什么用 macvlan ，主要用 bridge 的方式搞不定容器独立的 ipv6 （ host 模式就没安全意义了），用 bridge 的话有没有办法搞定？
- 透明代理 Mihomo/Clash ，虚拟机方式部署一切正常，「同样的配置 config.yaml 」 在宿主机上直接程序跑和使用 Docker 的方式，UI 管理界面中所有代理节点全都出不来，但体验上，宿主机裸跑和 Docker 都比虚拟机方式体感流畅非常多（虚拟机配置是够的，符合普通代理体感），这是为什么呢？
- Mac 也可以直接使用 Clash Verge 做透明代理，与 Linux 下裸跑和 Docker 方式一样，都无法在本地访问 Ng 反代的服务(ipv6)，怀疑是 ipv6 解析的问题，但是虚拟机里面的透明代理又正常，这个是最疑惑的点！
- QB 下载，用 macvlan 之后，网络就不太正常，用普通模式，速度又不行（ ipv6 ？）又为什么呢？
- 以及有没有其他更优解？

[trio]

这是我的 macvlan+bridge 的初始化脚本，宿主机可以和容器通信。
#!/bin/bash

# 检查网络是否存在
NETWORK_COUNT=$(docker network ls | grep -c zte_macvlan)
if [[ "$NETWORK_COUNT" -gt 0 ]]; then
echo "zte_macvlan network already exists"
else
echo "Creating zte_macvlan network"
docker network create --driver=macvlan \
--subnet=192.168.6.0/22 \
--gateway=192.168.5.1 \
-o parent=ovs_eth0 zte_macvlan
fi

# 创建 macvlan_host 并配置 IP
ip link add macvlan_host link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.6.2/22 dev macvlan_host

# IPv4 路由
for i in $(seq 100 140); do
ip route add 192.168.6.$i dev macvlan_host
done

# 启用 macvlan_host
ip link set macvlan_host up

[dewreg]

@trio 感谢，通过桥接确实可以解决通信问题，在我的场景下也可以忽略，只是好奇，Docker bridge 方式是不是没法有公网 ipv6 了 ?

[dewreg]

@trio 以及 docker inspect 看到的 macvlan 分配的 ipv6 ，和 DDNS 解析的 ipv6 也不一样，也着实不解，但是 DDNS 的确实能通

[pagxir]

建 Mac vlan 的时候不要选 private mode 即可。

[wheat0r]

bridge 就是 nat ，IPv4 和 IPv6 都是。
macvlan 网络的 IPv6 一般是配置一个 ULA ，实际上容器会同时得到 macvlan 这边来的 ULA 和路由器来的公网地址。

[dewreg]

@wheat0r 感觉 bridge 的 ipv6 （公网），就没法配成功过，这个是符合预期的不，如果 bridge 的 ipv6 能公网，也感觉不要 macvlan 了

[wheat0r]

@dewreg 正常来说 bridge 就没有公网，不存在怎么配置。

[dewreg]

@wheat0r 那确实不符合使用场景的预期

[dewreg]

@pagxir 默认是 vepa 模式？和宿主也不能通信，需要 macvlan 的 bridge 模式？

[greenskinmonster]

不考虑主系统迁移到 proxmox 吗？ lxc+docker 也很轻量化，网络结构规划和业务分离更加容易。

[dewreg]

@greenskinmonster 之前用了下 PVE ，然后莫名奇妙死机一次，也不知道是啥原因造成的，加上硬件直通也搞不明白，为了简单就直接 ubuntu 了，再回去可能也是一种选择 。。。

[Jisxu]

@dewreg #11 pve 底层是 debian ，跟 ubuntu 是一个家族的，命令差不多

[MacsedProtoss]

pve 才是正解 docker 跑这么多这么重的东西不太合理啊
我的 pve 持续跑一年不重启都没有问题 至于直通啥的得具体问题具体分析 我也有直通显卡和 nvme 的

[YsHaNg]

@MacsedProtoss 这才几个东西 docker 真不至于这么不堪 你这说法把跑 compose 甚至 k8s 的往哪放 至于容器都不需要直通 比如多个应用分享 gpu 非常轻松

[trio]

@dewreg 这需要在创建 docker network 的时候，补充--ipv6 相关的前缀/子网；可以生效，每个容器都有独立的公网可以访问的 IPV6 ；但是当 ISP 变更 IPV6 前缀，你的配置又得重新刷一遍，因此这方法不稳定。

[leo7476040305]

@dewreg PVE + 1, 透明代理可以采用 Surge On Macmini 或者 PVE 开 VM 装 OpenWRT 。Docker 的网络配置远比 PVE 的复杂。
访问照片服务可以用 Surge Ponte 或者 WireGuard / Tailscale 。
至于莫名其妙死机你可以待其恢复后查看 syslog ，并根据具体设备分析。

[yanqiyu]

@dewreg 想要 bridge 下面有公网 ipv6 要么你的上游接口有 ipv6-pd/你可以配静态路由，拿到或者路由过来一个段，然后你把那个前缀广播下去。

要么你启一个 6relayd/ndppd 这样的工具，把上游口的前缀直接广播下去，然后在两个接口之间代理 ndp+写路由。

（可悲的是现在的容器网络管理程序都不支持 DHCPv6/SLAAC ？但是我猜改一下容器里面的 sysctl 配合 ra 应该能让内核负责配地址？或者要是上游是静态的前缀直接就在容器管理器里面配置静态地址了）

说实话我更喜欢容器一个对外的 macvlan+一个对内的 bridge ，省心一点