Какое последнее ядро (я так понимаю, что только pf-kernel) поддерживало l7-filter kernelspace?

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

Есть подозрение, что это то, что ты ищешь: https://github.com/damentz/zen-kernel/commits/3.7/layer7

В любом случае, дай, пожалуйста, ссылку на современный юзерспейсный модуль.

По поводу юзерспейсного модуля не знаю, мне кажется, что его забросили тоже.

Однако существует библиотека ndpi ( http://www.ntop.org/products/ndpi/ ) (и её форк opendpi https://github.com/thomasbhatia/OpenDPI, который был на сайте http://www.opendpi.org/ , но теперь стал частью проприетарщины и лавочка прикрылась ).

Смысл этой библиотеке в вычленении из потока данных нужных протоколов. Но она также поддерживает проколы более высокого уровня (может определять трафик разных апдейтеров, айтюнза, андроид-маркета, игр и прочего говна, типа фейсбука. может определять домены для https-соединений (через просмотр сертификата) ).

Данная библиотека может быть «обернута» и использоваться в качестве netfilter модуля ядра, что используется в проектах https://github.com/ewildgoose/ndpi-netfilter (более новый, форк более старого) и более старый ( https://github.com/thomasbhatia/opendpi-netfilter ).

Проблема заключается в том, что для ndpi-netfilter требуется ndpi-1.3, который автор не выложил в гит, а в сети только 1.4 есть. А opendpi-netfilter с его opendpi у меня не собираются.

Я рекомендовал бы связаться с автором ndpi-netfilter (ewildgoose) через комментарии в его гитхаб-странице, попросив опубликовать код ndpi-1.3, а также заняться (или его попросить) адаптацией враппера-модуля к ndpi-1.4, т.к. в ней появилось множество полезных вещей.

Судя по всему исторически было так: ndpi -> forked to opendpi -> created opendpi-netfilter -> created ndpi-netfilter .

openndpi на хабрахабре: http://habrahabr.ru/post/108280/

Также существует ебилд net-firewall/opendpi-netfilter-wrapper в оверлее sunrise:
http://pastebin.com/6KFn3AEb

P.S. Прошу прощения за столь долгий ответ. Если я чем-то могу помочь, то обращайся.

Спасибо. А ты ClearOS не пробовал? Там DPI анонсирован из коробки.

К сожалению, нет, поскольку мне нужно лишь несколько правил, а не полупроприетарный дистрибув с троянами :) . Однако, гугл подсказывает мне, что ещё 7 месяцев назад clearos использовала l7-filter-userspace, а также внесла некоторые изменения, которые улучшают производительность.

Однако, я думаю, что бессмысленно спорить о том, что userspace-решение будет медленнее ядерного. Мало того, как я уже писал выше (а ты читал :) ), n/openDPI позволяет намнооого больше, чем l7, и развивается.

И да, ты говоришь, что l7-filter-userspace требует патчей и не работает на ядрах выше 3.3.x . Но это не так, и модуль там никакой не нужен. l7-filter-userspace независим от ядра, т.к. использует очереди netfilter netlink, которые полностью отделяют ядро от юзерспейса (подобно сокетам). Смысл в том, что пакет перенаправляется в очередь номер n, далее он кладется во входящий буфер этой очереди, подцепленное приложение этой очереди из юзерспейса получает сигнал+буфер и начинает выполнение своего кода, далее она передает пакеты в исходящий буфер очереди и пакет двигается дальше по правилам.

В конкретной реализации (а вообще через netlink можно с пакетами делать что угодно, хоть tc и netfilter в юзерспейсе реализовать) также происходит установка mark на пакет со стороны юзерспейс приложения перед отдачей его netfilter, а далее netfilter выполняет преобразования (которые мы хотим) с маркированными пакетам.

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

https://www.gentoo.ru/node/23897 Что-то типа этого, только тут он где-то ошибся или что-то не доделал.

ты говоришь, что l7-filter-userspace требует патчей и не работает на ядрах выше 3.3.x

Это где я такое говорил?

Сорри, ты говорил про: «что проще и легче его пилить в виде юзерспейсного модуля для netfilter.» Но это - не модуль netfilter (с технической точки зрения).

Угу, скорее, это helper или как там они называются. Короче, мы всё равно оба понимаем, о чём речь :).

Ага. Это я к тому, что к ядро оно вообще никак не относится, т.к. интерфейс очередей включен в ядро уже весьма давно.

Кстати, ты будешь заниматься проблемой open/nDPI-netfilter? Или данной вопрос тебя нисколько не интересует?

Как телекоммуникационщика — интересует, но не в контексте pf-kernel'а.

к ядро оно вообще никак не относится

Ну я их юзерспейсными поэтому и обозвал.

Как телекоммуникационщика — интересует, но не в контексте pf-kernel'а.

В контексте pf-kernel'а я думаю, что и не имеет смысла, т.к. оно должно и ебилдом без проблем на любом ядре собираться.

Судя по комментам на openwrt и у ивелгуса, его модуль ядра весьма производителен. Буду очень рад ебилду, если запилишь.

Кстати, в pf-kernel bcache не планируется интегрировать? Он же, вроде, вынесен в отдельное md-устройство уже.

Буду очень рад ебилду, если запилишь.

Какие ебилды, я же не гентушник :).

Кстати, в pf-kernel bcache не планируется интегрировать?

Очень хотелось бы, но SSD в добавок к винту в свой ноут я поставлю нескоро (хотя такая возможность есть), а к тому времени его запилят в ванили. Есть опыт использования bcache?

Какие ебилды, я же не гентушник :).

Тогда увидеть вариант с ndpi 1.4, который успешно собирается, загружается в ядро и обрабатывает пакеты :)

Есть опыт использования bcache?

Нет, только flashcache. Намного лучше, чем с хардом. По тестам на офф сайте, получается, что bcache куда быстрее, плюс не кеширует большие линейные участки, что плюс, если на одном разделе фильмы вместе с системой свалены.

Очень хотелось бы, но SSD в добавок к винту в свой ноут я поставлю нескоро (хотя такая возможность есть)

Если проблема с аппаратном обеспечении, то могу предоставить доступ к виртуальной машине, к которой будет подключен (полностью, а не партицией) SSD, плюс от отдельный раздел.

Да ну, мне же нужно ядро в реальной работе чувствовать.

Да ну, мне же нужно ядро в реальной работе чувствовать.

Ок, не буду приставать. Но из своего опыта скажу, что тестов производительности обычно достаточно для полноты восприятия. Хотя, бесспорно, запуск легковесных приложений менее секунды, а офиса за 2-3 впечатляет :)