"-j CONNMARK --save-mark" можно сделать 1 раз после всех ndpi

В принципе, подправить xt_ndpi не сложно.

На счет CLASSIFY в prerouting.

CLASSIFY предпологает передачу пакета т.е. когда определен исходящий интерфейс, а в mangle/prerouting он еще не определен (и его вообще может на быть). Это защита от дурака.

Значит по идее это должен патч imq для iptables добавлять этот функционал.

В смысле ? Метки ndpi в прероутинге использовать в imq для шепинга входящего трафика ?

Об исправлениях.

В текущей версии я добавил только несколько дополнительных форматов пакетов мю-TP/utp. Анализ самого протокола не производится.

А ты обратил внимание, что на последнеи графике доля неизвестного udp-трафика упала и стала видна доля неопознанного исходящего tcp трафика ?

Надо будет его еще раз проанализировать. То, что я видел было TCP-syn на недоступные торрент-хосты. С точки зрения шейпинга они не представляют проблемы, а вот если хочется блокировать, то с ними что-то надо делать.

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

Да. У себя проверил. Работает. Если через mark, то сперва в iptables маркируем трафик, потом в TC создаем классы и правила обработки маркированного тарфика, какую метку в какой класс. А если CLASSIFY то сразу в нужный класс кидать, без маркировки и создания правил соотвествия метки тому или иному классу.

Ну то что udp упал вижу. А вот tcp.. Так вроде рост неизвестного tcp и до этого на графиках видно.

Ну а вообще чуть лучше кажется шифрованный ловить стал ndpi, но все равно недостаточно. За час-полтора приблизительно 25% поймал. Может чуть больше. А вот с нешифрованным все очень отлично. Вроде все детектирует.

Softirq load впечатляет... Под 70-80%. Это ядно ядро или все он так грузит?

70-80 мс из 800 мс процессорного времени. т.е. если запускать на одном ядре, то оно будет занято на 70-80%

Я не пробовал запускать его только на одном ядре. У меня оно разнесено на 4 ядра в среденем (25%,15%,15%,15%) на 0-м ядре irq, а остальные ядра 0%

Ну все равно не мало.

Для мелких роутеров такое решение можно применять только с большими ограничениями. Оно не только процессор жрет, но и память, которой на мелких роутерах обычно мало (16-32Мб это вообще ниочем). На 1024 conntrack в нормальном варианте уходит 1.9Мб RAM, в худшем 2.2Мб .

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

У меня аналог atom. AMD e-350. Пока включил 3 протокола. Остальное по портам в шейпере. Могу и остальные протоколы включить, но как протестировать, ведь это домашний шлюз с шириной интернет канала в 30мбит. Только битторент может создать более менее нагрузку. Сейчас softirq в районе 10% на 25мбит p2p при сидировании.

Обновил более развернутую инструкцию http://a7lanov.blogspot.ru/2014/10/ubuntu-imq-ndpi-3.html

Я добавил на тебя ссылку.

Запустил transmission c обязательным шифрованием, запустил сбор трафика. Как наберу несколько гигов, попробую проанализировать.

В принципе если кому-то интересно, могу попробовать собрать и на других дистрибутивах и написать инструкцию.

гм. Обнаружилось, что не определяется только 2 вида трафика (в режиме обязательного шифрования) :

1) неудачные коннекты (syn)

2) коннекты открытые до запуска ndpi или до момента идентификации BT на ip:port.

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

Конечно. Лично мне CentOS интересен...и еще бы на FreeBSD =)

Я вроде бы сбрасывал все текущие соединения, потом запускал уже ndpi Все равно бОльшую часть шифрованного трафика не определялось. Клиент rtorrent. В натройках выбирал все типы шифрования. Может другие клиенты при не все, а только часть трафика шифрует. Сегодня-завтра посмотрю как с utorrent будет.

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

Проверил так же на Ubuntu 14.04. Надо доустановить только 2 пакета. Добавил это в инструкцию. Кроме Centos еще заодно и в Debian попробую собрать.

Я собирал на Debian 7.5 - без сучка и задоринки.

Ну тогда debian не буду пробовать.

Забыл добавить, что собирал по твоей статье)

Подскажите,пожалуйста,а для какой версии ядра Вы собирали? По ссылке, в архиве http://devel.aanet.ru/ndpi/nDPI-1.5.1.r8369_v0.tar.gz, если я правильно понимаю, нет патча для ядра 3.2.0-4 - а это стандартное ядро для Debain 7.

Меньше чем на 3.4 не собирал.

режектов от патча 3.4.97 на ядро 3.2.1 нет. Возможно будет работать. Попробуй :)

я собирал для 3.4.97

нтоп

