Мы старый мир разрушим. Начнём с поведения сети в GNU/Linux!

Хотел вчера я iperf’ом померить полосу. Хосты дома у меня прибиты и в прямой, и в обратной dns зонах, так что я ввёл адрес и… оно мне написало, что до хоста достучатся не может. А он работает. Но с другим адресом! Сначала подумал, что это сбой в udhcpd (да, я использую его и unbound, вместо dnsmasq), но оказалось, что просто изменился MAC-адрес моей машины. Удивительное рядом…

Компьютер подключается к сети медью, через intel’овскую десктопную карту. Она включена в мостовой интерфейс, соответственно мостовой интерфейс использует её MAC-адрес для общения с сетью. Но просмотр вывода ‘ip link’ показал, что интерфейс br0 имеет отличный от интерфейса vlan2 (да, дома я использую vlan’ы) MAC-адрес. Тут я, конечно, выпал в осадок. Так как 10 лет linux bridge копировал MAC включённого в него интерфейса, а теперь, внезапно, нет!

И ведь я даже догадываюсь, почему оно так теперь нынче выглядит: мост копировал на себя адрес интерфейса, и если интерфейсов более одного, то выбирал он адрес с наименьшим значением. И он таки мог применить на себя, например, адрес интерфейса виртуальной машины (начинающийся с ’52:54:00:’), вместо адреса реального сетевого интерфейса (начинающегося с ‘f8:’). То есть на время смены MAC’а, в момент включения/выключения виртуальной машины, хост мог сидеть без сети. Этого можно было избежать, принудительно добавив интерфейс-заглушку в бридж… Но это же что-то делать надо! А теперь нате — вот вам фикс, который меняет стандартное поведение. Пожалуйста. Без предупреждения. «Благо для всех и для каждого», ога-ога…

И теперь, чтобы парировать изменение поведения linux bridge, приходится совсем отказаться от использования helper’а из состава bridge-utils (да, у меня Debian):

aliech@arcturus:~$ cat /etc/network/interfaces.d/br0
auto br0
iface br0 inet dhcp
	#bridge_ports	vlan2									# параметр helper'а из bridge-utils, более не нужно
	#bridge_stp	off									# параметр helper'а из bridge-utils, более не нужно
	#bridge_fd	0									# параметр helper'а из bridge-utils, более не нужно
	#bridge_maxwait	0									# параметр helper'а из bridge-utils, более не нужно
	pre-up		ip link show enp1s0 | grep -q DOWN && ip link set enp1s0 up || true	# поднимаем физический интерфейс, если не поднят
	pre-up		ip link add link enp1s0 name vlan2 type vlan id 2 gvrp off		# добавляем vlan (только если нужен)
	pre-up		ip link set vlan2 up							# поднимаем vlan (только если нужен)
	pre-up		ip link add name br0 type bridge					# добавляем мост
	pre-up		ip link set vlan2 master br0						# добавляем в мост сетевой интерфейс
	pre-up		ip link set dev br0 address xx:xx:xx:xx:xx:xx				# ставим на мост MAC-адрес сетевого интерфейса
	post-down	ip link set vlan2 nomaster						# удаляем сетевой интерфейс из моста
	post-down	ip link delete br0 type bridge						# удаляем мост
	post-down	ip link set vlan2 down							# гасим vlan (если создавали vlan)
	post-down	ip link del vlan2							# удаляем vlan (если создавали vlan)

Вот смотрите: vlan я уже давно добавляю руками, так как у helper’а из состава пакета vlan нет параметров, касающихся gvrp. Теперь руками и мостом управляю. И, в итоге, получается портянка в лучших традициях Slackware. Может пора мигрировать? Меня разве скрипты и массовый make config/install/uninstall может смутить? Ну да, uninstall не у всех программ в Makefile прописан. Ну так скрипт напишу, который мне на базе inortify, например, отследит действия make install и откатит их. Делов то…