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

Через ndpi должны проходить ВСЕ пакеты в ОБЕ стороны.

Это условие корректной работы ndpi?

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

Хочу выгрузить модуль, делаю

~# modprobe -r xt_ndpi
modprobe: FATAL: Module xt_ndpi is in use.

Правила все убрал которые используют ndpi. Но всеравно зависимости.

:~# lsmod | grep xt_ndpi
xt_ndpi               469080  2239
nf_conntrack           91572  10 xt_ndpi,nf_conntrack_proto_gre,nf_nat,nf_nat_ipv4,nf_nat_pptp,xt_conntrack,nf_nat_masquerade_ipv4,xt_connmark,nf_conntrack_ipv4,nf_conntrack_pptp
x_tables               27104  19 xt_statistic,xt_iprange,xt_ndpi,ipt_NETFLOW,ip_tables,xt_tcpudp,xt_string,ipt_MASQUERADE,xt_conntrack,xt_IMQ,xt_LOG,xt_nat,xt_set,xt_multiport,iptable_filter,xt_CLASSIFY,xt_TCPMSS,xt_connmark,iptable_mangle

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

Сперва надо сбросить все соединения. conntrack -F В инструкции об том сказано.

Опачки, то что нужно и не заметил. Спасибо.

Через ndpi должны проходить ВСЕ пакеты в ОБЕ стороны.

Это условие корректной работы ndpi?

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

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

если разные каналы НАТятся разными адресами, то будут проблемы.

Пропустил весь трафик, скачал 3 фильма по 1,5Гб, вроде совпадает, там конечно не только мой трафик был, вроде детектит хорошо, скорость была отличная.

если разные каналы НАТятся разными адресами, то будут проблемы.

Какие могут быть проблемы? Или может просто с цепочки маркировки выгонять если входящий интерфейс провайдера?

Chain PREROUTING (policy ACCEPT 23M packets, 21G bytes)
  23M   21G ndpi_p2p   all  --  *      *       0.0.0.0/0            0.0.0.0/0
  23M   21G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore

Chain ndpi_p2p (1 references)
 pkts bytes target     prot opt in     out     source               destination
8000K 6234M ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol bittorrent
 
Chain ndpi_p2p_mark (9 references)
 pkts bytes target     prot opt in     out     source               destination
8000K 6234M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x1
3998K 3116M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.50000000000
4002K 3118M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x2

Выгонять если новые соединения и входящий интерфейс провайдера.

Исправлена ошибка в "-j NDPI --ndpi-id"

Раньше при установке марки или класса использовался только основной протокол, а подпротокол игнорировался (bug).

Теперь, если протокол определен, то сначала используется основной протокол и потом, если определен подпротокол, то используется подпротокол. Иначе используется марка/маска для протокола unknown.

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

iptables  -m ndpi ! --unknown -j NDPI --ndpi-id --set-mark

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

А если я сначала завожу все в ndpi

-A PREROUTING -j ndpi_p2p

детектирую нужный протокол

-A ndpi_p2p -m ndpi  --bittorrent  -j ndpi_p2p_check

отберу новые входящие от клиентов

-A ndpi_p2p_check -m conntrack --ctstate NEW -s 10.193.0.0/16 -i ppp+ -j ndpi_p2p_mark

промаркирую как мне надо их

-A ndpi_p2p_mark -j CONNMARK --set-xmark 0x1/0xffffffff
-A ndpi_p2p_mark -m statistic --mode random --probability 0.50000000000 -j RETURN
-A ndpi_p2p_mark -j CONNMARK --set-xmark 0x2/0xffffffff

В этом случае маркировка новых соединений правильно наложиться на все связанные, в частности bittorrent ?

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

Для BT/tcp это далеко не всегда так.

А как-нибудь можно сделать через iptables и -j NDPI возможность назначать тип протокола конкретному соединению принудительно? Например, -p tcp --dport 80 -j NDPI --set-ndpi-proto http (или set-ndpi-id 0x07/0xff).

пока нет.

Я собирался сделать загрузку своих предопределение по портам/порт+сеть. Увы пока занят другим.

А для каких целей это может потребоваться?

Я тут похоже на баг нарвался. поставил дебиан минимал 8.2 на ядре 3.16.0-4-amd64, ядро не патчил.

И xtables-addons с сорсов из репозитория не компилируются.

В общем, скачал с гибхаба версию 2.6, которая поставилась.

НО!

1)как мне проверить роботоспособность xtables?

2)есть ли более нормальные решения вопроса? должен же кто-то был сталкиваться.

3) Ввожу iptables -A INPUT -j NDPI --help и получаю ошибку с неправильным синтаксом. почему?

