Собирается без проблем?

Не совсем, https://github.com/vel21ripn/nDPI/issues/41

Я вижу, что сильно изменена работа с nf_conntrack.

Кроме nDPI мне нужно добиться работы ipt_NETFLOW и IMQ в новых ядрах.

У меня есть еще пара специфических патчей ядра: SO_MARK_64 (маркировка сокета дополнительно 64-х битной меткой) и goto-target для iptables (позволяет пропустить N следующих правил)

Без них мне нет смысла что-то делать с новыми ядрами.

AUFS для 4.19 уже есть ?

Кстати, я приспособил ipset для поиска множества строк.

Если за сутки не упадет, то выложу обновление для 4.19 без NF_CUSTOM.

Если используется патч для ядра, от исправления минимальны и они уже выложены.

Через mangle Маркирую DSCP bittorrent dsc 60 остальной трафик мимо Ndpi в dscp 61

Форвордится это всё на микротик. там же на основе DSCP режу.

Столкнулся с проблемой,что когда примерно в районе 1гбит/с трафик прилетает череp шайтанмашину - она вешается намертво. Это примерно 700-1000 клиентов.

Хм. У меня рельного трафика > 500мбит/с не получить, только если записывать и воспроизводить с максимально возможной скоростью, да и 10Г интерфейсов на тестовой машине пока нет.

А RPS включен ? на сколько равномерно распределяется обработка трафика по ядрам ?

что говорит mpstat -P ALL 3

да там 16 ядер xeon e5 )) Там нагрузки на ядра 1-2% от силы. В логи ничего не успевает сервер азписать. Просто замирает намертво и всё. при трафике 500мбит/С оно вроде бы живет,но если кидаю 1 гбит/с - досвиданиня. Но я собираю под debian. Может под centos иначе будет.

Подключение через SFP+ интерфейс. RPS не актуален в таких условиях. Слишком малый объём трафика.

Ядро с патчем ?

Этого я не знаю.

я под debian собрал из ветки 1.7

Не определяются протоколы из стандартного списка. Проверил на YouTube и BitTorrent

Что говорит dmesg после загрузки модуля ?

С какими параметрами загружается модуль.

Настоятельно рекомендую патчить ядро.

[ 39.339230] xt_ndpi: Warning! Hostdef 'ggpht.com' missmatch! Skipping. [ 39.341198] xt_ndpi v1.2 ndpi 2.4.0-1320-97f4744 IPv6=YES debug_message=no BT: hash_size 0k, hash_expiation 0 sec, log_size 128kb sizeof hash_ip4p_node=44 id_struct=296 PATRICIA_MAXBITS=128 flow_struct=2024 packet_struct=1400 flow_tcp_struct=41 flow_udp_struct=27 int_one_line_struct=16 ndpi_ip_addr_t=16 ndpi_protocol=8 nf_ct_ext_ndpi=60 spinlock_t=4 NF_LABEL_ID 7 [ 39.341199] xt_ndpi MAX_PROTOCOLS 320 LAST_PROTOCOL 243

А какая версия ядра используется? на 4.19 есть жалоба.

Про мертвые зависания: Я пару раз при отладке ( давно еще ) сталкивался с таким, что при какой-то ошибке оно не делало oops, а тупо висло, но это были явные ошибки со spin_lock/spin_unlock. До сих пор я не пробовал проводить стресс-тестирование на нехватку cpu и ram.

Проблема еще в том, что я редко тестирую вариант без патча ядра, т.к. там приходится использовать адские хаки.

Если ndpi используется без патча ядра, то использование connlabel должно давать непредсказуемый результат (обычно oops).

У меня есть очень дохла машинка (древний atom), могу попробовать ей скормить 500мбит/с. Возможно проблема и проявится. Но это мне нужно до работы добраться.

Если речь идет о ядре системы 4.9.0-8-amd64

о патче ядра я слышу первый раз ( весьма мало времени еще знаком с ndpi )

Если я заворачиваю трафик на ndpi с микротика - где-то 1-2% cpu Занято и озу 200-400мб. ( это при трафике в 1 гигабит ).

Мне нужно детектить весьма скудный список трафика ( торренты и винапдейт )

Я даже готов заплатить/материально поддержать проект за нормальную настройку и отладку ))))

4.9.0-8 - это мне совсем непонятно.

На дворе сейчас 4.9.148.

Нет ли возможности обновиться на 4.14?

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

Там есть патчи для практически всех веток ядер.

Про битторрент - шифрованное оно не детектит, а про винапдейт - не знаю (а оно не ssl ?).

Чтобы BT лучше детектился, нужно загружать модуль с параметром bt_hash_size > 9. Если у тебя гигабит трафика, то bt_hash_size лучше сделать 14.

Попробуй завернуть трафик с микротика, но не включай ndpi, а запусти ndpiReader на интерфейсе с трафиком (нужно просто собрать nDPI и там в examples/ будет ndpiReader).

Учти, что для работы nDPI нужен трафик в обе стороны.

