nDPI как замена l7filter [продолжение]

Я не провайдер. У меня небольшая сеть на 100-150 хомяков. Большая вероятность того, что кому то вдруг срочно понадобится сайт дополнений для iis или сайт магазина игрушек? К тому же эта блокировка полгода висела. Узнал что в ней дело случайно.

Дампы снять можно, но хочется проверить именно с правилами iptables

Добавлен парсер CSGO/DOTA2. Пока они неотличимы :( Возможно они отличаются только адресами/портами серверов.

С WoT пока все совсем непонятно. Боюсь там хрень похлеще BT.

Обнаружение BT немного исправлено, потестируйте у кого есть WoT - попадает оно в BT или остается unknown.

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

По этому я и написал «перед собой». Это буквально, только перед своим хостом, а не перед абонентами.

iis.net и g2a.com Да при блокировании tor они отваливаются. Думал по ip блочит, но вроде нет его в списках.

«Перед собой» не вариант. Я не смогу поставить и запустить все приложения(игры) для проверки! По этому глобально нужно включать отлавливать жалобы и уже «перед собой» дампить и проверять.

Vel, погонял 3 часа. Вроде всё хорошо. Пока жалоб не было. Буду дальше тестить.

Отписал на гитхабе о блокировке. Но прикрыли, сказав, что все нормально и сайты определяются как https

Потому что бага была найдена при разработке max197616/nfqfilter, вот она nDPI#147.

Протоколы в тестируемом бранче не мерджатся с первичной веткой разработки, по этой причине постоянно будут грабли. Особых проблем изменить это не составит, естественно не силами vel'a.

Собрал ndpi-netfilter последней ревизии 1.7.0-netfilter-222-edf7a3b на свежем Debian 8.6, ядро 3.16.39 с патчем v3.14.5. правила

iptables -I FORWARD -m ndpi --bittorrent -j DROP
iptables -I FORWARD -m ndpi --bittorrent -j LOG --log-level 6 --log-prefix "bittorrent-traffic"

а с какими параметрами загружен модуль ?

без bt_hash_size оно не будет определять большую часть BT-трафика

а какие оптимальные настройки bt_hash_size ?

Где можно посмотреть все ваши патчи imq? По ссылке http://devel.aanet.ru/ndpi/imq.html крайняя 4.0.3. А в посте у вас 4.4 даже есть

Вот оно

Я имел ввиду все патчи) Почему этого патча например нет тут http://devel.aanet.ru/ndpi/imq.html ?

Я имел ввиду все патчи)

