Тут одна проблема выявилась. Точнее заметил только сейчас. Решил настроить ВПН напрямую между рабочим и домашним комп (по умолчанию впн сервер у меня находится на домашнем шлюзе, сейчас же решил сделать по типу «точка-точка» именно между 2 машинами) и проверить как все это работает. Сразу заметил, что скорость чуть ниже, чем должно быть. Начал рыть. Выяснилось, что небольшие потери в скорости начинаются при связке tc + ndpi. Работает это у меня следующим образом все: Есть скрипт (вроде как даже выкладывал где-то тут ссылку), создает правила tc на основе ip/port плюс меток, которые ставятся средствами iptables. ndpi используется как раз, чтоб маркировать ту часть трафика, которую не определить средствами tc/iptables (тот же bitorrent). И вот тут начинаются странности. Если просто добавить правила маркировки средствами ndpi (например -m ndpi --bittorrent -j MARK --set-mark 25), то это никак не влияет на трафик. Скорость как была так и остается. Но если создать классы и правила в tc, которые даже не касаются трафика маркированного ndpi (то есть не добавлять правил вида
tc filter add dev imq0 protocol ip parrent 1:0 prio 1 handle 25fw flowwid 1:25 ), то скорость начинает падать (в моем случае с 50 мбит до 38-40). Проблема исчезнет если удалить правило iptables с маркировкой трафика средствами ndpi, либо удалением правил tc. Но как они между собой могут быть связаны мне не понятно. В tc детектится и шейпится одно (например трафик по 80 порту), ndpi просто маркирует трафик, но трафик с метками ничего не трогает.

Завтра хочу протестировать как поведет себя эта связка, если ndpi будет не маркировать трафик, а сразу отправлять его в очередь с помощью CLASSIFY, ну и дальше копать.

Немного сумбурно конечно рассказал, но не смог понятливей. Вечер понедельника. Голова плохо соображает и не могу понятливей сформулировать =)

UDP. Нашел правило, из-за которого падает скорость.

tc filter add dev imq1 protocol ip parent 2:0 prio 33 u32  match ip src 192.168.1.1/24  flowid 2:204

-A PREROUTING -m ndpi --bittorrent -j MARK --set-mark 25

Кстати еще. К сожалению имеющийся аналог CLASSIFY (да и вообще сам CLASSIFY) бесполезен, так как он маркирует только пакеты, но не соединения. Особенно это сильно заметно в случае bittorrent. Если просто маркировать пакет или использовать CLASSIFY, то детектируется только 10-15% всего трафика. Но если распространять метку на все соединение, то тогда почти все 100%. Поэтому отказаться от лишнего этапа с маркировкой трафика не избежать. Я надеялся сразу отправлять трафик в необходимый класс.

Если просто маркировать пакет или использовать CLASSIFY, то детектируется только 10-15% всего трафика.

Как это ? Нифига не понял.

nDPI привязан к conntack т.е. соединению. Для шейпинга нужно классифицировать нужно пакеты. Сейчас это делается достаточно просто

"-j NDPI --ndpi-id --set-clsf"

Предыдущее сообщение пока не осилил - tl;dr

Я хочу сказать, что если сделать просто

-m ndpi --bittorrent -j MARK --set-mark 205

-m ndpi --bittorrent -j NDPI --value 0x10205 --set-clsf

-m mark --mark 205 -j CONNMARK --save-mark

tc filter add dev imq1 protocol ip parent 1:0 prio 0 u32  match ip src 192.168.1.1/24  flowid 1:203

 -m ndpi --bittorrent -j MARK --set-mark 205

"-m mark --mark 205 -j CONNMARK --save-mark"

Гм, а как потом этот CONNMARK используется?

А нет ли где использования правил "-m state --state ESTABLISHED" которые пропускают часть действий для пакетов относящихся к установленным соединениям или переопределяют крассы/метки ?