у нтопа есть несколько коммерческих утилит. от есть толк? кто-нибудь пробовал?

Пробовал ntop-ng. Ничего интересного для себя не обнаружил.

А что именно не понравилось?

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

а где бы взять инструкцию по доп функционалу? поставить-то поставил, а как потестить даже ума не приложу. мало общался с iptables

не понял если честно. Я просто подключал репозиторий, ставил ntop (jy тянул еще несколько пакетов) потом в вебке смотрел статистику.

я по базовой ндпи

например. Блокировка DNS

iptables -t mangle -A PREROUTING -m ndpi --dns -j DROP

Маркировка DNS

iptables -t mangle -A PREROUTING -m ndpi --dns -j MARK --set-mark 10

а почему в mangle а не в filter?

Маркировка в фильтр не бывает. Для маркировки таблица манг.

да пофиг где маркировать. У MARK нет ограничений. Главное маркировать до проверки метки :)

Но в mangle PREROUTING удобнее, т.к. там проходят все входящие пакеты, а в filter оно разделено на INPUT/FORWARD

Ну в общем дам. Я слишком критичен был в своих словах) Надо было просто уточнить что первым идет mangle, и маркировать тоже принято там.

скоро выложу обновление патч для ядра 3.17.3 и обновление nDPI до svn r8568

Удалось еще немного сократить затраты памяти - osdpi_id_node на 32 байта и ndpi_flow_struct на 96

Отлично! буду ждать)

гуд)) жду обновлений!!

Сейчас началось тестирование обнаружения торрент-трафика с декодированием dht и ответов трекера/нод. Каждая обнаруженная нода/пир заносятся в отдельную хеш-таблицу на 15 минут(?). При обнаружении пакета с адресом и портом из этой таблици трафик считается торрентом.

Это создает дополнительные расходы памяти (24 байта на ipv4:port), так что эта фича будет отключаемая.

на реальном ~300mbit/s трафике это давало больше 600000 записей.

С другой стороны - это всего дополнительно 15Мбайт к 200Мбайтам занимаемых flow & id

Для меня вопрос потребления памяти имеет меньшее значение, чем нагрузка на CPU

cpu будет использоваться чуть-чуть больше.

На данный момент общий результат улучшился - 1706kb неизвестного трафика на 358Mb принятого трафика и 22Mb неизвестного трафика на 14Gb переданного трафика за 21 час.

Но вот всплеск неизвестного трафика с 8 до 11 часов пока непонятен. Весь трафик идущий на хост записывается, так что нужно анализировать вручную.

Честно сказать результаты по мне так отличные. Из 14Gb только 6% неизвестного. Если же использовать в качестве блокировщика p2p на работе то думаю будет 100% результат.

Выложил обновленную версию на основе nDPI-1.5.1+ svn rev.8568

Очень рекомендую прочтитать описание изменений.

Тестирование было не очень длительное ( особенно на полном трафике).

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

крутяк!!! апплодисменты твоим трудам )) сейчас буду собирать на свежем SLES 12 и тестить)

Спасибо! И какой кстати все таки указывать размер хэша? Трафик p2p в районе 30мбит/сек. 24/7

я бы поставил 2 и посмотрел на число элементов Вот сейчас у меня

hash_size 8192 hash timeout 2100s count 860912 min 72 max 144

На мой взгляд очередь до 300 элементов не должна создавать заметной нагрузки.

Ок. Спасибо. Сегодня-завтра соберу новое ядро и ndpi

Я там сегодня некоторые уточнения написал.

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

Есть еще желание сделать список имен торрентов которые раздают клиенты - эта инфа (имя и хеш) есть после декодирования протокола.

А что полезного даст имя и хэш торрента?

Видно кто чего раздает. Но это явно будет опцией.

Мне тут летом несколько раз приходила abuse за раздачу спайдермена2. Определить кто раздает было не очень просто. А с таким функционалом можно было бы определить мгновенно. Я даже в чем-то был солидарен с правообладателем - раздавать экранку такого дерьмового качества просто преступление :)

Наверно полезным было бы выделение торрент-трекеров. С точки зрения блокировки ( а не шейпинга) выгоднее блокировать трекеры. DHT вроде и так опрделяется без проблем.

Есть 2 ближайшие задачи:

- определить какие данные декодирования являются наиболее полезными в определении BT трафика и стратегия удаления данных из хеша. Возможно разные данные нужно хранить разное время.

- IPv6. У меня дома давно уже есть /56, а тут на работе появилась сетка /48. В ndpi-netfilter ipv6 пока отрезано, а в nDPI оно есть. Поддержка ipv6 будет определятся на уровне компиляции.

С каждым годом доля ipv6 растет, да и все современные ОС уже готовы для работы с ipv6.