Все патчи тут (http://www.linuximq.net/), у vel'a с поддержкой netns в плоть до 4.4 по-моему.

а какие оптимальные настройки bt_hash_size ?

Не помню чтобы кто-то ими делился. Если с 2014года ничего не изменилось, то мануал примерно такой:

Парсер сообщений (dht) и хеш для хранения ip:port получаемых парсером. По-умолчанию хеш отключен! Чтобы его включить нужно указать его размер 1-32 (параметр bt_hash_size). Число элементов хеша будет равно N*1024. Кроме это можно указать время хранения данных в хеше 900-3600 секунд (параметр bt_hash_timeout). По моим наблюдениям, большая часть повторных обращений происходит в пределах 30 минут. Число хранимых элементов в хеше и другую информацию о хеше можно посмотреть в /proc/net/xt_ndpi/info.Чем больше хранящихся элементов, тем длинее цепочка, тем дольше поиск. При тестировании на одном сервере в хеше было ~11000 элементов. При тестировании на сети /24 с 300Мбитным трафиком число элементов было 0.8-1.2 миллиона элементов! Каждый элемент - 24 байта!

Формат /proc/net/xt_ndpi/info

hash_size 8192 hash timeout 2100s count 622642 min 0 max 117 gc 248549

hash_size 8192 - размер хеш-наблицы; hash timeout 2100s - время хранения; count 622642 - общее число элементов в хеше; min 0 - минимальная длина цепочки в хеш-таблице; max 117 - максимальная длина цепочки в хеш-таблице; gc 248549 - счетчик удалений из хеша.

Дальше идут длины цепочек для каждой цепочки хеш-таблицы. Если в файл /proc/net/xt_ndpi/info записать число от 0 до hash_size-2, то в этом файле будет показано содержимое цепочки. Чтобы посмотреть общую информацию о хеше в файл нужно записать "-1"

Но сразу говорю, написанно скорее всего не точно. Если «Число элементов хеша будет равно N*1024», то почему тогда могут быть миллионы элементов в таблице? Видимо формулировка не совсем верная. Еще не знаю что будет с элементами когда таблица будет заполнена, но время жизни не истекло. Более старые элементы будут вычищаться из таблицы или новые не будут влезать. В общем, из-за того что лично мне не совсем очевидна формула расчета потребления памяти (всегда можно почитать код), как например для stripe_cache_size для mdraid (и я это проверял)

# (((stripe_cache_size*page_size)*number_of_disc))/1024)/1024
# 8192 pages * 3 disk = 96Mb RAM
echo 8192 > /sys/block/md0/md/stripe_cache_size

bt_hash_size=N - это размер hash-а. Каждый элемент хеша - список ip:port отсортированный по времени.

Если данных много, а размер hash-а маленький, то мы получаем длинные списки и более медленный поиск.

тут 4.9.3 вышло, так там nf_queue опять перепахали и imq патчи не прикладываются :(

Надо смотреть в чем разница.

bt_hash_size=N - это размер hash-а. Каждый элемент хеша - список ip:port отсортированный по времени. Если данных много, а размер hash-а маленький, то мы получаем длинные списки и более медленный поиск.

Так более понятней. То есть рекомендация простая - чем больше размер hash'a, тем поиск выполняется быстрее. Остался вопрос про память. На сколько я понял количество элементов зависит от поступаемых данных и никак не ограничивается, элементы удаляются по тайм-ауту.

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

Именно так.

Возникла мысль - сделать ограничение на максимальную длину списка элемента хеша bt_hash_len. Тогда bt_hash_size*1024*bt_hash_len - будет максимальным числом хранимых записей.

Возникла мысль - сделать ограничение на максимальную длину списка элемента хеша bt_hash_len. Тогда bt_hash_size*1024*bt_hash_len - будет максимальным числом хранимых записей.

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

Как-то так, если развивать идею.

Именно поэтому я и спрашивал, где можно посмотреть все патчи. Вчера не смог собрать с новыми ядрами, поэтому решил остаться на 4.4

4.5/4.6/4.7/4.8 не нравятся вам? :) На 4.9 никто еще не портировал.

4.5,4.6,4.7,4.8 - EOL

Не люблю мертвечину :)

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

Для 4.4, как оказалось, стартовый патч потом где-то был подправлен и к 4.4.42 он уже отличался.

Для 4.9.3 вроде приложил, нужно тестировать.

4.9.3 уже тоже мертвечина)

с чего бы ? 4.9 только только stable стала.

То, что ее похоронят - это да, но и 4.10.3 пока еще не вышла.

В смысле что уже 4.9.4, это имел ввиду.

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

Не совсем понял.

Я прикладываю патчи в начале ветки ( например с 4.4.3 ), дальше оно мержится с официальными патчами и по мере появления конфликтов исправяется.

Для 4.4.42 первоначальный патч уже нельзя применить (режекты и ошибки компиляции), а как вытащить все изменения которые были связаны с этим патчем я не знаю.

Я у себя выложил патч imq для 4.9.3

Быстрое тестирование показало, что вроде работает, но не гарантий, что все хорошо.

А, теперь понял. Не знал что мержится с офф патчами. Думал они сами по себе. Спасибо. Посмотрю на досуге новый для 4.9 тоже

Беда обнаружилась!

На ядрах 4.8 и 4.9 без патча ndpi не работает!

В 4.8rc0 изменили nf_conntrack_labels