Есть. В filter INPUT. Разве это распространяется на mangle?

не должно.

Просто такая фигня может происходить если не все пакеты проходят через ndpi. Под словом «все» - это входяшие и исходящие пакеты (транзитные в обе стороны).

скайп

Добрый вечер/день

Возможно ли отфильтровать голосовой трафик скайпа?

без понятия.

Если он шифрованный, то маловероятно.

обновил на гитхабе ветку netfilter 1.7.0-netfilter-202-c20e93d

Исправления:

Bittorrent снова работает с IPv6!

Bittorrent более аккуратно вносит данные в хеш-таблицу. Раньше для любого пакета определенного как BT в хеш вносились оба адреса. Теперь для запросов в хеш вносится только адрес источника.

Дополнение:

Можно определять трафик по протоколу L4 + port + сеть

В /proc/net/xt_ndpi/ip_proto пожно посмотреть предопределенные IP:протокол

Формат строки для изменения

[-]prefix ([[(tcp|udp|any):]port[-port]:]protocol)+

prefix - это сеть/длина_маски

'-' - удалить

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

10.0.0.0/8 tcp:1080:http tcp:8080:http tcp:5000-5200:ftp_data

Пытался смержить свои изменения с веткой dev - пока результат отрицательный. Слишком много там изменений. Похоже придется заново прикладывать все патчи.

Спасибо. Будем тестить.

PKGBUILD для пользователей ArchLinux https://aur.archlinux.org/packages/ipt_ndpi

Спасибо!

Работает отлично (тестирую еще с момента внесения изменений в гит).

Пытался смержить свои изменения с веткой dev - пока результат отрицательный. >Слишком много там изменений. Похоже придется заново прикладывать все патчи.

Надеемся и ждем! )

проблемы при подсчете с помощью ipt_NETFLOW после наложения патча IMQ

Считаю и журналирую трафик с помощью ipt_NETFLOW и оболочки Flowviewer(вещь!). После перезагрузки ядра(3.18) с наложенным патчем imq ipt_NETFLOW выгружает несоответствующую реальным размерам статистику(примерно на два порядка). Два правила находится в таблице mangle цепочках PREROUTING и OUTPUT.

Не подскажите причину и рецепт излечения?

Вообще не в тему, но патч-то у вас какой?

Вообще лучше сюда https://github.com/aabc/ipt-netflow + сюда сходить https://github.com/imq/linuximq

я тут подправил ipt_NETFLOW на тему ndpi - там есть в структуре 2 байта неиспользуемое поле, в которое можно сохранить протокол.

1459170901  6 173.194.222.101 80 194.226.xxx.xxx 48289 39207 8442 65 47 0 vlan517 ndpi=youtube,http
1459170901  6 64.233.163.155 443 10.21.12.253 54795 3020 1670 13 16 SNAT 194.226.xxx.xxx 12371 vlan517 ndpi=google,ssl
1459170902  6 240d:1a:30e:c300:2ac6:8eff:fe36:54fa 51413 2a01:xxxx:xxx:::3 33718 1092 1023 10 9 0 vlan136 ndpi=bittorrent

Только коллектор у меня свой.

Единственное подозрение на то, что ipt_NETFLOW не пересобран после патча imq.

imq изменяет размер «struct sk_buff»

Произвел два действия:

1. Пересобрал IMQ в ядре модулем. Изменился порядок инициализации сетевых карт - при монолитном использовании IMQ интерфейсы инициализировались раньше физических.

2. Пересобрал по Вашему совету пакет ipt_NETFLOW(gentoo) после патча, а он действительно при сборке использует ссылку(/usr/src/linux) на текущие исходники.

И ура! - статистика стала показывать реальные величины. Спасибо за подмогу. Буду разбираться с nDPI дальше.

Задам вопросы не по теме, но все же косвенное отношение имеют. Вы отметили два момента:

я тут подправил ipt_NETFLOW на тему ndpi - там есть в структуре 2 байта неиспользуемое поле, в которое можно сохранить протокол.

только коллектор у меня свой.

Вопросы: 1. где взять этот правленый ipt_NETFLOW? 2. что за коллектор? может окажется, что он лучше 3. чем пользуетесь для визуализации и построения отчетов поверх данных собранных коллектором?

1. где взять этот правленый ipt_NETFLOW?

Пока он не выложен в открытый доступ, т.к. там еще несколько хаков расчитаных на модифицированное ядро. Тем еще сделана поддержка ipv6 для NETFLOW_v5.

В принципе, можно на гитхабе форкнуть,но без правки коллектора он бесполезен.

2. что за коллектор? может окажется, что он лучше

от заточен под решение своих задач - подсчет трафика по 5-минутным интервалам (подробный + сумма для каждого локального ip). конвертация после стандартного коллектора оказалась очень сложная.

3. чем пользуетесь для визуализации и построения отчетов поверх данных собранных коллектором?

нет визуализации. А для отчетов свой старинный велосипед.

Тут чел из аргентины ( который нашел пару странностей ) отписался

The new way to mark and match work fine! You've done an excellent job!! We are analyzing (dpi), classify, marking and applying policies (shaping with tc) over 3.5Gbps and 1.2 million of sessions (conntrack sessions) (over 25k subscribers/box). We are using and old machine with 16 cores and two 10Gbps NICs with RSS enabled to balance between cpu core.

Вот это более серьезное тестирование. Не то, что мои жалкие 400Мбит/с.

Небольшое обновление. (commit 7fc13cd1cc042fecd0dd8977d845a7b802561b6d) от 18.04.2016

    backport https://github.com/ntop/nDPI/pull/173
    
            Fixed buffer overflows with safe str search
            Fixed more buffer overflows with small packets
            Fixed oscar buffer overflow

Исправление касается возможных некорректных действий при поиске строк в коротких пакетах. Особенно это коснулось протоколов ftp & ssl.

гм. Похоже, что никто не использует ndpi без патча ядра.

И правильно делают! Оно сломалось! Когда ? Я сам не понял.

1.7.0-netfilter-211-e616e74 - должно работать без патча ядра.

Я последние полгода только этой версией и пользуюсь... Проблем не замечал. Трафик детектит. Явных утечек памяти нет. В сутки от 40 до 100гиг.

гм. Я этот вариант тестировал хз когда, на 4.Х точно не тестировал.

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

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

Ну у меня одна машина i386 другая x86_64. Ядра 3.17. Почему у меня работало без проблем не знаю. Но спасибо, завтра обновлю и там и там. Пересобирать ядро каждый раз уже давно надоело, поэтому использую версию без патча.

Найдена причина - это разные туннели.

Пока не будет исправления нужно исключить вcякие ipip/ipgre из обработки в ndpi.

Непонятно какие еще туннели дают такой эффект.

В 1.7.0-netfilter-212-56eacee исправлена достаточно экзотическия проблема:

Если анализируется трафик на машине с интерфейсами типа ipip и число conntrack через туннель больше чем обычного трафика, то появляется куча предупреждений.

Доброго времени суток.

Собрал по инструкции от сюда

# uname -a
Linux fw.hostname.local 3.10.0-123.20.1.el7.IMQ.x86_64 #1 SMP Thu Apr 28 07:35:26 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

# cat /usr/src/kernels/3.10.0-123.20.1.el7.IMQ.x86_64/.config | grep IMQ
# Linux/x86_64 3.10.0-123.20.1.el7.IMQ.x86_64 Kernel Configuration
CONFIG_NETFILTER_XT_TARGET_IMQ=m
CONFIG_IMQ=m

После того как подгрузил модули, добавляю правило:

iptables -t mangle -A PREROUTING -m ndpi --bittorrent -j MARK --set-mark 25