я еще могу предположить,что у меня правило написано криво в mangle.

Я походу маркерую весь входящий трафик включая исходящий от клиентов после микротика.

если использовать 2 сетевых интерфейса в виде L2 bridge - работать будет?

Каким образом тогда нужно маркировать трафик,если eth1 - шлюз, eth2 - клиенты?

Это самый простой обработки транзитного трафика.

Трафик в бридже можно обрабатывать в iptables, если включить «echo 1 >/proc/sys/net/bridge/bridge-nf-call-iptables»

трафик проходит как минимум через mangle/FORWARD и filter/FORWARD (в качестве входящего интерфейса имя моста).

Для чего маркировка? Для шейпинга или для дальнейшей обработки?

да,я хочу отловить торрент трафик входящий и на микротике его порезать.

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

Завернуть входящий и исходящий трафик - это не так просто.

В этом смысле бридж значительно более простое и правильное решение.

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

дропать трафик можно сразу в мосте и маркировать не нужно.

А как ты предпологал маркировать - через dscp/tos ?

Есть подозрение, что в битторренте есть ложные срабатывания, так что дропать такой трафик небезопасно. Лучше шейпить в 32кбит/с

шлюзом стоит микротик у сервера. у клиентов тоже. на сервере включен форвард.

Роучу клиентов на сервер. Помечею на сервере торрент трафик в DSCP 60,весь остальной в 61.

На микротике отлавливаю оба DSCP и роучу его уже в интернет. При этом отлавливаю исходящие подключения от клиентов и на основании этих подключений роучу входящие назад на сервер. Попутно маркерую пакеты с dscp 60 и зажимаю на микротике.

Во всей этой истории я предполагаю,что нужно всё-таки бриджевать. Что-то мне подсказывает,что я циклично маркерую по многу раз одни и те же пакеты.

...и похоже по этой причине сервер и отбрасывает копыта.

А у тебя сколько rps и сколько мегабит и есть ли ipv6?

netflow

Проект развивается - это хорошо. Спасибо.

По поводу netflow и «отказаться от ipt_NETFLOW» - радует. но нужна поддержка v9 т.е. nat и natevents

гм, в v9 нет ни доп. протоколов, ни имен хостов. Я хотел было туда добавить эти данные, но строковых параметров тем нет :( Возможно я идиот и не вижу очевидних вещей...

Сейчас запись выглядит так:

1551612365 1551612640 v4 6 xxx.xxx.xxx.x 51236 74.125.131.188 5228 246 312 6 6 I=16,16 Google.SSL C=mtalk.google.com

При наличии SNAT/DNAT добавляются поля SN=ip:port и/или DN=ip:port

Сейчас идет тестирование. Проблема в том, что пока оно неудачное. Уже несколько раз примерно через двое суток оно умирало и что плохо, не в моем коде. Ядро было 4.19.18. Сейчас запущен новый раунд, но с ядром 4.19.26. Прошло почти двое суток. Если за неделю не умрет, то выложу новую ветку.

Вроде 8 дней отпахало. Нужно проверить вариант без патча ядра хотя бы 2-3 дня.

Такое длительное тестирование из-за то, что пришлось переделать внутренности. При этом сильно сократилась разница между вариантами с патчем ядра и без него.

Кроме этого нужно понять откуда берется небольшая (0.1%) разница в счетчиках iptables и суммой трафика из ndpi_flow при 5-и минутном интервале. Возможно это проблема кроется в разнице времени считывания ndpi_flow и iptables -nvxL. Короче - нужно время для тестирования.

Пока непонятно что делать при переполнении данных и/или нехватке памяти.

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

Для критических ситуаций планируется задать число завершенных соединений, после которого они будут удаляться и будет генерироваться особая запись об объеме потерянных данных. Система не должна ложиться от нехватки памяти!

Цена одной записи - 176 байт + длина имени хоста ( < 256 байт). так что в случае на 2000000 записей о завершенных соединениях нужно не более 830 Мбайт рамы.

Появилась новая ветка flow_info

Как я уже говорил, она позиционируется как замена ipt_NETFLOW ( для тех, кому нужны названия протоколов и имена хостов/сертификатов и информация о NAT)

Минимальный сетап для сохранения информации о трафике через eth1

modprobe xt_ndpi ndpi_enable_flow=1
echo "limit=1000000" >/proc/net/xt_ndpi/flow
echo "timeout=330" >/proc/net/xt_ndpi/flow
iptables -t mangle -A PREROUTING -m ndpi --all
iptables -t mangle -A OUTPUT -m ndpi --all
iptables -t mangle -A PREROUTING -i eth1  -m ndpi ! --error -j NDPI --flow-info
iptables -t mangle -A POSTROUTING -o eth1 -m ndpi ! --error -j NDPI --flow-info

cat /proc/net/xt_ndpi/flow >/tmp/traffic_`data +%Y.%m.%d-%H%M`

не компилируется у меня с USE_HACK_USERID

/usr/src/nDPI/ndpi-netfilter/src/main.c: In function ‘ndpi_mt’:
/usr/src/nDPI/ndpi-netfilter/src/main.c:1234:12: error: ‘const struct sk_buff’ has no member named ‘userid’; did you mean ‘users’?
      (skb->userid & 0xffff000000000000ull)
            ^~~~~~
            users
/usr/src/nDPI/ndpi-netfilter/src/main.c:1236:42: error: ‘const struct sk_buff’ has no member named ‘userid’; did you mean ‘users’?
          ct_ndpi->flinfo.ip_snat  = skb->userid & 0xffffffff;
                                          ^~~~~~
                                          users

ну и т.д.

особо не вникал, решил спросить )