4) http://s019.radikal.ru/i631/1512/64/a00aa05b0258.png по ссылке на скрине пишется про ошибку. это нормально?

товарищи, с предыдущим фактически разобрался.
ndpiReader детектит траф(youtube,speedtest) нормально
А вот через iptables не хочет.

 iptables -t mangle -A POSTROUTING -m ndpi --all -j DSCP --set-dscp 10
iptables -t mangle -A POSTROUTING -j DSCP --set-dscp 11 

Установлен бридж.
Весь траф детектится по второму правилу.

Как быть?

Могу ошибаться, но может быть еще надо RETURN? По крайней мере при использовании MARK/CONNMARK RETURN нужно делать, иначе трафик детектируется повторно и другими классами.

убрал второе правило..т.е. по любому dscp ни чем не подменится, но 0 байт и 0 пакетов...iptables не детектит траф.

Вообще, может это из-за бриджа? как у вас организованно?

А зачем вообще DSCP? Вы дальше что-то хотите делать с трафиком? MARK не подходит? У меня все с помощью MARK. Проблем нет.

дальше на микротик и через PCQ очередь шейпить и далее приоритеты на пролетах радио.

Но не в этом дело..я могу ACCEPT или DROP поставить...результата нет.

Вот в чем беда, мне кажется iptables не так собрался..хотя все по инструкции, ядро не патчил.

Я немного поковырял ndpi. он все же определяет пакеты, но если ставить метки, классифицировать. Если ставить TOS биты или ACCEPT, DROP, то правило не срабатывает.

Нужен товарищ Vel для уточнения.

уточнение. если сначала ставить метки.

У меня дропы работали и работают вроде как. Ну по крайней мере правила такого вида

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

Счетчик так же показывает что правило работает.

 iptables -t mangle  -L -vn
Chain PREROUTING (policy ACCEPT 1950 packets, 1676K bytes)
 pkts bytes target     prot opt in     out     source               destination
  92M   57G CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore
  28M 9768M MARK       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! ctstate INVALID,UNTRACKED protocol bittorrent MARK set 0x19
  28M 9819M CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            mark match 0x19 CONNMARK save
  119  7389 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x19

Счетчик дропов маленький, так как правило дропа добавил только что, в то время как остальные еще пару дней назад.

да, да..именно это я и имел в виду... может мы не правильно друг друга поняли. c NDPI можно использовать только метки и классификацию. а дальше все уже должно идти стандартными средствами. Но если скомбинировать -m ndpi с чем-нибудь другим в одном правиле, то ничего не получится.

Ну например так тоже работает

iptables -t mangle -A PREROUTING -i eth0 -m ndpi --ip_icmp -j DROP

iptables -t mangle -L -vn
Chain PREROUTING (policy ACCEPT 42133 packets, 41M bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   180 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ndpi protocol ip_icmp

ок. система какая у вас? ядро, компиляция ядра? повторить эксперимент т.к. на моем дебиане 8.2 работает так как я и описал.

ubuntu 32 бита дома и 64 на работе. Ядро и там и там 3.16.7. Вот мой процесс сборки http://a7lanov.blogspot.ru/2014/10/ubuntu-imq-ndpi-07122014.html

я вернулся с попойки/деревни/отдыха

наверно смогу ответить на какие-нибудь вопросы.

до проверки пока дело не дошло. ядро собралось, xtables версии 2.3.1, ...xtables не собираетсся. Ниже ссылка на скрин. ругается на xt_chaos.

https://raw.githubusercontent.com/imq

Но может не собирать из сорсов? а деб установить?

Могу поделиться своими дебками.

давайте, только у меня ядро последнего апдейта.

Упс. А bzr branch lp:ubuntu/xtables-addons то уже не работает. Но есть готовые сборки там же, https://launchpad.net/ubuntu/ source/xtables-addons/2.7-2ubuntu1. У меня как раз стоит версия 2.7.2. Попробуйте тамошние бинарники. К сожалению у себя проверить только завтра смогу. Дома x64 системы нет. На работе есть тестовые виртуалки, там и проверю завтра.

тут чувак из аргентины описал проблемку с подпротоколами и мастер-протоколом - есть неоднозначные ситуации которыми хочется рулить. ИМХО разумные замечания.

Расширение для iptables теперь будет проверять версию ядерного модуля (во избежании разных глюков) и из него будет получать имена доступных протоколов.

Я немного изменил --help для match: если есть отключенные протоколы, то они будут в отдельном списке. Список в 4 колонки.

для match появится в явном виде проверка протокола и мастер-протокола, а так же проверка наличия мастер-протокола.

Для target появится set-mark/clsf по протоколу или мастер-протоколу.

Думаю за пару дней управлюсь.

я использовал ubuntu/trusty/xtables-addons

там 2.3.1

Да я заметил. На 3.17 не встали расширения версии 2.3. (которые были в репах). Пришлось в ручную ставить 2.7. Поправил в мануале.

Попробуйте поставить 2.7. В принципе на вашем ядре 2.3 должно без проблем работать (по крайней мере у меня с ядром 3.16.7 расширения 2.3 и проблем нет), но вдруг поможет.

в общем, я поставил.. только вам нужно код проверить в статье..там очепятки есть.. и что за dl=0 dl=1? я их удалил из кода и так собрал, т.к. не нашел что это.

Теперь о попугаях, iptables не детектит,nDPIReader не собрался...где-то косяк. lsmod xt_ndpi есть.

П.С. собрал по обновленной инструкции..ошибок не было

п.п.с. нуждно добавить git в установку. у меня не было.

Спасибо, поправил очепятки. В спешке при копировании не проверил. Git не было в установке, так как раньше ndpi архивный брал у ТС. Сейчас решил через гитхаб это делать. Поэтому забыл добавить git в первоначальную установку. Тоже исправил.

physdev наше все...работает ndpi )))