И сервер перезагружается. Сейчас сервер находится в другом здании, посмотреть что именно происходит в этот момент возможности нет. В логах(/var/log/messages) ошибок я не нахожу. Как можно отловить в чем ошибка или может быть я что-то не так делаю?

Я эту инструкцию давно не обновлял. Помню с какой то версией nDpi была проблема, при включении такого правила появлялся Kernel Panic. Используйте версию с гитхаба. У меня там же есть инструкция для убунту. Дойдите до участка, где описывается установка и гитхаба. По идее в Centos все точно так же. Инструкцию обновлю позже, когда буду свободней.

Версия nDPI какая ?

Брать только с github.

Насколько я помню, брал версию как раз с гитхаба...

# cat ./nDPI/config.log | grep VERSION
| #define PACKAGE_VERSION "1.7.0"
| #define VERSION "1.7.0"

Тогда наверное идти на место и там в консоли добавлять правило и смотреть то происходит. ndpi с патчами на ядро?

1.7 оно уже давно. более информативно grep NDPI_GIT_RELEASE config.h

Что из себя представляет 3.10.0-123.20.1.el7 - не знаю.

Я вообще на 3.10 не тестировал.

Было бы интересно посмотреть на oops. На 3.10 вроде работает ramoops ядра 3.10 - ramoops с человеческим лицом!

vel

1.7 оно уже давно. более информативно grep NDPI_GIT_RELEASE config.h

# grep NDPI_GIT_RELEASE config.h
#define NDPI_GIT_RELEASE "1.7.0-netfilter-212-56eacee"

vel

Было бы интересно посмотреть на oops.

Постараюсь собрать в ближайшее время, спасибо!

as_lan

ndpi с патчами на ядро?

Да.

А если использовать версию без патчев? не пробовали?

Imex, Linux 4.5 + iptables 1.6.0, работает прекрасно. Попробуйте собрать на современном ядре.

Добрый день, Если есть возможность поясните, пожалуйста, для начинающего некоторые моменты по NDPI. Правильно ли я понимаю, что:
1) исходники NDPI от офф разработчиков компилируются в библиотеку, которая в режиме реального времени не позволяет работать с траффиком.
2) исходники NDPI от Vel компилируется в модуль для ядра, с помощью него можно отслеживать трафик в рельном времени.

Если правильно, то для какую функцию выполняют дополнительные патчи, IMQ и патч для IPtables. Или без них NDPI в реальном времени просто работать не будет и это обязательное требование?

P.S. хочу установить все на ядро 3.4.80 Debian. Возможно патч для IPtables не нужен?

1 - почему ? оно умеет через libpcap слушать интерфейсы и возможно nflog

2 - это интерфейс между nDPI-iptables-nfconntrack

IMQ к nDPI не имеет отношения.

для 3.4 патч обязателен.

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

А для 4.5 патч от 4.4 от сюда подойдет?

без понятия.

Там вроде пара режектов была, но они тривиальные и ручками их подправить не сложно.

да

Для 4.5.0 тут.

А как продвигается процесс синхронизации с апстрим веткой? Я видел, что попытка была, но потом откат.

Пока никак. Времени нет совсем.

Там сильно переделали 2 вещи - переименовали ipv6 поля (не нет много работы) и переделали организацию инклюдов - а это не тривиальная проблема т.к. они забили на kernel-mode

Мелкие правки я буду бекпортить ( типа #205 )

Мои предложения:
1. ndpi кстати не умеет собирать пакеты. Как идея добавить сборку пакетов в ndpi
2. Добавить поиск в пакетах произвольной фразы
3. Добавить анализ потока в tcp в ndpi
4. Добавить поиск url
5. Добавить в -j NDPI отправку tcp пакетов

Где патчи ?

Ждем PR.

Я заметил, если поставить mtu 128, то ndpi не видит пакеты с этим mtu.

А чего до 64 не убавил ? :)

MTU < 512 не рекомендовалось использовать во все времена.