具有独立IP地址(网络命名空间)的系统-n生成容器不能工作。

Question

看一下systemd-nspawn的文档，它一定是想要有一种非常方便用户的方式来在不同的网络命名空间中启动容器。您可以使用-n选项，只需在两端启用systemd-networkd.service。容器在一个“私有”范围内获取自己的IP地址。(DNS可能需要一些附加步骤)。

结果是，我在范围169.254.*.*中获得了一个IP地址。默认路由点位于host0接口，无需通过任何网关/路由器。试图访问互联网服务器(例如8.8.8.8 )的尝试以“无主机路径”失败。(如果这样做不起作用，就没有必要计算DNS )。

如果我在主机上运行tcpdump -i ve-fedora-25，我可以看到DHCP请求，但是它们没有响应。systemd肯定是在主机上运行的。主机端的日志在ve-fedora-25上显示“已获得的载波”，networkctl将其显示为“可路由的”&“配置的”都是绿色的。

我的系统是Fedora 25。我想要一个可以使用TCP/IP连接到的OS容器，同时能够连接到世界(例如运行dnf包管理器)。就像libvirt的VM是如此的容易开箱即用。哪里出问题了？

Answer 1

问题是Fedora的火瓦尔德。看上去，n育从未与firewalld集成过。(n溯源也没有正确地与Fedora的SELinux策略集成)。

正如问题中提到的，libvirt运行良好:)。我们可以使用与上的LXC一起运行容器时发现的相同技巧。

更新:升级到Fedora 30.

后，解决方案停止工作。

使用选项--network-bridge virbr0运行systemd-n派生。这不依赖于systemd-networkd，而是利用了libvirtd.service。默认情况下，后一个服务已经在Fedora上启动。在客人中，像往常一样设置您喜欢的DHCP客户端。

当使用systemd-networkd作为

客户端

时，DHCP DNS解析

使用systemd-networkd作为DHCP客户端可能会意外地独立工作，如果您可能有一个来自上一个容器引导的遗留/etc/resolv.conf。但一般情况下你不能依赖这一点。它实际上是为与systemd-resolved.service一起运行而设计的。

反过来，systemd解决方案也打算与nss-resolve一起使用。然而，这并不是必要的AIUI。