Всем привет
Задача была такая: организовать форвардинг мультикаста в обход стандартному ядерному. Это я сделал и всё работает как надо за одним исключением, когда надо форвардить пакеты, снимая их с бриджа. Пакеты сами форвардятся нормально, но вот нетфильтр построутинг SNAT для них не отрабатывает... Для остальных входящих интерфейсов всё отрабатывает как надо, а для бриджа нет.
Сэмулировал похожую ситуацию средтсвами ядра, когда пакет роутился с бриджа на нужный интерфейс, вроде норм.

Нетфильтр огромный, кавыряю, но не очень - то приближаюсь к решению, которое может заключается в вызове какой - нибудь функции для skb, а может быть какой - то флаг забыл выставить...

Если кто - нибудь в курсе моей проблемы, подскажите пожалуйста куда копать

Заранее благодарен за помощь

немного продвинулся в своем исследовании...
судя по всему что - то гадится после отработки BRIDGE_FILTER. в случае с мультикастом рассылка идет по всем портам моста + на верх - сетевому уровню... закомментил момент, где мост посылая на другие свои порты, вызывает хуки BRIDGE_FILTER и нетфильтр заработал...

сейчас дошел до того места, где косяк в поиске правила
http://lxr.linux.no/#linux+v3.2.1/net/ipv4...p_tables.c#L310

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


сюда мы попадаем отсюда, значит буду исследовать функции вышестоящие, как выходной интерфейс становится бриджом

такое ощущение, что на бридж фильтре правило для пакета заносится в кеш, а когда мы уже с ip уровня ретранлируем пакеты, то хук нетфильтра дергает из кеша, а не свежепереданные данные sk_buff

да, мост вызывает postrouting для протоколов ip уровня и таким образом создает правило, которое видимо кешироуется, осталось понять, как сбросить это правило
http://lxr.linux.no/#linux+v3.2.1/net/brid...etfilter.c#L847

Проблема (или точнее - особенность) в работе netfilter. Каждому пакету, приходящему в систему на PREROUTE или в EBTABLES назначается, так называемое, "слежение за соединением", то есть сущность, которая сопровождает sk_buff на протяжении всей его жизни, а также остается актуальным по истечению определенного периода времени после уничтожения пакетов идущим по определенному маршруту. Эта связь осуществляется на базе 4 (а для некоторых протоколов более)параметров, по которым однозначно определяется принадлежность пакета к текущему соединению: saddr, daddr, sport, dport для udp протокола
То есть если даже уничтожать связь sk_buff с conntrack, она всё равно будет обнаружена по этим четырем параметрам.

Исходя из вышесказанного, вытекала более существенная проблема флужения на ip уровне, не удавалось бы создавать правила для разных выходных интерфейсов, ибо правило одно на все копии sk_buff.

Я решил (избежал) данную проблему, изменяя порт отправления для копий sk_buff, предназначенных для флужения. Изменеие происходит на основании индексов входного и выходного сетевых интерфейсов. На сколько удачно я подобрал изменение sport, я не знаю, но небольших количествах интерфейсов всё работает как надо.
В случае с бриждом, то это следствие, которое лечится точно таким же способом.

в моем случае изменение sport, надеюсь будет не критичным

хотя решение может быть и более элегантным