Início / unix / Perguntas / 719379
Accepted
Binarus
Asked: 2022-10-02 01:38:16 +0800 CST

Como posso fazer o Linux gerar diferentes endereços MAC para diferentes dispositivos de ponte que estão em diferentes PCs?

  • 772

Acabei de atualizar dois servidores do Debian 10 (Buster) para o Debian 11 (Bullseye). Depois, não consegui mais alcançar nenhum deles pela rede. Depois de alguma investigação, o seguinte problema acabou:

Ambas as máquinas têm um dispositivo de ponte configurado. Obviamente, o algoritmo que o Debian usa para atribuir endereços MAC aos dispositivos de ponte mudou da versão 10 para 11. Após a atualização, o dispositivo de ponte no primeiro servidor tinha o mesmo endereço MAC que o dispositivo de ponte no segundo servidor , o que com certeza não foi o caso antes.

Uma das respostas afirma que uma ponte é um dispositivo puramente interno e que, portanto, o endereço MAC de uma ponte não importa. No entanto, isso é obviamente errado. Pelo menos no meu caso, os pacotes de ambas as máquinas estavam saindo com o endereço de origem do hardware sendo o endereço MAC da ponte, e as portas de rede em ambas as máquinas estavam processando os pacotes de entrada apenas se fossem destinados ao endereço MAC da ponte.

Como esse endereço MAC era o mesmo em ambas as máquinas, a rede ficou inutilizável, o que é completamente lógico e compreensível.

Como posso fazer o Debian gerar endereços MAC diferentes para dispositivos de ponte que estão em máquinas diferentes (ou mesmo na mesma máquina, mas esse não é o meu problema)?

debian bridge

3 respostas

  1. Best Answer

    Navegando na Internet, encontrei este relatório de bug no systemd-udev relacionado às pontes do Debian 11: systemd-udev interfere nos endereços MAC das interfaces que não deveria fazer #21185 :

    ash.in.ffho.net:~# for n in 0 1 2 3; do ip l add br$n type bridge; done
ash.in.ffho.net:~# ip -br l

br0              DOWN           d2:9e:b3:32:53:42 <BROADCAST,MULTICAST> 
br1              DOWN           e2:00:44:2c:5b:70 <BROADCAST,MULTICAST> 
br2              DOWN           0e:99:b7:42:f0:25 <BROADCAST,MULTICAST> 
br3              DOWN           a6:3f:5f:b5:9a:d6 <BROADCAST,MULTICAST> 
ash.in.ffho.net:~# for n in 0 1 2 3; do ip link del br${n}; done
ash.in.ffho.net:~# for n in 0 1 2 3; do ip l add br$n type bridge; done
ash.in.ffho.net:~# ip -br l

br0              DOWN           d2:9e:b3:32:53:42 <BROADCAST,MULTICAST> 
br1              DOWN           e2:00:44:2c:5b:70 <BROADCAST,MULTICAST> 
br2              DOWN           0e:99:b7:42:f0:25 <BROADCAST,MULTICAST> 
br3              DOWN           a6:3f:5f:b5:9a:d6 <BROADCAST,MULTICAST>

    Como você pode ver, as pontes foram criadas com comandos de baixo nível, mas sempre herdam o mesmo valor de endereço MAC: um systemdcomponente interfere e define o endereço MAC. Pode-se ver isso em ação usando ip monitor link:

    22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 0a:ae:c3:0d:ec:68 brd ff:ff:ff:ff:ff:ff
22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff
Deleted 22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff
23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 4e:e9:11:dd:a5:aa brd ff:ff:ff:ff:ff:ff
23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff

    Você pode ver como o endereço MAC inicialmente aleatório é substituído por um fixo, duas vezes para o mesmo valor para um determinado nome de ponte.

    Um outro efeito colateral é que quando a interface é configurada administrativamente UP, o status operacional da ponte se torna DOWN em vez de UNKNOWN inicialmente por causa disso (veja essas minhas respostas em SU e SF mencionando comportamentos sobre DOWN e UNKNOWN: Como o Linux determina o MAC padrão endereço de um dispositivo de ponte? , o endereço de ponte linux ipv6 não funciona quando o endereço mac é forçado ). De qualquer forma, isso não importa mais uma vez que sua primeira porta de ponte esteja conectada.

    Fazer o mesmo experimento dentro de um namespace de rede (por exemplo: ip add netns experimente ip netns exec experiment bash -lantes de executar os comandos acima duas vezes) onde systemd-udevdnão interfere mostrará o comportamento usual de ter endereços aleatórios diferentes a cada vez.

    Este é um efeito do ecossistema systemd e não acontece em sistemas que não executam o systemd (ou versões mais antigas do systemd). Uma correção proposta é usar:

    # /etc/systemd/network/90-bridge.link
[Match]
OriginalName=br*