cat /proc/net/xt_ndpi/flow >/tmp/traffic_`data +%Y.%m.%d-%H%M`

cat /proc/net/xt_ndpi/flows >/tmp/traffic_`date +%Y.%m.%d-%H%M`

Упс. забыл убрать. Спасибо!

спасибо, я без него скомпилил, просто не знал насколько функционально будет...

на тесте полдня работает ) в бой рано?

У меня оно пару суток отработало в таком виде, а до этого прототип 8 суток отработал.

В новой ветке разница между патченным ядром и не патченным ядром стремится к нулю. Скорее всего скоро можно будет отказаться от патча с NF_CUSTOM.

Если оно загружено без ndpi_enable_flow=1, то накладные расходы ровно такие же как в netfilter-2.6.

А сильно сложно будет прикрутить вывод в flows значения connlabel и connmark ?

connmark - запросто, а вот с connlabel есть проблема - если используется вариант без патча ядра, то там хранятся данные nDPI.

по сути нужен только connmark (у меня там account id клиентов), connlabel упомянул до кучи, если его не будет - не критично, ну или опционально если вариант с патчем

еше у меня не работает почему-то

echo «mode» >/proc/net/xt_ndpi/flow write error: Invalid argument

echo "read_all" >/proc/net/xt_ndpi/flows

3 режима чтения

- read_all - нормальное чтение данных с определенным интервалом.

- read_closed - для подчитывание закрывающихся соединений между считыванием аккаунтинга. Теоретически должно помогать при большом числе коннектов/сек.

- read_flows - чтение абсолютных значений счетчиков. Это для простого мониторинга.

Режим нельзя менять во время чтения. Можно менять после seek(0) или после открытия файла или после получения EOF.

Список всегда отсортирован в обратном порядке по времени создания соединения (от самых новых к самым старым).

Все равно не понял как менять режим (

всегда выдает ошибку записи

Исправил. И про connmark добавил.

PS

echo -n "read_all" >/proc/net/xt_ndpi/flows замечательно работало :)

спасибо!

а может имеет смысл чтобы количество полей всегда было одинаково? для парсинга проще

Парсинг и так простой, а обязательные поля идут сначала строки.

Или ты на ассемблере парсер пишешь ? :)

Изменить формат вывода не сложно - там 1 функция. Форкни и сделай как тебе удобно.

Приветствую!

Новая ветка flow это netfilter + функционал flow?

Набор данных есть в заголовке. По сравнению с ipt_NETFLOW нет MAC адресов и VLAN. Получение данных через procfs, т.е. только локально.

Пример данных о соединении

1554461054 1554756887 4 17 xxx.xxx.xxx.61 8053 74.125.131.189 443 1463 1602 22 24 I=17,17 P=Google.QUIC H=cello.client-channel.google.com

Заголовок я конечно прочитал ) , я имел ввиду немного другое - про то, что nDPI-flow вынесена в отдельную ветку (nDPI как замена l7filter [продолжение2] (комментарий)) потому что добавлен новый функционал к имеющемуся?

Было две причины сделать новую ветку: внесение больших изменений в код и добавление функционала.

Возможно ли добавить нумерацию, например как у netfilter при распаковки, т. е. nDPI-flow-1.1 1.2 и т д? Это хорошо для сборки установочных пакетов.

50518 1554913901 1554914134 4 6 172.17.13.87 47517 172.217.16.142 443 208 236 4 5 21,27 89.18.14.87:47517 - Google.SSL android-safebrowsing.google.com

лично у себя сделал так прямо в коде, парсинг элементарный и через sflow-tools загоняю прямо в биллинг, неделю - полет нормальный! огромное спасибо!

Там есть мелкое, но полезное исправление по мотивам ndpi filter does not detect potocol inside http_proxy #54

В документации неточность

https://github.com/vel21ripn/nDPI/blob/flow_info/ndpi-netfilter/FLOW_INFO.txt

порядок полей не соответствует тому что в коде, а именно

9.  Bytes from sourse to destination
10. Packets from sourse to destination
11. Bytes from destination to sourse
12. Packets from destination to sourse

а в коде на самом деле

9.  Bytes from sourse to destination
10. Bytes from destination to sourse
11. Packets from sourse to destination
12. Packets from destination to sourse

Спасибо. Подправлю.