IPv6 Docker 跑 BT 的方案和问题

[LnTrx]

需求

BT 的机制会将本机的 IPv6“昭告天下”，可能会引来外部刺探，抵消 IPv6 超大地址空间的天然安全优势。
因此，想用 Docker 给 BT 分配一个独立的 IPv6 。

实现方式

我在过去的帖子有讨论过类似的做法，简单过一下。

建一个 macvlan 网卡：

docker network create -d macvlan \
  --subnet=192.168.x.0/24  \
  --gateway=192.168.x.1 \
  --ipv6 --subnet=fd00:8::/80 \
  -o parent=外网网卡 \
  -o macvlan_mode=bridge macvlan1

开一个 BT 的 Docker：

docker run -d \
  --name=qbittorrent \
  -e PUID=??? \ #防止文件权限都是 root 影响其他应用
  -e PGID=??? \
  -e TZ=Asia/Shanghai \
  -e WEBUI_PORT=6666 \ 
  --ip=192.168.x.211 --net=macvlan1\
  --add-host=tracker.example.com:9.9.9.9 \  #固定 tracker 为 IPv4 地址，减少双栈上报的问题
  -v 配置路径:/config \
  -v 下载路径:/downloads \
  --restart unless-stopped \
  linuxserver/qbittorrent:4.4.5

要远程访问 IPv6 Docker ，一种是直接 DDNS ，过去的帖子讨论过。但配 SSL 还是有点小麻烦，这里选择在宿主的反代上统一处理，也顺便隐藏了 WebUI 入口。然而 macvlan 默认禁止宿主访问，可以参考网友的方案（国内 国外）来绕过：

ip link add brmv0 link 外网网卡 type macvlan mode bridge
ip addr add 192.168.x.210/32 dev brmv0 #子网中未用过的 IP
ip link set brmv0 up
ip route add 192.168.x.211/32 dev brmv0 #目标 Docker 的 IP

如此宿主就能通过 192.168.x.211:6666 访问容器。重启会失效，可以加入到开机脚本。顺便一提，也可用 IPv6 的私有段来互通。

小问题

如此配置，IPv4 的 UPnP 工作如常，容器能从路由获取 SLAAC IPv6 并正常访问，系统重启后亦是如此。

查看客户端回报到 tracker 的信息，IPv4 是公网 IP ，但 IPv6 却是 [::]。
此时在配置界面修改 BT 的监听端口或者网络接口一次，IPv6 上报就会变为容器的公网 IPv6 。
但容器只要重启，IPv6 上报的问题就会再次出现。

尽管只是一个小问题，还是让人有点头疼，尝试修改了多项 qBittorrent 的配置也未能解决。
个人推测，可能是 qBittorrent 启动得“太快”了，以至于网络接口还没来得及配置好 IPv6 。而当配置完成后，软件也没有及时更新信息。

于是，想到了一种简单粗暴的办法，即直接修改容器的启动脚本：

docker exec -it qbittorrent vi /init

在靠前的位置插入：

sleep 5

保存后再重启容器，IPv6 回报的问题就消失了。

考虑到 IPv6 配置延迟的问题可能会在不止这一个场景下出现，而且这个办法实在有失优雅，所以发出来想了解一下是否有更好的解决方案。

上述配置中 webui 默认监听公网，实际使用请记得改密码或只监听内网

[iniwex]

host 模式不好吗

[jousca]

引来外部刺探------------你本机防火墙干啥用的？允许出站端口，不开放入站端口，它刺探出个啥？？

[LnTrx]

@jousca 防火墙只要是人配的就可能有失误。我的主机存在有入站需求的端口，即使防火墙正确、应用安全到位也可能有 0day ，即使没有被攻破从报文也能分析出很多信息。总之增加一个隔离没什么坏处。
这不是说只做本机防护不安全，而是说利用 IPv6 的特性有望更安全。

[LnTrx]

@iniwex 前面已经讲过了，目的是分配一个独立的 IPv6 。

[iniwex]

@LnTrx QB 得话里面绑定得网口可以单独设置为仅 ipv6 地址，这样 v4 地址就不会介入

[guazila]

这个方法很不错。我测试过，开了 IPV6 地址下载 BT ，把 V6 地址暴露出去，防火墙拦截次数会从每天十几个暴涨到每天近十万个，坏人还是很多的。

[evalfun]

我的解决方案是用 pve 开一个 lxc 容器，然后将本地存储挂载进容器里面，lxc 容器网卡直接桥接到内网里面，挺方便的

[YGBlvcAK]

感谢楼主的分享，学会了 docker 配置 ipv6 的方法，楼上有些人真是吃饱了撑的，这都喷，自己不需要就觉得所有人都不能需要，另外，分享一个更简单的测试 ipv6 连通性的命令：
docker run --rm --net=macvlan1 busybox ping 240c::6666