[Link]
MACAddressPolicy=random

    mas parece que a correção real é alterar o arquivo que participa da geração desse valor "stable random", conforme descrito lá: https://wiki.debian.org/MachineId

    Cada máquina deve ter um valor diferente. Isso é especialmente importante para VMs clonadas de um modelo base. A relação entre machine-ide a maneira como o endereço MAC "estável" da ponte é gerado é mencionada no patch que implementou a mudança (bastante quebra) :

    === Este patch

    Este patch significa que definiremos um MAC "estável" para praticamente qualquer dispositivo virtual por padrão, onde "estável" significa que o ID da máquina e o nome da interface foram excluídos .

    Também foi mencionado que isso teria impactos , mas isso foi ignorado.

    Isso não se limita a interfaces do tipo bridge, mas a qualquer interface que gere um endereço MAC aleatório : por exemplo, os tipos veth, macvlan tuntaptambém são afetados.

    Eu pude verificar que o mesmo nome de bridge obteria um valor "stable random" diferente depois de fazer as operações descritas no link do Debian:

    rm -f /etc/machine-id /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure

    dando agora no anterior ip monitorum novo endereço MAC para o mesmo nome da ponte: 32:ee:c8:92:9f:e8 em vez de 1a:d0:fc:63:c1:71 ao excluir e recriar brtest0.

    Deleted 23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff
24: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether da:72:b6:63:23:e5 brd ff:ff:ff:ff:ff:ff
24: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 32:ee:c8:92:9f:e8 brd ff:ff:ff:ff:ff:ff

    Conclusão:

    Como o endereço MAC da ponte agora é definido manualmente, a ponte não herdará mais um dos endereços MAC de outras interfaces definidas como portas de ponte, incluindo as interfaces permanentes usuais (físicas ou VMs) que devem ter um endereço MAC diferente. Dois sistemas usando o mesmo machine-ide o mesmo nome de ponte (ex: br0) com tal ponte participando do roteamento (ou seja: há um endereço IP configurado na ponte, mas mesmo que não a ponte possa emitir outros quadros relacionados à ponte dependendo de suas configurações) na mesma LAN emitirá quadros com o mesmo endereço MAC de origem (pontes), possivelmente interrompendo os switches no caminho e de qualquer maneira ignorando esse mesmo endereço MAC de origem do peer.

    • 6

  2. Você pode dizer ao Debian para clonar o endereço MAC com uma bridge_hwdiretiva.

    ex: meu /etc/network/interfacesarquivo:

    iface enp2s0 inet manual

auto br0
iface br0 inet dhcp
  bridge_ports enp2s0
  bridge_hw enp2s0

    Agora ambos enp2s0e br0têm o mesmo endereço.

    $ sudo dmesg | grep 18:d6
[    2.660733] r8169 0000:02:00.0 eth0: RTL8168e/8111e, 18:d6:c7:05:89:07, XID 2c2, IRQ 26

$ ifconfig enp2s0 | grep ether ; ifconfig br0 | grep Description:   Debian GNU/Linux 11 (bullseye)
        ether 18:d6:c7:05:89:07  txqueuelen 1000  (Ethernet)
        ether 18:d6:c7:05:89:07  txqueuelen 1000  (Ethernet)
    • 4

  3. Em primeiro lugar, a resposta de AB mostra a solução correta. Se você está tendo o mesmo problema, siga a resposta de AB para resolvê-lo da maneira correta.

    No entanto, por uma questão de completude, gostaria de mostrar uma solução alternativa (muito inferior). Eu estava sob pressão e não esperava uma resposta correta tão rápido. Portanto, resolvi temporariamente o problema por conta própria, alterando ligeiramente /etc/network/interfaces:

    auto br0
iface br0 inet static
        bridge_ports eno1
        address 192.168.20.11
        netmask 255.255.255.0
        broadcast 192.168.20.255
        gateway 192.168.20.250    
        hwaddress ether 02:01:01:01:11:01

    A última linha é o ponto chave. Faz com que o SO atribua o endereço MAC indicado à ponte. O endereço MAC mostrado é um endereço do intervalo de endereços MAC privado semi-oficial. Verifiquei que esse endereço MAC permanece o mesmo quando você remove ou adiciona dispositivos à ponte.

    Obviamente, você deve fornecer a cada ponte um endereço MAC diferente, independentemente de as pontes estarem ou não na mesma máquina.

    Novamente, o método acima apenas resolve o problema do endereço MAC da ponte. Acredito que muito mais pode dar muito errado se houver as mesmas IDs de máquina em máquinas diferentes. A resposta de AB menciona como criar uma nova ID de máquina e um teste rápido mostrou que cada ID de máquina criada dessa maneira difere de todas as outras IDs de máquina criadas dessa maneira.

    • 2

relate perguntas