опция --ret не принимается iptables.

И вообще, -j NDPI как работает?

Документанция немного запутана. Я так понял, что -m ndpi конкретно определяет протоколы. Я так понял что без -j NDPI создается некая таблица, из которой нужно выйти?

--ret выпилина из -j NDPI еще в январе прошлого года.

"-j NDPI" используется для маркировки пакета (аналог -j MARK) и для классификации пакета (аналог -j CLASSIFY).

значение+маска для каждого протокола задается через /proc/net/xt_ndpi/proto http://devel.aanet.ru/ndpi/#21032015

Исправлена ошибка в NDPI --ndpi-id. Забыл инвертировать маску :(

Исправленная версия доступна на гитхабе.

Описания изменений сами знаете где.

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

Для шейпера нужно маркировать пакеты. Где может пригодиться маркировка CT ?

Можно добавить в NDPI --set-ctmark аналогичный CONNMARK

Ошибки есть, в BT точно. Все руки не доходят подправить.

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

не понял

чтобы не прогонять все пакеты, а автоматом все пакеты в соединении метить, а далее вообще создать динамические списки адресов и в обход ndpi метить трафик.

нет. Пример http-сервер: он может отдать сначала аудио, а потом видео.

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

Как отправить пакеты в нужный класс через таргет NDPI?

Вот так работает iptables -t mangle -A POSTROUTING -m ndpi --proto ssh -j CLASSIFY --set-class 2:22

Вот так не работает iptables -t mangle -A POSTROUTING -m ndpi --proto ssh -j NDPI --value 20022 --set-clsf Что я только не пытался просчитать, логику брал из мана.

«CLASSIFY --set-class 2:22» это major 0x2 minor 0x22

major и minor каждый по 16bit

В NDPI используется 32-х битная метка. Старшие 16 бит - major, младшие 16 бит - minor

"-j NDPI --value 20022" это 0x00020022

Правильно я понял, что классификация через iptables должна осуществляться одним правилом:

iptables -t mangle -A POSTROUTING -o eth0 -j NDPI --ndpi-id --set-clsf

А классы к протоколам должны быть указаны в /proc/net/xt_ndpi/proto.

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

да

Проверить можно используя "-j NDPI --ndpi-id --set-mark --set-clsf" && «iptables -t mangle -A POSTROUTING -o eth0 -m ndpi ! --unknown -j LOG»

Дописал возможность определения протокола по параметрам ip/masklen (tcp|udp):port-range:ndpi_protocol

Там такая структура уже была для TOR/skype/apple, но она была с точностью до ip/masklen.

Запустил на тестирование, если не упадет за 3-4 дня, то выложу.

Появилось немного времени для поиска ошибок и свободных 200Гб на ssd диске. Сейчас хочу записать ~180Gb трафика и проанализировать неизвестные пакеты, благо есть набор скриптов позволяющих повторить сохраненный трафик.

А разве использование стандартных средств iptables/tc для определения трафика по параметрам tcp/udp/port не нагружает меньше, чем ndpi?

В принципе есть близкий аналог в виде ipset hash ip:port и SET --map-set.

я правда пока не знаю как там с подсетями. Будет ли ipset адекватно работать с таким вариантом

10.0.0.0/8 tcp:8880:http
10.0.1.1 tcp:8880:ftp

Хотелось бы определять трафик в одном месте, а не при помощи 10 костылей.

Я просто доделал интерфейс для изменения того дерева, которое используется в nDPI для определения протокола по ip-адресам.