проблемы arp с прозрачным мостом на Linux

Я пытался защитить свои виртуальные машины на моем esx сервере путем помещения их позади прозрачного моста с 2 интерфейсами, один впереди, один сзади.

Мое намерение состоит в том, чтобы положить все правила брандмауэра на одно место (вместо на каждом виртуальном сервере).

Я использовал в качестве моста пустую новую виртуальную машину на основе дуги Linux (но я подозреваю, что это не имеет значения, какой бренд Linux это).

То, что я имею, является 2 виртуальными switchs (таким образом, две Виртуальных сети, VN_front и VN_back), каждый с 2 типами портов (переключил/разделил или promiscious/where, машина видит все пакеты).

На моей вычислительной машине промежуточного звена я настроил 2 виртуальных NIC, один на VN_front, один на VN_back, обоих в promisc режиме.

Я создал мост br0 с обоими NIC в нем:

brctl addbr br0
brctl stp br0 off
brctl addif br0 front_if
brctl addif br0 back_if

Затем поднятый их:

ifconfig front_if 0.0.0.0 promisc
ifconfig back_if 0.0.0.0 promisc
ifconfig br0 0.0.0.0

(Я использую promisc режим, потому что я не уверен, что могу обойтись без, думая, что, возможно, пакеты не достигают NICs),

Затем я взял один из своего виртуального сервера, находящегося на VN_front, и включил его к VN_back вместо этого (это - изящный вариант использования, я думаю о, способность переместить мои серверы только путем изменения VN, они включены, ничего не изменяя в конфигурации).

Затем я изучил макинтоши, "замеченные" моим безадресным использованием моста brctl showmacs br0 и это действительно показывало мой сервер с обеих сторон:

Я получаю что-то, что похоже на это:

port no mac addr                is local?       ageing timer
  2     00:0c:29:e1:54:75       no                 9.27
  1     00:0c:29:fd:86:0c       no                 9.27
  2     00:50:56:90:05:86       no                73.38
  1     00:50:56:90:05:88       no                 0.10
  2     00:50:56:90:05:8b       yes                0.00  << FRONT VN
  1     00:50:56:90:05:8c       yes                0.00  << BACK  VN
  2     00:50:56:90:19:18       no                13.55
  2     00:50:56:90:3c:cf       no                13.57

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

Я подозреваю некоторую ужасную вещь, происходящую в мире ARP... :-/

Если я проверяю с помощью ping-запросов с переднего виртуального сервера на задний виртуальный сервер, я могу только видеть заднюю машину, если та задняя машина проверяет с помощью ping-запросов что-то в передней стороне. Как только я останавливаю ping от задней машины, ping от передней машины прекращает проходить...

Я заметил что, если задняя машина проверяет с помощью ping-запросов, то ее порт на мосту является корректным...

Я попытался играть с arp_ переключателем/proc/sys, но без ясного эффекта на конечный результат.../proc/sys/net/ipv4/ip_forward, кажется, не имеет применение при использовании моста (кажется, что это все заботилось о brctl),/proc/sys/net/ipv4/conf//arp_, кажется, не изменяются очень или... (попробовал arp_announce к 2 или 8 - как предложенный в другом месте - и arp_ignore к 0 или 1),

Все примеры, которые я видел, имеют другую подсеть с обеих сторон как 10.0.1.0/24 и 10.0.2.0/24... В моем случае я хочу 10.0.1.0/24 на обеих сторонах (точно так же, как прозрачный переключатель - кроме он - скрытый fw).

Превращение STP вкл\выкл, кажется, не оказывает влияния на мою проблему.

Это как будто arp пакеты где, проходя через мост, повреждая другую сторону с ложными данными... Я попытался использовать -arp в каждом интерфейсе, br0, передняя сторона, назад... это повреждает вещь в целом... Я подозреваю, что это имеет некоторое отношение к обеим сторонам, находящимся на той же подсети...

Я думал о помещении всей моей машины позади fw, чтобы иметь весь одинаковый подсеть сзади..., но я застреваю со шлюзом своего поставщика, стоящим в передней стороне с частью моей подсети (на самом деле 3 устройства для маршрутизации целой подсети), таким образом, у меня всегда будет дюйм/с от той же подсети на обеих сторонах, независимо от того, что я делаю... (Я использую закрепленного переднего дюйм/с на своей делегированной подсети).

Я в замешательстве... - _ -'' спасибо за Вашу справку.

(Поскольку кто-либо попробовал что-то вроде этого? из ESXI?)

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

Я знаю, что мог использовать что-то как фырканье, но оно обращается к некоторому совершенно другому виду проблем совершенно другим способом...),