Необычная настройка двух сетевых интерфейсов

ни даже MAC-адреса.

И как тогда эта коробка работает в ethernet'е?

Не знаю относительно работоспособности такой схемы. Исходящий пакет вроде как можно отправить куда угодно, и когда этот пакет вернётся из коробки он может быть отправлен дальше через любой другой интерфейс. А вот сделать, чтобы хост отправил куда-то дальше входящий пакет, предназначенный именно этому хосту, ИМХО, штатными средставами нельзя.

И как тогда эта коробка работает в ethernet'е?

У копеечных свитчей тоже нет MAC-адреса, но это не мешает им работать в ethernet-сети 8). Эта волшебная коробка, например, может работать как «зеркало»: делать что-то страшное со входящими пакетами и затем отправлять их обратно. Теоретически это возможно, но я не знаю как именно такое реализовать.

Простейшее решение, которое пришло мне в голову, выглядит вот так:

Коробка
  eth0
    eth0.0 # это VLANы
    eth0.1

Система
  eth0
  eth1
    eth1.0 # на этот VLAN мы вешаем внешний IP-адрес
    eth1.1

  br0 = eth0 + eth1.1

eth0 подключена к внешней сети, eth1 подключена к «волшебной коробке». Я хочу, чтобы все ethernet-фреймы (именно на уровне ethernet, не IP), перед отправкой во внешнюю сеть

вы хотите странного :) Зачем вам ether-фреймы? хотя..ваше дело..

в бридж и покрутив ebtables?

