Назад | Перейти на главную страницу

Можно ли включить изоляцию портов на мостах Linux?

На большинстве управляемых коммутаторов можно включить изоляцию портов уровня 2. Реализация и терминология различаются от поставщика к поставщику, но, как правило, вы сохраняете один или несколько портов в состоянии Promiscuous (Cisco) или Uplink (HP) по умолчанию и настраиваете другие порты как изолированные (Cisco) или частные (HP). Впоследствии изолированные порты могут общаться только с беспорядочными, но не друг с другом.

Есть ли способ реализовать это с помощью мостов Linux, например. изолировать виртуальные машины друг от друга? Может через ebtables?

По запросу @pQd вот рабочий пример изоляции порта с виртуальными машинами (здесь: на основе Proxmox VE), когда хост является восходящим каналом и все виртуальные машины должны быть изолированы друг от друга. Я использую это для внутренней сервисной сети (DNS, обновления и т. Д.). Мост vmbr1, виртуальные устройства Ethernet vethNNN.1 (где NNN это VID). Если вам нужна только изоляция, этого должно быть достаточно:

ebtables --append FORWARD --logical-in vmbr1 --jump DROP

Если нужно настроить несколько мостов и другие виртуальные машины также должны быть восходящими линиями (здесь: veth100.1 и veth102.1), что-то вроде этого более уместно (непроверено):

for br in $(seq 0 1); do
    br=vmbr$br
    ebtables --new-chain $br
    ebtables --policy $br DROP
    ebtables --append FORWARD --logical-in $br --jump $br
done
for if in 100.1 102.1; do
    br=vmbr$(echo $if | cut -d. -f2)
    if=veth$if
    ebtables --append $br --in-if $if
    ebtables --append $br --out-if $if
done

Если хост не должен быть восходящим каналом, это должно сработать (хотя я тоже не пробовал):

ebtables --append INPUT --logical-in vmbr1 --jump vmbr1
ebtables --append OUTPUT --logical-out vmbr1 --jump vmbr1

вы можете попробовать использовать ebtables и создать собственные правила, включающие порт моста ввода / вывода.

у меня нет сервера с мостом под рукой, но я бы сделал что-то вроде этого:

ebtables -P FORWARD DROP
ebtables -F FORWARD
ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow from uplink to any ports
ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow from any ports to uplink

Поскольку этот вопрос был задан (в 2012 г.), стал доступен более новый метод (в 2018 г.) с ядром Linux> = 4.18 и достаточно недавно связанным iproute2 инструменты: изоляция порта моста.

Это описано в KernelNewbies для Linux 4.18:

  • мост: добавить поддержку изоляции портов. Изолированные порты не могут обмениваться данными между собой, но они все равно могут обмениваться данными с неизолированными портами. совершить

Если интерфейс (обычно называется tapX для ВМ или vethX для контейнера) был установлен в качестве порта моста моста с именем мост0 как это:

# ip link set dev tap0 master bridge0

можно установить его изолированным с помощью bridge команда вроде этой:

# bridge link set dev tap0 isolated on

Это не будет иметь видимого эффекта, пока не будет изолирован хотя бы второй порт того же моста:

# bridge link set dev tap1 isolated on

Теперь порты моста tap0 и tap1 не сможет отправлять или получать какие-либо пакеты на другой порт или из него, но по-прежнему будет нормально взаимодействовать с любым другим портом моста. Вы можете изолировать все порты, кроме одного, который используется по умолчанию в роли беспорядочного / восходящего порта.

Ноты:

  • как описано в коммите, это для каждого порта. Если на изолированном порту моста имеется несколько VLAN, это затрагивает все,
  • неясно, является ли собственный интерфейс моста (мост0 здесь) может быть изолирован (даже с правильным синтаксисом: добавление self ключевое слово, когда устройство - это само имя моста),
  • Все новые расширенные функции доступны через (RT) netlink с ip link и bridge Команды не имеют эквивалента в более старом API ioctl, поэтому brctl нельзя использовать для этого.

Это может быть более простой способ изолировать виртуальные машины / других клиентов друг от друга, при этом позволяя им взаимодействовать с вышестоящим шлюзом - используя IP-адреса (IPv4, здесь).

например, виртуальные машины включены 192.168.12.x/24, шлюз находится в 192.168.12.254. Первые 2 линии разрешают каждое направление к / от шлюза. Третья строка блокирует весь остальной трафик IPv4 между другими хостами в подсети:

ebtables -A FORWARD -p IPv4 --ip-src 192.168.12.0/24 --ip-dst 192.168.12.254 -j ACCEPT ebtables -A FORWARD -p IPv4 --ip-src 192.168.12.254 --ip-dst 192.168.12.0/24 -j ACCEPT ebtables -A FORWARD -p IPv4 --ip-src 192.168.12.0/24 --ip-dst 192.168.12.0/24 -j DROP

Я не придумал, как также заблокировать «все остальное» (трафик не IPv4) между этими клиентами, потому что я думаю, вам, вероятно, все равно придется разрешить некоторые вещи, например, ARP?