ドキュメントを見ると、systemd-nspawn非常にユーザーフレンドリーな方法でさまざまなネットワークネームスペースのコンテナを起動するためのものであるに違いありません。この-nオプションを使用するには、systemd-networkd.service両端で有効にするだけです。コンテナは、「プライベート」範囲の1つから独自のIPアドレスを取得します。 （DNSには一部が必要な場合があります。追加ステップ）。
その結果、範囲内のIPアドレスが得られます169.254.*.*。デフォルトパスはこのhost0インターフェイスを指し、ゲートウェイ/ルータを通過しません。たとえば、インターネットサーバーにアクセスしようとすると、8.8.8.8「ホストへのパスなし」メッセージで失敗します。 （これがうまくいかない場合は、DNSを解決する意味はありません。）
ホストでこれを実行すると、tcpdump -i ve-fedora-25DHCP要求を表示できますが、応答を受け取りません。 systemd-networkdがホストシステムで実行されている必要があります。ホスト側ログには「Getting Operator」と表示されve-fedora-25、networkctlは「Routeable」と「Configured」の両方で緑色で表示されます。
私のシステムはFedora 25です。私はTCP / IPを使用して接続できますが、世界に接続できるオペレーティングシステムコンテナを望んでいます（パッケージマネージャのdnf実行など）。仮想マシンと同様に、基本的libvirtに簡単に使用できます。何が間違っていますか？
ベストアンサー1
問題はFedoraにあります。ファイアウォール。 nspawnは決してファイアウォールと統合されていないようです。 （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。