без инкапсуляциии вряд ли выйдет - завернуть трафик на коробочку ещё возможно, а вот перенаправить трафик от неё уже нет. К примеру если коробка тупо отправляет фреймы обратно, то бридж получит на вход фрейм с собственным mac`ом как отправителя - как-бы у него чего не вскипело

придётся делать некий (впрочем несложный) софт который по nfqueue забирает покет из цепи POSTROUTE, заворачивает его в IP (да-да из одного фрейма получатся 2), отправляет в коробочку. А получаемое из пишет коробочки в raw-сокет eth0.

Как предполагается отличать трафик уже прошедший через коробку от всего остального?

У копеечных свитчей тоже нет MAC-адреса, но это не мешает им работать в ethernet-сети 8).

Попробуйте тогда адресовать пакет этому «копеечному свичу».

Ставьте ваш черный ящик в разрыв, но для это у него должно быть 2 ethernet-интерфейса.

Попробуйте тогда адресовать пакет этому «копеечному свичу».

А зачем? Свитч может просто собирать какую-либо информацию о трафике. Для этого ему MAC-адрес именно в этой сети не нужен. Есть куча разных устройств, которые «делают что-то страшное» с пакетами, но при этом являются полностью невидимыми в сети для других устройств.

Ставьте ваш черный ящик в разрыв, но для это у него должно быть 2 ethernet-интерфейса.

Можно разрулить VLANами, я выше написал.

Да, действительно, я не сообразил.

Трафик, уже прошедший через коробку, пересылать его в eth0 или нет? Не понятно.

Я знаю про свичи и т.д. Просто мне хотелось услышать, что ТС сам думает про этому поводу, может он бы расказал больше про эту коробочку, может на самом деле у неё есть MAC-адрес и с ней можно работать и на ip-уровне и вобще поведать откуда взялась такая странная схема.

И, вроде как, в случае бриджа пришедший широковещательный пакет будет получен и линуксом, а не только волшебной коробочкой.

Из поставленной задачи не совсем ясно, что требуется. Но попробую потелепатить.

В общем, то, что Вы описали и есть самый обыкновенный bridge из двух интерфейсов самой «волшебной коробки» - он как раз и занимается чистым перенаправлением фреймов с одного интерфейса в другой (с поправочкой на динамическую таблицу мак-адресов привязанных к каждому интерфейсу, такой себе роутинг L2 уровня). Потом уже к нему прикрутили ebtables, который умеет фильтровать, проверять и прочие плюшки. Если надо скрыть MAC-адрес вашей коробки - никто не запрещает ей поставить что-то вида 00:00:00:00:00:00 на br0 интерфейс и не ставить IP. Только тогда естественно будут проблемы с удалённым доступом к этой вашей коробке, но это решаемо консолью на самой коробке.

Лучше, конечно спросить у того, кто ставил задачу, но так, по идее у пришедшего из eth1 (с коробки) трафика надо смотреть dst MAC/IP-адреса и в случае совпадения со значениями на eth0 принимать, а при не совпадении пересылать пакет в eth0.

Или можно смотреть src MAC/IP-адреса, и, если они пренадлежат машине с Линуксом, отправлять пакет в eth0, иначе принимать. Но, если коробочка модифицирует эти адреса, то вобще не понятно как что можно отличить.

И, вроде как, в случае бриджа пришедший широковещательный пакет будет получен и линуксом, а не только волшебной коробочкой.

Получен то он будет точно, иначе бридж не сможет работать. А вот как он будет обработан - зависит от настроек. И от того, что именно нужно получить автору темы.

Трафик из коробочки должен возвращаться или нет? Если нет то достаточно зеркалировать трафик на этот интерфейс, это одно или два правила в iptables (или etables, если на втором уровне).

Это какой-то DPI или СОРМ?

Так, пусть у коробки есть MAC-адрес, и она может подменять MAC-адресы подменять. Нужно сделать так, чтобы извне Linux + коробка воспринималось как одно устройство с одним MAC-адресом. И чтобы весь трафик проходил через коробку, как будто она стоит в разрыв цепи.

Тогда прошедший и не прошедший через коробку трафик можно различать по MAC-адресам (коробка MAC-адреса будет подменять)?

Этого ведь можно добиться, просто объединив eth0 и eth1 в бридж?

Если есть MAC, можно попрбовать такую схему.

1. Интерфейсы объединяем в бридж

2. На линуксе оставляем только один маршут через любой ip-адрес и для этого адреса делаем arp-запись с MAC-ом коробки.

3. Через ebtables делаем обработку arp-запросов, чтобы на запросы об ip-адресе линукс машины отдавался MAC-адрес коробки.

4. Коробка каким-то образом должна различать пакеты, идущие от линукса в инет и из инета к линуксу и менять им MAC-адреса.

Не знаю, последний пункт получается самый сложный.

В целом, вариант, предложенный mironov_ivan проще. Если коробка поддерживает VLAN'ы, то за счёт VLAN'ом мы делаем на коробке два, а на Линуксе 3 как-бы интерфейса и уже их выстраиваем в цепочку. Но тут нужна сложная конфигурация коробки.

В любом из предложенных в этом топике вариантов коробке достаётся ethernet-кадр не в точности такой, как если бы он был без eth1 интерфейса на линуксе, либо MAC-другой, либо VLAN-id добавлен, либо кадр завёрнут в ip-пакеты.

И не понятно что будет происходить с широковещательными ethernet-кадрами. Просто одно дело, если у Линукса на eth0 только шлюз для выхода в инет и из широковещательных ожидаем только arp-трафик. А если там полноценный ethernet сегмент, то нужно смотерть, чтобы не возникали дубликаты пакетов.

Когда линукс принимает broadcast на eth0 он должен проигнорировать содержимое пакета и тупо отдать его коробочке, а когда получает этот же пакет с eth1, линукс должен понять, что этот броадкас пакет уже проходил через него и фактически является unicast'ом, то есть предназначен только ему и отправлять его в eth0 не надо.

Ну, а совсем на закуску остаётся вопрос о прозрачности всего этого для софта на Линуксе. Реализовать штатными средствами такую схему, чтобы её не видел ″tcpdump″ или ″ping -r″ не получится.