O host está obtendo um IP de um dispositivo em ponte, mas uma VM virt-manager não está

Docker usa iptables para gerenciar seus contêineres, assim como libvirt também o usa. Mas geralmente o Docker não funciona bem com outras ferramentas relacionadas à rede em execução no mesmo sistema, por dois motivos:

• O Docker carrega o br_netfiltermódulo do kernel que faz com que os quadros em ponte atravessem iptables (em vez de apenas ebtables ).

• Docker também define a política padrão de filtro/FORWARD do iptables para DROP

  O Docker também define a política da FORWARDcadeia como DROP. Se o seu host Docker também atuar como um roteador, isso fará com que o roteador não encaminhe mais nenhum tráfego. Se quiser que seu sistema continue funcionando como um roteador, você pode adicionar ACCEPTregras explícitas à DOCKER-USERcadeia para permitir isso.

A combinação destes, e o fato de br_netfilterfazer isso como comportamento padrão , qualquer ponte presente no sistema, seja ela relacionada ou não ao Docker, herda uma política de encaminhamento padrão de DROP através do iptables , além de tudo o que o ebtables possa fazer se também estiver presente : qualquer quadro encaminhado é descartado.

Portanto, todas as pontes manipuladas pela libvirt são afetadas: as VMs ficam isoladas devido à execução do Docker. Conforme citado acima, exceções podem ser adicionadas (mas na verdade devem ser inseridas em vez de adicionadas) à DOCKER-USERregra de cadeia criada pelo Docker (mas que pode ser criada primeiro pelo administrador, se necessário). Apenas adicionar regras à FORWARDcadeia pode não ser suficiente porque o Docker sempre insere suas regras antes (mas chama DOCKER-USERprimeiro).

Para permitir que qualquer ponte não Docker não seja filtrada por iptables , pode-se usar uma das seguintes opções:

1. combinar por endereço IP o que pode ser encaminhado. Não será mais fácil diferenciar do DHCP usando endereços como 0.0.0.0 e 255.255.255.255, eles também devem ser adicionados. Para o IP LAN 192.0.2.0/24 isso seria:

   iptables -N DOCKER-USER || true # doesn't matter if done before Docker or after (and thus already existing)
   iptables -I DOCKER-USER -s 192.0.2.0/24 -d 192.0.2.0/24 -j ACCEPT
   iptables -I DOCKER-USER -s 0.0.0.0/32 -d 255.255.255.255/32 -j ACCEPT
   

2. ou, em vez disso, combine por interface não Docker

   A menos que sejam nomeados de forma personalizada, as interfaces do Docker são sempre nomeadas como docker0ou br-.... Não use a mesma convenção de nomenclatura e adicione exceções para elas.

   Do ponto de vista do iptables , os quadros em ponte encaminhados das portas da ponte eno1 e, por exemplo, vnet0 (a interface tap para a VM) são apresentados como provenientes da interface br0 : a porta da ponte não será vista, então o pacote vem de br0 e é encaminhado para br0 .

   A ordem é importante. A declaração do índice de inserção mantém uma ordem natural para as regras abaixo, como se elas tivessem sido adicionadas -A(mas elas precisam ser inseridas porque o Docker adicionou um final -j RETURN).

   iptables -N DOCKER-USER || true
   iptables -I DOCKER-USER 1 -i docker0 -o docker0 -j RETURN
   iptables -I DOCKER-USER 2 -i br-+ -o br-+ -j RETURN
   

   Permitir br0e br1:

   iptables -I DOCKER-USER 3 -i br0 -o br0 -j ACCEPT
   iptables -I DOCKER-USER 4 -i br1 -o br1 -j ACCEPT
   

   Vamos continuar com outros nomes comuns para libvirt e LXC (também uma vítima comum):

   iptables -I DOCKER-USER 5 -i virbr0 -o virbr0 -j ACCEPT
   iptables -I DOCKER-USER 6 -i lxcbr0 -o lxcbr0 -j ACCEPT
   

3. ou, em vez disso, faça com que o iptables obtenha algumas informações de ponte para tomar uma decisão

   Mesmo que pareça mais genérico, deve ser evitado, porque o uso do physdevmódulo match carrega o br_netfiltermódulo do kernel para funcionar se ainda não estiver carregado, portanto, ele estará presente mesmo quando não estiver usando o Docker, embora seu objetivo seja proteger-se do carregamento do Docker br_netfilter. É um pouco mais poderoso porque permite distinguir quadros que foram interligados de pacotes que foram roteados (com um roteamento de um braço que usa uma ponte como interface de roteamento).

   Exceções para o Docker ainda são necessárias, pois o Docker faz sua própria filtragem de LAN em suas próprias cadeias. Qualquer coisa que não seja Docker e em ponte (em vez de roteada) é permitida.

   iptables -N DOCKER-USER || true
   iptables -I DOCKER-USER 1 -i docker0 -o docker0 -j RETURN
   iptables -I DOCKER-USER 2 -i br-+ -o br-+ -j RETURN
   iptables -I DOCKER-USER 3 -m physdev --physdev-is-bridged -j ACCEPT
   

As escolhas anteriores podem não funcionar em todos os casos possíveis, considerando que a própria libvirt possui regras na cadeia FORWARD que podem não funcionar corretamente ou podem sofrer curto-circuito pelas regras do Docker. Embora as regras nat , que também são afetadas, geralmente sejam tratadas de forma completamente correta neste caso pela libvirt (e pelo LXC).

4. Docker em uma VM

   Não misture o Docker com nenhuma outra ferramenta de rede, pois isso atrapalhará seu comportamento na presença de uma ponte. Em vez disso, execute o próprio Docker em uma VM onde esteja devidamente isolado e não afete o host ou outras VMs e contêineres (por exemplo: LXC) no host. Então, se esta VM estiver conectada à rede principal, como a configuração do host atual já permite, isso não mudará muito nas configurações externas para alcançar seus contêineres: o Docker terá apenas seu próprio endereço IP separado na LAN física, em vez de os anfitriões.

5. outras possibilidades (requer kernel >= 5.3)

   Pré-carregue br_netfilterpara ter certeza de obter as configurações do sysctl disponíveis e desative a configuração de todo o sistema para iptables com:

   modprobe br_netfilter
   sysctl -w net.bridge.bridge-nf-call-iptables=0
   

   e ative-o novamente em pontes selecionadas do Docker (possivelmente usando um script executando comandos do Docker para recuperar seus nomes):

   ip link set dev docker0 type bridge nf_call_iptables 1
   ip link set dev br-5039242381f0 type bridge nf_call_iptables 1
   

   Isso exigirá ações em cada nova ponte criada.

   Uma outra maneira poderia ser o Docker-in-Docker sendo executado em um contêiner com apenas a configuração global desabilitada (esta configuração ainda está habilitada por padrão em novos namespaces de rede...). Isso parece cada vez mais difícil devido à carga adicional de gerenciamento do que executar o Docker em uma VM.

Eu escolheria 4. (VM: evita todas as interferências possíveis do Docker) ou então 2. (mantenha-o simples, mas bom o suficiente)

Nota: tudo o que está escrito se aplica ao IPv6, substituindo iptablespelo ip6tablesacima (incluindo o sysctl). Para integração com nftables , consulte esta resposta específica do nftables .