Здравствуйте! Поставил себе на шлюз ndpi 1.7.0-netfilter-224-21e4600 with IPv6(собралось и поставилось без всяких проблем и патчей). Так же на нем стоит сенсор ipt_NETFLOW который через некоторое время после добавления правила iptables -t mangle -I PREROUTING -m ndpi --bittorrent -j MARK --set-mark 10 начал писать в лог кучу сообщений следующего характера - ipt_NETFLOW: sendmsg[0] error -11: data loss 172 pkt, 63471 bytes: increase sndbuf! и сервер начал жутко виснуть. Из файла /proc/net/stat/ipt_netflow было видно что был достигнут порог active flows 2000000 (в обычном режиме не превышает 20000)и превышен sndbuf. Подскажите пожалуйста куда копать? Заранее благодарю! Дополнительная информация: сервер форвардит до 400мбит трафика. lsb_release -a Distributor ID: Debian Description: Debian GNU/Linux 8.1 (jessie) Release: 8.1 Codename: jessie

uname -a Linux border 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux

lscpu Model name: Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz

lspci 01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

ipt_NETFLOW version 2.2, srcversion ECDD053FB28D2E5A9910D50 ipt_NETFLOW: hashsize 655360 (5120K)

xt_ndpi v1.2 ndpi 1.7.0-netfilter-224-21e4600 with IPv6 bt hash size 0k gc timeout 1200 sec sizeof hash_ip4p_node 44 sizeof id_struct 256 sizeof flow_struct 912 sizeof packet_struct 416 sizeof flow_tcp_struct 38 sizeof flow_udp_struct 18 sizeof int_one_line_struct 4 sizeof ndpi_ip_addr_t 16 sizeof ndpi_protocol 4 sizeof nf_ct_ext_ndpi 40 sizeof spinlock_t 4 NF_LABEL_WORDS 4 NF_LABEL_ID 8

Пока не понятно как оно могло повлиять.

Есть возможность повторно воспроизвести проблему ?

Повторно то воспроизведу, а что потом смотреть?

Добавлю что netflow собараю в raw -A PREROUTING -i eth1.vlanid -j NETFLOW -A PREROUTING -i eth1.vlanid -j NETFLOW (трафик с мира приходит на два интерфейса)

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

Если она больше 50% в softirq, то нужно включить RPS (Documentation/networking/scaling.txt)

Хочется исключить вариант с [D]DoS.

А почему не делать это по человечески -t filter -I FORWARD -j NETFLOW?

Пробовал в качестве эксперимента выставлять до правил которые находятся в mangle PREROUTING и предназначены для маркировки пакетов которые пойдут на кеширующий прокси.

Можете рассказать как собирали, у меня не выходит?

Я так понял сейчас на 4.9 без патча ядра не взлетит?

должно работать.

в 4.8 переделали connlabels и пришлось вариант без патча сильно переписать.

Приветствую. При сборке выпадает с ошибкой, подскажите как подправить?

DKMS make.log for ndpi-1.7.0 for kernel 4.9.0-0.bpo.2-amd64 (x86_64)
Пнд Июн 19 12:19:06 EEST 2017
make: вход в каталог «/usr/src/linux-headers-4.9.0-0.bpo.2-amd64»
/usr/src/linux-headers-4.9.0-0.bpo.2-common/scripts/Makefile.build:49: *** CFLAGS was changed in "/var/lib/dkms/ndpi/1.7.0/build/Makefile". Fix it to use ccflags-y.  Останов.

без понятия.

У тебя дело до компиляции не дошло, значит что-то в системе отсутствует.

А разве не в этом дело ?

*** CFLAGS was changed in "/var/lib/dkms/ndpi/1.7.0/build/Makefile". Fix it to use ccflags-y.

Из этого все стоит.

GNU tools (autogen, automake, autoconf, libtool)
GNU C compiler (gcc)

conntrack -F && rmmod xt_ndpi

Можно ли выгружать модуль если есть правила в фаерволе с этим модулем? Не будет ли kernel panic?

Хочу хєш включить, посоветуйте значения, думал поставить максимальные 6Гб памяти, 500 Мбит трафика.

bt_hash_size=32 bt_hash_timeout=3600

Можно ли выгружать модуль если есть правила в фаерволе с этим модулем? Не будет ли kernel panic?

оно не даст выгрузиться пока есть хотя бы одно правило с -m ndpi или -j NDPI