방금 서버 2개를 업그레이드했습니다.데비안 10(버스터) 에데비안 11(황소의 눈). 그 이후에는 더 이상 온라인으로 연락할 수 없었습니다. 몇 가지 조사 결과 다음과 같은 문제가 발견되었습니다.
두 시스템 모두 브리지 장치로 구성되어 있습니다. 분명히 브리지 장치에 MAC 주소를 할당하는 데비안 알고리즘이 버전 10에서 버전 11로 변경되었습니다.업그레이드 후 첫 번째 서버의 브리지 장치는 두 번째 서버의 브리지 장치와 동일한 MAC 주소를 갖습니다., 이전에는 그렇지 않았습니다.
하나거기에 답이 있다브리지가 순전히 내부 장치이므로 브리지의 MAC 주소가 중요하지 않다고 주장합니다. 그러나 이는 분명히 잘못된 것입니다. 적어도 내 경우에는 두 컴퓨터의 패킷이 다음으로 끝났습니다.하드웨어 소스 주소는 브리지의 MAC 주소이며,두 시스템의 네트워크 포트가 들어오는 패킷을 처리하고 있습니다.목적지가 브리지의 MAC 주소인 경우에만 해당됩니다.
두 시스템의 MAC 주소가 동일하기 때문에 네트워크를 사용할 수 없게 되는 것은 완전히 논리적이고 이해할 수 있습니다.
데비안이 다른 컴퓨터(또는 같은 컴퓨터에 있더라도 내 질문은 아님)에 브리지된 장치에 대해 다른 MAC 주소를 생성하도록 하려면 어떻게 해야 합니까?
답변1
인터넷을 검색하던 중 이런 버그 보고서를 발견했습니다.systemd-udev데비안 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 주소를 고정 주소로 덮어쓰고 주어진 브리지 이름에 대해 동일한 값으로 두 번 덮어쓰는 방법을 확인할 수 있습니다.
또 다른 부작용은 인터페이스를 설정할 때행정업, 브릿지작동하다따라서 상태는 처음에는 UNKNOWN 대신 DOWN이 됩니다(DOWN 및 UNKNOWN에 관한 동작을 언급하는 SU 및 SF에 대한 내 답변 참조:Linux는 브리지 장치의 기본 MAC 주소를 어떻게 결정합니까?,Mac 주소를 강제로 적용할 때 Linux ipv6 브리지 주소가 작동하지 않습니다.). 어쨌든 첫 번째 브리지 포트를 연결하면 더 이상 문제가 되지 않습니다.
비간섭 네트워크 네임스페이스 내에서 동일한 실험을 실행하면(예: 위 명령을 두 번 실행하기 전) 매번 다른 임의 주소를 갖는 ip add netns experiment일반적인 동작을 보여줍니다.ip netns exec experiment bash -lsystemd-udevd
이건 효과야체계systemd(또는 이전 버전의 systemd)를 실행하지 않는 시스템에서는 발생하지 않습니다. 제안된 수정 사항 중 하나는 다음을 사용하는 것입니다.
# /etc/systemd/network/90-bridge.link [Match] OriginalName=br* [Link] MACAddressPolicy=random
그러나 실제 해결 방법은 아래에 설명된 대로 이 "안정적인 임의" 값을 생성하는 데 관련된 파일을 변경하는 것 같습니다.https://wiki.debian.org/MachineId
각 기계마다 다른 값을 가져야 합니다. 이는 기본 템플릿에서 가상 머신을 복제할 때 특히 중요합니다. 사이의 관계 machine-id및 생성 방법패치 구현(상당히 중요한) 변경 사항:
=== 이번 패치
이 패치는 거의 모든 가상 장치에 대해 기본적으로 "안정적인" MAC을 사용한다는 의미입니다. 여기서 "안정적"은 "안정적"을 의미합니다.컴퓨터 ID 및 인터페이스 이름 끄기.
또한언급하다이것은 가질 것이다영향, 그러나 이는 무시되었습니다.
이는 유형의 인터페이스에만 국한되지 않습니다.다리그러나 생성되는 모든 것에 대해무작위 MAC주소: type veth등도 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 주소 중 하나를 더 이상 상속하지 않습니다. 두 시스템 모두 동일 machine-id하고 동일한 브리지 이름(예: br0)을 사용하며 이러한 브리지는 라우팅에 참여합니다(예: 브리지에 IP 주소가 구성되어 있지만 그렇지 않더라도 브리지는 브리지 관련 기타 프레임을 발행할 수 있음) 네트워크 동일한 LAN에 있는 프레임은 동일한 소스 MAC 주소(브리지)를 사용하여 프레임을 전송하므로 경로의 스위치가 중단될 수 있으며 어쨌든 피어의 동일한 소스 MAC 주소를 무시합니다.
답변2
명령을 사용하여 데비안에게 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와 다르다는 것을 알 수 있습니다.