如何讓 Linux 為不同 PC 上的不同橋接設備生成不同的 MAC 地址？
我剛剛將兩台伺服器從 Debian 10 (Buster) 升級到 Debian 11 (Bullseye)。之後，我再也無法通過網路聯繫到他們中的任何一個。經過一番調查，發現了以下問題：
兩台機器都配置了橋接設備。顯然，Debian 為橋接設備分配 MAC 地址的算法已經從 10 版本更改為 11 版本。升級後，第一台伺服器上的橋接設備與第二台伺服器上的橋接設備具有相同的 MAC 地址，這可以肯定以前不是這樣。
那裡的答案之一聲稱網橋是純粹的內部設備，因此網橋的 MAC 地址無關緊要。然而，這顯然是錯誤的。至少在我的情況下，來自兩台機器的數據包都是以硬體源地址作為網橋的 MAC 地址的，並且兩台機器上的網路埠只有在它們的目的地是網橋的 MAC 地址時才處理傳入的數據包。
由於兩台機器上的 MAC 地址相同，因此網路變得無法使用，這是完全合乎邏輯且可以理解的。
如何讓 Debian 為不同機器上的網橋設備生成不同的 MAC 地址（甚至在同一台機器上，但這不是我的問題）？
在 Internet 中瀏覽時，我在systemd-udev上發現了這個與 Debian 11 橋相關的錯誤報告： systemd-udev 干擾了它不應該執行的介面的 MAC 地址 #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>如您所見，網橋是使用低級命令創建的，但它們始終繼承相同的 MAC 地址值：
systemd組件會干擾並設置 MAC 地址。可以使用以下方法看到這一點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您可以看到最初隨機的 MAC 地址是如何被覆蓋為固定地址的，對於給定的網橋名稱，它是相同值的兩倍。
另一個副作用是，當介面設置為UP時，網橋執行狀態最初變為 DOWN 而不是 UNKNOWN （請參閱我在 SU 和 SF 上的這些答案，提到有關 DOWN 和 UNKNOWN 的行為：Linux 如何確定預設 MAC網橋設備的地址？，強制mac地址時linux ipv6網橋地址不起作用）。無論如何，一旦連接了它的第一個橋接埠，這不再重要了。
在不干擾的網路命名空間內（例如：在兩次執行上述命令之前）進行
ip add netns experiment相同的實驗將顯示每次具有不同隨機地址的通常行為。ip netns exec experiment bash -l``systemd-udevd這是systemd生態系統的影響，不會發生在未執行 systemd 的系統（或舊版本的 systemd）上。一種建議的解決方法是使用：
# /etc/systemd/network/90-bridge.link [Match] OriginalName=br* [Link] MACAddressPolicy=random但似乎真正的解決方法是更改參與生成此“穩定隨機”值的文件，如下所述：https ://wiki.debian.org/MachineId
每台機器都應該有不同的值。這對於從基本模板複製的 VM 尤其重要。在實施了（相當破壞性的）更改的更新檔中
machine-id提到了橋“穩定”MAC地址之間的關係和生成方式：=== 這個更新檔
這個更新檔意味著我們將為幾乎任何虛擬設備預設設置一個“穩定”的 MAC，其中“穩定”意味著關閉 machine-id 和介面名稱。
這不僅限於bridge類型的介面，還包括任何會生成隨機 MAC地址的介面：例如 types
veth，macvlantuntap也會受到影響。在執行 Debian 連結中描述的操作後，我可以驗證相同的網橋名稱是否會獲得不同的“穩定隨機”值：
rm -f /etc/machine-id /var/lib/dbus/machine-id dbus-uuidgen --ensure=/etc/machine-id dbus-uuidgen --ensure現在在以前
ip monitor為相同的網橋名稱提供一個新的 MAC 地址： 32:ee:c8:92:9f:e8 在刪除和重新創建時而不是 1a:d0:fc:63:c1:71brtest0。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結論：
由於現在手動設置了網橋 MAC 地址，因此網橋將不再繼承設置為網橋埠的其他介面的 MAC 地址之一，包括通常的永久（物理或虛擬機）介面，這些介面預計每個介面都有不同的 MAC 地址。兩個系統使用相同
machine-id且相同的網橋名稱（例如：）br0，並且此類網橋參與路由（即：網橋上配置了 IP 地址，但即使沒有，網橋也可以根據其設置發出與橋接相關的其他幀）在同一個 LAN 上將發出具有相同源 MAC 地址（網橋）的幀，可能會破壞路徑中的交換機，並且無論如何都會忽略來自對等方的相同源 MAC 地址。