contêiner systemd-nspawn com endereço IP separado (namespace de rede) não está funcionando

1

Olhando a documentação para systemd-nspawn , ela deve ter sido planejada para ter uma maneira muito fácil de usar para iniciar contêineres em um namespace de rede diferente. Você usa a opção -n e simplesmente ativa systemd-networkd.service em ambas as extremidades. O contêiner recebe seu próprio endereço IP em um dos intervalos "privados". (O DNS pode exigir alguma etapa adicional ).

O resultado é que obtenho um endereço IP no intervalo 169.254.*.* . A rota padrão aponta na interface host0 sem passar por nenhum gateway / roteador. Tentativas de acessar os servidores de internet, por exemplo 8.8.8.8 falha com "Nenhuma rota para hospedar". (Nenhum ponto de trabalhar com o DNS, se isso não funcionar).

Se eu executar tcpdump -i ve-fedora-25 no host, posso ver as solicitações de DHCP, mas elas não são respondidas. O systemd-networkd está definitivamente rodando no host. Os logs do lado do host mostram "Gained carrier" em ve-fedora-25 , e networkctl mostra isso como "roteável" & "configurado" tudo em verde.

Meu sistema é Fedora 25. Eu quero um contêiner de sistema operacional que eu possa conectar usando TCP / IP, e ao mesmo tempo ser capaz de se conectar ao mundo (por exemplo, para executar o gerenciador de pacotes dnf ). Assim como libvirt VMs funcionam tão facilmente fora da caixa. O que deu errado?

    
por sourcejedi 10.04.2017 / 17:41

1 resposta

4

O problema é que o firewalld do Fedora. Parece que o nspawn nunca foi integrado ao firewalld. (O nspawn também não está corretamente integrado com a política SELinux do Fedora).

Como mencionado na pergunta, o libvirt está funcionando bem :). Nós podemos usar o mesmo truque que as pessoas descobriram para rodar containers com o LXC no Fedora .

Execute systemd-nspawn com a opção --network-bridge virbr0 . Em vez de depender de systemd-networkd , isso aproveita libvirtd.service . O último serviço já é iniciado por padrão no Fedora. No convidado, configure seu cliente DHCP preferido como de costume.

Resolução de DNS ao usar systemd-networkd como cliente DHCP

Usar systemd-networkd como cliente DHCP pode acidentalmente funcionar sozinho, se você tiver uma sobrecorrente /etc/resolv.conf de uma inicialização de contêiner anterior. Mas você não pode confiar nesse trabalho em geral. Ele foi realmente projetado para ser executado junto com systemd-resolved.service .

Por sua vez, o systemd-resolved deve ser usado com nss-resolve . No entanto, isso não é AIUI essencial.

    
por 10.04.2017 / 17:41