☰

firewalld: interface que muda zonas de forma autônoma

tag-icon • tag-icon docker firewalld rhel8
firewalld: interface que muda zonas de forma autônoma

Eu tenho um sistema RHEL8 servindo como nó de trabalho Docker Swarm. Ele está firewalldhabilitado e possui uma dockerzona à qual as interfaces docker0e docker_gwbridgesão atribuídas.

$ cat /etc/firewalld/zones/docker.xml
<?xml version="1.0" encoding="utf-8"?>
<zone version="1.0" target="ACCEPT">
  <short>docker</short>
  <description>zone for docker bridge network interfaces</description>
  <interface name="docker_gwbridge"/>
  <interface name="docker0"/>
</zone>

Após reinicializar, firewalldreiniciar ou recarregar, essas interfaces aparecem na zona correta, por firewall-cmd --get-active-zones.

$ firewall-cmd --get-active-zones
docker
  interfaces: docker_gwbridge docker0
internal
  interfaces: vethb6daacd veth0a3a13c veth3922477 veth1fc2c24 veth35f6f77 veth172d461 vethf457e97 vethed46b94 vethc3293eb vethe6c08de vethb1c5fb6 vethd6bcfd8 eth0

No entanto, após alguns minutos (geralmente menos de uma hora), eles passam para internala zona, interrompendo a rede em contêineres.

$ firewall-cmd --get-active-zones
internal
  interfaces: vethb6daacd veth0a3a13c veth3922477 veth1fc2c24 veth35f6f77 veth172d461 vethf457e97 vethed46b94 vethc3293eb vethe6c08de vethb1c5fb6 vethd6bcfd8 eth0 docker_gwbridge docker0 veth5686e56 vetha51060c vethde79c75

A firewall-cmd --reloadcorrige novamente por um tempo.

Essa questãoparecia relevante, mas essas interfaces (se estou interpretando corretamente) não são gerenciadas pelo NetworkManager, então não acho que seja culpa disso.

$ nmcli device
DEVICE           TYPE      STATE                   CONNECTION
eth0             ethernet  connected               eth0
docker0          bridge    connected (externally)  docker0
docker_gwbridge  bridge    connected (externally)  docker_gwbridge
veth5686e56      ethernet  unmanaged               --
vetha51060c      ethernet  unmanaged               --
vethde79c75      ethernet  unmanaged               --
lo               loopback  unmanaged               --

$ ls /etc/sysconfig/network-scripts/
ifcfg-eth0

Não consigo encontrar nada de interessante em /var/log/firewalld. Tenho vários outros nós que teoricamente estão configurados da mesma forma onde esse problema não ocorre.

Não configurei os nós e não sou administrador de sistema, mas estou tentando descobrir! Alguma palavra de sabedoria?

Responder1

Parece que uma tarefa do Chef é a causa disso, com o Chef inexplicavelmente configurado de forma diferente entre servidores funcionando e quebrados.

informação relacionada