[LnTrx]

即便没被攻破也可能刺探到不少信息。试想以下流程：

1. 通过 tracker 获知用户 IP
理论上可以知道哪个 IP 在下什么种。

2. 扫描获得用户 IP 的端口分布
从开了什么服务可以对用户有一个初步的了解。

3. 通过 https 端口获得域名证书
直接 IP 访问有效的 https 口，成品 NAS 大概率返回的是域名证书，而且至少 UI 上没处可改 ssl_reject_handshake 。

4. 通过域名获得更多信息
NAS 的域名大概率是 DDNS ，这样就可以持续追踪，架空了 IPv6 随机可变的优势。即使现在主机固若金汤，也保不齐未来会出纰漏。域名本身还能进一步挖出更多信息，如果 beian 了更是一步实名。

[LnTrx]

理想情况下，安全措施做到位，再分离 IP 的增益不是很明显。
但现状是，单就论玩 NAS 的，各种监听[::]、主机防火墙放开、弱密码甚至默认密码都不鲜见。即使有这方面的知识，也容易有侥幸心理或者不方便而无法做到完善。比如常见虚拟组网方案在不少场景还是不太方便，如果给亲友下载个东西总不能发个 tailscale ，宿主还是得暴露几个入站。
所以，IPv6 地址的隔离至少应能帮助一些人规避掉一个明显的攻击面。这个攻击面其实 IPv4 也有，但 IPv6 的防火墙配置更容易疏忽，而且利用 IPv6 超大的地址空间也能给出新的解决方案。

[jousca]

既然提到了超大地址空间，有没有一种可能你给 Docker 随机配置几百个 V6 公网地址几分钟切换？

[LnTrx]

@jousca 没有现成的方案，也不理解为啥有这种需求。
可以给个思路，比如通过指定容器的 MAC 来决定各容器的 EUI-64 后缀：
docker run --rm --net=macvlan01 --mac-address 00:11:22:33:44:55 busybox sh -c "sleep 5;ip addr"
理论上完全可以开几百个不同 IP 的 docker （可能会耗尽 IPv4 的内网 IP ）

[anonex]

我用 NAT6

[LnTrx]

@anonex NAT6 的外网 IP 不是同一个嘛

[LnTrx]

陆续看到有不少收藏的，也可以聊聊在各自机器上验证的情况

[guhui]

我家里主路由获得了 /64 的前缀（浙江移动），下有一台 QNAP NAS 运行 docker ，包括 transmission 。目前 transmission 采用 host 模式使用 NAS 的 IPv6 地址，我想给 transmission 设置单独的 IPv6 地址。

我查了很多资料，/64 的地址池似乎无法再自动地划分子网。实际上我没有划分子网需求，只要容器有全球单拨 IPv6 地址就行。目前看到创建 macvlan 应该是可行的办法，看了你的步骤，我还有这些问题：

创建 macvlan 网络时，参数 `—subnet` 这里的 `fd00:8::/80` 是否改为自己的 /64 地址段？是否还需要将网关设置为主路由 lan 侧接口（比如 switch0 ）的 IPv6 地址？需要的话，是填写 switch0 的单拨地址，还是链路本地址即可？
```bash
--ipv6 --subnet=fd00:8::/80
```

实际上威联通在 Container Station 自带了一个名为 `qnet` 的容器网络，它允许容器使用与主机相同的 IPv4 局域网段，但该缺少 IPv6 配置，也无法修改其配置。

[LnTrx]

@guhui fd00:8::/80 是给网卡规划的本地地址，与 NAS 自身的公网、局域网 IP 无关。macvlan 配置下 docker 会从上级路由自动获取新的公网 IP ，在我的测试中无需手动配置 IPv6 网关。

[wxg1015]

@LnTrx 尝试把 ipv6 指定为 fe80 呢 我试了下 指定 fd00 进容器看 属于 scope:glob 是不是因为这个
指定 fe80::的话 进去看是 scope:link 似乎就默认不会汇报链路本地地址

[wxg1015]

好吧 我理解错了 你的意思应该是指 容器启动过快 导致启动了 qb 后却还没从路由器获取到 ipv6 slaac 地址（指定的内网 v4 ，v6 地址已经获取到）导致第一次的汇报 v6 是[::]吧？我这边是群晖 docker 好像没遇到这情况···· 不过我这边同时也指定了 fd00:8::1 作为网关 不知道是不是这个有关？没有配置网关导致 macvlan 没有及时获取公网 v6 ip ？ 总而言之本质上应该还是容器本身没有及时从路由器获取 slaac 地址导致的吧 如果有这种情况应该也无所谓吧 下次汇报就会有了