☰

個別の IP アドレス (ネットワーク名前空間) を持つ systemd-nspawn コンテナが動作しない

tag-icon • tag-icon networking systemd-nspawn
個別の IP アドレス (ネットワーク名前空間) を持つ systemd-nspawn コンテナが動作しない

のドキュメントを見るとsystemd-nspawn、異なるネットワーク名前空間でコンテナを起動するための非常にユーザーフレンドリーな方法が用意されているはずです。-nオプションを使用して、systemd-networkd.service両端で有効にするだけです。コンテナは「プライベート」範囲の1つで独自のIPアドレスを取得します。（DNSにはいくつかの追加ステップ）。

結果として、範囲 の IP アドレスが取得されます169.254.*.*。デフォルト ルートは、host0ゲートウェイ/ルーターを経由せずにインターフェイスを指します。たとえば、インターネット サーバーに到達しようとすると、8.8.8.8「ホストへのルートがありません」というエラーが表示されて失敗します。(これが機能しない場合は、DNS を解析しても意味がありません)。

ホスト上で実行するとtcpdump -i ve-fedora-25、DHCP 要求は表示されますが、応答はありません。systemd-networkd は間違いなくホスト上で実行されています。ホスト側のログには「Gained carrier」と表示されve-fedora-25、networkctl ではこれが「routable」および「configured」としてすべて緑色で表示されます。

私のシステムは Fedora 25 です。TCP/IP を使用して接続できる OS コンテナーが必要ですが、同時に外部に接続することもできます (例: パッケージ マネージャーを実行するため)。VMがそのまま簡単に動作するdnfのと同じように。何が間違っているのでしょうか?libvirt

答え1

問題はFedoraのファイアウォール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 にとって必須ではありません。

関連情報