具有单独 IP 地址(网络命名空间)的 systemd-nspawn 容器不起作用

sou*_*edi 3 networking systemd-nspawn

查看 的文档systemd-nspawn,它肯定旨在以一种非常用户友好的方式在不同的网络命名空间中启动容器。您使用该-n选项,只需systemd-networkd.service在两端启用即可。容器在“私有”范围之一中获取自己的 IP 地址。(DNS 可能需要一些额外的步骤)。

结果是我获得了范围内的 IP 地址169.254.*.*。默认路由指向host0接口,不经过任何网关/路由器。尝试访问 Internet 服务器,例如8.8.8.8失败,并显示“No route to host”。(如果这不起作用,则没有必要计算 DNS)。

如果我tcpdump -i ve-fedora-25在主机上运行,我可以看到 DHCP 请求,但没有响应。systemd-networkd 肯定在主机上运行。主机端日志在 上显示“Gainedcarrier” ve-fedora-25,networkctl 将其显示为“可路由”和“已配置”,全部为绿色。

我的系统是 Fedora 25。我想要一个可以使用 TCP/IP 连接到的操作系统容器,同时能够连接到世界(例如运行dnf包管理器)。就像libvirtVM 开箱即用一样轻松。出了什么问题?

sou*_*edi 5

问题是 Fedora 的firewalld。似乎 nspawn 从未与 firewalld 集成。(nspawn 也没有与 Fedora 的 SELinux 策略正确集成)。

正如问题中提到的,libvirt 工作正常:)。我们可以使用人们发现的在 Fedora 上使用LXC运行容器的相同技巧。

更新:升级到 Fedora 30 后,该解决方法停止工作。


使用选项运行 systemd-nspawn --network-bridge virbr0。这不是依靠systemd-networkd,而是利用libvirtd.service。后一个服务已经在 Fedora 上默认启动。在来宾中,像往常一样设置首选的 DHCP 客户端。

使用 systemd-networkd 作为 DHCP 客户端时的 DNS 解析

使用systemd-networkdDHCP客户端可能会意外地工作在自己,如果你可能有一个遗留的/etc/resolv.conf从以前的容器中启动。但是你不能依赖这个工作。它真的被设计为与systemd-resolved.service.

反过来,systemd-resolved 旨在与nss-resolve. 然而,这不是必不可少的 AIUI。