Утечка трафика в Linux bridge от выключенных виртуальных машин.

Вопрос или проблема

У меня настроен linux-мост (br0) с использованием netplan следующим образом:

  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
  bridges:
    probr:
      interfaces:
        - eno1
      macaddress: ab:cd:ef:01:02:03
      addresses:
        - 51.x.y.z/24
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1
      parameters:
        stp: false
        forward-delay: 0
      dhcp4: no
      dhcp6: no
      routes:
        - to: 0.0.0.0/0
          via: 55.x.y.254
        - to: 55.x.y.z/28
          scope: link

Я использую libvirt virt-install с аргументом сети: virt-install ... --network type=bridge,source=br0,model=virtio,filterref=clean-traffic,mac=00:11:22:33:44:55

Сеть работает как ожидалось, но я заметил, что если у меня есть несколько ВМ, трафик, предназначенный для ВМ, которая выключена, будет направлен на все работающие ВМ. Это приведет к утечке информации о соединениях. Есть ли способ настроить мост, чтобы этого не происходило? Возможно, с помощью ebtables? Я заметил, что следующая команда ebtables работает, но я ищу что-то более общее, так как не знаю имя интерфейса заранее (vnet1): ebtables -A FORWARD -p IPv4 --ip-destination 55.x.y.z -o ! vnet1 -j DROP Фильтрация по MAC не сработает, так как IP и MAC принадлежат выключенной ВМ, но мост по каким-то причинам все равно решает его вещать.

Это поведение по умолчанию для linux-моста. Если пакет приходит и мост не знает, на каком порту существует MAC-адрес назначения, он отправляет пакет на каждый порт (кроме порта, с которого пришел пакет). Таким образом мост узнает порт/MAC-сопоставление. Идея заключается в том, что когда пакет пересылается везде, то если получатель существует за одним из портов, он ответит и тогда мост узнает, на какой порт пересылать пакеты с таким MAC впредь.

Я видел это решенным с openvswitch, это программируемый мост, где можно точно настроить поведение обучения MAC и решить эту проблему. Я бы не рекомендовал это решение, потому что оно сильно отличается от iptables и вы потратите много времени.

Другой подход заключался бы в использовании Openstack. Это сложная система, но ее сетевые плагины (что бы они ни использовали внутри) должны решить эту проблему. Я не проверял каждый сетевой плагин, чтобы с уверенностью сказать, что все они это решают, но я читал код для networking-ovn, и он действительно исправляет проблему.

Ответ или решение

Теория:

Проблема, с которой вы столкнулись, относится к базовому поведению Linux моста. Мосты по умолчанию действуют как простые сетевые коммутаторы (switches) уровня 2 OSI, и одно из их ключевых свойств — это обучение MAC-адресам. Когда на мост поступает пакет, он ищет MAC-адрес назначения в своей таблице обучения. Если адрес отсутствует, мост отправляет (флудит) пакет на все подключенные порты, кроме того, с которого он пришёл. Это позволяет мосту определить соответствие между MAC-адресом и портом, когда устройство, которому адресован пакет, ответит.

Пример:

У вас настроен Linux мост br0 с помощью netplan и используется либвирт (libvirt) для создания виртуальных машин с сетевыми интерфейсами, подключёнными к этому мосту. При выключении одной из ВМ трафик, адресованный ей, начинает флудиться на все остальные ВМ, что приводит к утечке информации. Это происходит, потому что отключенное устройство более не отвечает, и мост теряет сведения о соответствии его MAC-адреса какому-либо порту.

Применение:

Использование ebtables: Как вы отметили, использование ebtables может помочь сконфигурировать правило фильтрации трафика. Однако ваша текущая конфигурация требует знания интерфейса (например, vnet1). Для более общей настройки можно автоматизировать процесс получения имён интерфейсов или использовать динамические правила, которые отключают форвардинг ко всем неизвестным MAC-адресам. Например, ebtables можно интегрировать со скриптами, которые отслеживают состояние ВМ и применяют соответствующие правила.
Переход на Open vSwitch (OVS): Узконастроенный, более мощный аналог Linux моста, поддерживающий обширные настройки и вреде MAC обучения. Это требует определённого времени на изучение, так как OVS имеет интерфейс и функциональные возможности, отличающиеся от iptables/ebtables, но предоставляет более точное управление уровня 2.
Интеграция с OpenStack: OpenStack с его продвинутыми сетевыми плагинами, такими как networking-ovn, может решить вашу проблему, так как имеет более сложные механизмы управления сетью и способностью настраивать MAC обучение. Но это сложное решение и требует значительных усилий на развёртывание.

Рекомендации: Если имеющиеся навыки позволяют, попробуйте использовать Open vSwitch для замены Linux моста. Это обеспечит более гибкое и безопасное управление сетевым трафиком виртуальных машин. В противном случае, автоматизация ebtables станет временным решением, предотвращающим флуд неизвестных пакетов на ВМ, пока вы ищете более долгосрочные решения.