私は2つのサーバーをアップグレードしました。Debian 10（バスター）Debian 11（雄牛の目）。それ以来、これ以上オンラインで連絡できなくなりました。いくつかの調査の結果、以下の問題が発見されました。
どちらのシステムもブリッジデバイスで構成されています。明らかに、ブリッジデバイスにMACアドレスを割り当てるDebianアルゴリズムがバージョン10からバージョン11に変更されました。アップグレード後、最初のサーバーのブリッジ デバイスは、2 番目のサーバーのブリッジ デバイスと同じ MAC アドレスを持ちます。、以前はそうではありませんでした。
一つそこに答えがあるブリッジは純粋に内部デバイスなので、ブリッジのMACアドレスは重要ではないと主張します。しかし、これは明らかに間違っています。少なくとも私の場合、両方のコンピュータからのパケットは次に終わりました。ハードウェアソースアドレスはブリッジのMACアドレスであり、両方のシステムのネットワークポートが着信パケットを処理しています。宛先がブリッジのMACアドレスの場合にのみ適用されます。
両方のシステムのMACアドレスが同じであるため、ネットワークが利用できなくなることは完全に論理的で理解できます。
Debian が別のコンピュータ（または同じコンピュータにあっても、私の質問ではありません）にブリッジされたデバイス用に別の MAC アドレスを生成するにはどうすればよいですか。
答え1
インターネットを検索している間、このバグレポートが見つかりました。systemd-udevDebian 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アドレス値を継承します。コンポーネントがsystemdMACアドレスを妨害して設定します。次のコマンドを使用して実際の動作を確認できます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アドレスを固定アドレスで上書きし、指定されたブリッジ名に対して同じ値で2回上書きする方法を確認できます。
別の副作用は、インターフェイスを設定するとき行政アップ、ブリッジ働くしたがって、状態は最初はUNKNOWNの代わりにDOWNになります（DOWNとUNKNOWNに関する動作について言及するSUとSFへの私の答えを参照してください。LinuxはブリッジデバイスのデフォルトMACアドレスをどのように決定しますか？、Macアドレスを強制的に適用すると、Linux ipv6ブリッジアドレスが機能しません。）。とにかく、最初のブリッジポートを接続しても問題はありません。
非干渉ネットワークの名前空間内で同じ実験を実行すると（たとえば、上記のコマンドを2回実行する前に）、毎回異なるランダムアドレスを持つip add netns experiment一般的な動作が表示されます。ip netns exec experiment bash -lsystemd-udevd
これは効果です。システムsystemd（または以前のバージョンのsystemd）を実行していないシステムでは発生しません。提案された修正の1つは、次を使用することです。
# /etc/systemd/network/90-bridge.link [Match] OriginalName=br* [Link] MACAddressPolicy=random
ただし、実際の回避策は、以下に説明するように、この「安定したランダム」値を生成するために関連するファイルを変更するようです。https://wiki.debian.org/MachineId
各マシンに異なる値が必要です。これは、プライマリテンプレートから仮想マシンを複製するときに特に重要です。の関係machine-idと作成方法パッチの実装(かなり重要)の変更:
===今回のパッチ
このパッチは、ほぼすべての仮想デバイスにデフォルトで「安定した」MACを使用することを意味します。ここで、「安定的」とは「安定的」を意味する。コンピュータIDとインターフェイス名をオフにする。
これはタイプのインターフェイスに限定されません。足しかし、生成されるすべてについてランダムMAC住所：typevethなどもmacvlan tuntap影響を受けます。
Debianリンクに記載されている操作を実行した後、同じブリッジ名が異なる「安定したランダム」値を取得していることを確認できます。
rm -f /etc/machine-id /var/lib/dbus/machine-id dbus-uuidgen --ensure=/etc/machine-id dbus-uuidgen --ensure
ip monitor同じブリッジ名に削除して再作成すると、1a：d0：fc：63：c1：71の代わりに32：ee：c8：92：9f：e8という新しいMACアドレスが付与されます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
結論として：
ブリッジMACアドレスが手動で設定されるため、ブリッジは他のMACアドレスを持つことが期待される一般的な永続（物理または仮想マシン）インターフェイスを含むブリッジポートに設定されている他のインターフェイスのMACアドレスの1つを継承しなくなりました。どちらのシステムも同じでmachine-id同じブリッジ名（例br0：）を使用し、これらのブリッジはルーティングに参加します（たとえば、ブリッジにIPアドレスが設定されていますが、それ以外の場合でもブリッジはブリッジ関連のその他のフレームを発行できます）。のフレームは同じソースMACアドレス（ブリッジ）を使用してフレームを送信するため、パスのスイッチが中断される可能性があり、とにかくピアの同じソースMACアドレスを無視します。
答え2
コマンドを使用して、DebianにMACアドレスを複製するように指示できますbridge_hw。
たとえば、私の/etc/network/interfacesファイルは次のようになります。
iface enp2s0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports enp2s0
bridge_hw enp2s0
今、両方とも同じアドレスをenp2s0持っています。br0
$ 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)
答え3
まず、ABの答えは正しい解決策を示しています。同じ問題が発生した場合は、正しい解決策を見つけるためにABの答えに従ってください。
しかし、完全性を期すために代替（はるかに劣った）ソリューションを見せたいです。私は非常にストレスを受けて、それはすぐに正解を得ることを期待していませんでした。だから私はいくつかの変更を与えて一時的に問題を解決しました/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
最後の行が重要です。これにより、オペレーティングシステムに表示されたMACアドレスをブリッジに割り当てることができます。表示されたMACアドレスは、完成した非公開MACアドレス範囲のアドレスです。ブリッジからデバイスを削除または追加しても、MACアドレスが同じままであることを確認しました。
もちろん、ブリッジが同じシステム上にあるかどうかにかかわらず、各ブリッジに異なるMACアドレスを割り当てる必要があります。
繰り返しますが、上記の方法はブリッジMACアドレスの問題のみを解決します。別のコンピュータに同じコンピュータIDがあると、何かが大幅に間違っている可能性があると思います。 ABの回答には、新しいコンピュータIDを作成する方法が記載されており、クイックテストでは、この方法で生成されたすべてのコンピュータIDがこの方法で生成された他のすべてのコンピュータIDと異なることがわかります。