LINUX.ORG.RU
Форум — General  

nDPI как замена l7filter

 ,


23

17

Если кому интересно, то вот рецепт

На большом потоке ( >300мбит/с ) c большим числом протоколов (>20) используется примерно 40% одного ядра Intel(R) Xeon(R) CPU E31230@3.20GHz. Если поток больше или процессор слабее, то включаем RPS или используем сетевые карты с multi-queue и irq-affinity :)

Требуется много памяти. На каждое соединение расходуется примерно 800+264*0.7 байт.

Исходники теперь есть на https://github.com/vel21ripn/nDPI/tree/netfilter

★★★★★

Последнее исправление: vel (всего исправлений: 3)
← Загрузка CPU после обновления
bttv automute option →
  1 2 3 4 5 6 7 8 9 10 11 12
Ответ на: комментарий от as_lan

Кстати! Относительно UPD2 в мануале:

sudo apt-get build-dep iptables

The following NEW packages will be installed:
  libmnl0 libnetfilter-conntrack-dev libnetfilter-conntrack3
firebolt
()
Ответ на: комментарий от firebolt

1. Vel еще не выложил. не на что пока инструкцию писать. 2. Ну у меня сперва все собиралось на 12.04. Потом обновил систему 14.04 и там уже пришлось самому ставить этот пакет. Когда буду обновлять инструкцию этот пункт исправлю.

Кстати, ndpi трафик игры WoT распознает как bitorrent. Выяснилось на работе, когда заблокировал в рабочее время bitorrent, и при этом жаловался один из сотрудников, которому нужно было протестировать один ПК на этой игре.

as_lan ★★
()
Ответ на: комментарий от as_lan

Мануал - просто мечта

Вы написали уникальный мануал. Во всем интернете (по крайней мере, его русскоязычном сегменте) нет ничего подобного - рабочего и актуального. Давным давно не пользовался мануалами, где особо трудиться не надо, все, что пишешь, работает. Благодарен!

firebolt
()
Ответ на: комментарий от as_lan

tcpdum-ом

Только желательно с минимумом лишнего трафика.

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

А я пока исправляю в nDPI работу со строками. Там везде испольуется memcmp, а во многих случаях нужно strncasecmp.

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

Повторил все это дело на Debian Wheezy. Единственное отличие заключается в том, что apt-get build-dep iptables ничего не доставляет. Соответственно UPD2 из мануала не является актуальным. Хотя я эти библиотеки все же вручную поставил перед всеми действиями)))

firebolt
()
Ответ на: комментарий от firebolt

Говорю же, будет новый архив, будет и обновление) Причем сразу на 3 системах проверю. Ubuntu 12.04, 14.04 и последний дебиан. На Centos пока так и не удалось собрать нормальный rpm. Да и времени в последнее время не очень много.

as_lan ★★
()
Ответ на: комментарий от firebolt

А ядро 3.2 патченое было или 3.9? У меня какие-то проблемы с шейпером начинаются на 3.2 после патча imq, трафик в обход шейпера начинает идти, времени особо потестить не было.

alestro
()
Ответ на: комментарий от as_lan

Неясная проблема

При дальнейшей настройке iptables обнаружил отсутствие таблицы nat: 

# iptables -t nat -F
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

С чем может быть связана данная проблема? Она есть и в установке на Ubuntu Server и в Debian Wheezy. В обеих установках при конфигурировании ядра в make oldconfig я не вникал и на все жал Enter.

firebolt
()
Ответ на: Неясная проблема от firebolt

При сборке ядра не включили nat (не делали случаем make localmodconfig ? ) Раз не включен nat, то заодно и проверьте в разделе QOS не отключен ли htb и sfq (если вам они конечно нужны)

as_lan ★★
()
Ответ на: комментарий от firebolt

При сборке один или 2 раза у меня так же почему то был выключен NAT. Плюс потом выяснилось что еще кое какие критичные модули оказались выключенными. Но я подозревал что это чисто моя локальная проблема была, и у других не должно быть ее. Как оказалось ошибался. У меня к примеру те же SFQ и HTB были отключены. Естественно шейпер не работал. Возможно причиной, как и в вашем случае, было невнимательное чтение то что мне предлагали включить/отключить после oldconfig =)

as_lan ★★
()
Ответ на: комментарий от Imex

Я пока не выкладывал вариант без патча ядра.

Без патча оно будет работать только с ядрами 3.10 и выше. Для старых ядер патч будет обязательным.

Я с 28 декабря отмечаю НГ и только сейчас вернулся в город.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Я выложил новую версию. Основные изменения

Серьезно уменьшен объем памяти. Размер структуры flow теперь примерно 800 байт и размер ее не сильно зависит от разрядности процессора.

Для ядер 3.10 и выше не требуется патчить ядро

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

as_lan, судя по отсутствию прежней статьи по настройке, я понимаю, что появилась новая версия. Но я опять не могу ее найти. В блоге видна за январь только одна запись про занятость абонента в Asterisk. Я не умею искать? Что-то странное.

firebolt
()
Ответ на: комментарий от firebolt

я пока вернул в черновики. Статья новая есть. Но есть проблема. На рабочей машине nDpi работает, но не полностью (не работает например обнаружение icmp). В виртуалке на 14.04 вообще ничего не видит. Vel я письмо написал. Жду ответа.

as_lan ★★
()
Ответ на: комментарий от as_lan

У меня http на виртуалке детектит только на 80м порту, других портов как будто не существует. т.е правило

-A FORWARD -m ndpi --http -j ACCEPT

yalexeyka
()
Ответ на: комментарий от as_lan

У меня http на виртуалке детектит только на 80м порту, других портов как будто не существует. т.е правило

-A FORWARD -m ndpi  --http  -j ACCEPT

пропускает трафик только по 80му порту. Аналогичная ситуация с ssh. В чем может быть проблема? Пробовал как старые, так и новые сборки ndpi. Возможно ли такое повеление из за виртуалки? Из ОС пробовал Ububtu и Fedora. При этом ndpi с сайта ntop детектит нормально.

yalexeyka
()
Ответ на: комментарий от as_lan

Под какую ОС? Машина, я понимаю, физическая? На http://www2.epfr.ru:8080/ пустит если только http и dns разрешить? Как правильно написать правила iptables чтобы пропускать только http? Когда вернется syn+ack как поведет себя модуль? Надо ли правилом выше пропускать все syn+ack?

yalexeyka
()
Ответ на: комментарий от yalexeyka

Ubuntu. Машина физическая. Проверить все смогу когда буду дома. Сейчас на работе, нет возможности все в подробностях проверить.

as_lan ★★
()
Ответ на: комментарий от yalexeyka

syn+ack пропускает всегда. т.к. только по номеру порта протокол не всегда можно определить.

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

Проверил на qemu ядро 3.14.28 

wget -O /dev/zero http://10.11.188.8:4080/
Connecting to 10.11.188.8:4080 (10.11.188.8:4080)
zero                 100% |***********************************************|   152   0:00:00 ETA
# iptables -nvxL
# iptables -nvxL
Chain INPUT (policy ACCEPT 6 packets, 1024 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       4      636            all  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol http
       6     1024            all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 5 packets, 348 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       3      236            all  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol http
       5      348            all  --  *      *       0.0.0.0/0            0.0.0.0/0
По моим понятиям работает как надо.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Я правильно понимаю, что только для http правильно так:

-A FORWARD -m ndpi --dns -j ACCEPT
-A FORWARD -m ndpi --http -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -j DROP

При таких правилах должен проходить http запрос на нестандартный порт? Пока по 80 порту http летает - все хорошо, как только нестандартный, то DROP

yalexeyka
()
Ответ на: комментарий от yalexeyka

для DNS должно работать, а для всего остального через TCP - нет.

Первые syn и syn+ack попадут в DROP т.к. они еще не идентифицированы и NEW

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

на тестовой машине с ssh вроде все хорошо, а вот с icmp есть странности - оно обнаруживается в tcp и udp 8-/

vel ★★★★★
() автор топика
Ответ на: комментарий от as_lan

icmp работает тоже, но очень хитро. Cмотрю счетчики и удивляюсь. 

    2410   120956            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp
    1656   107857            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp
    7878   927267            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp
icmp пакеты содержащие в себе tcp/udp пакеты детектируются ядром и как icmp и как tcp/udp! Идея ясна, но как с этим быть - непонятно. Проблема в ядре.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Хоть убейся, но не понимаю. Почему у меня не видит.

tcpdump 

09:57:17.585900 IP 81.163.55.134 > 5-143-96-210.dynamic.primorye.net.ru: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:17.629746 IP 81.163.55.134 > 136.169.241.30: ICMP 81.163.55.134 udp port 5550 unreachable, length 66
09:57:17.707430 IP 81.163.55.134 > www.yandex.ru: ICMP echo request, id 1, seq 103, length 40
09:57:17.742307 IP www.yandex.ru > 81.163.55.134: ICMP echo reply, id 1, seq 103, length 40
09:57:17.763058 IP 81.163.55.134 > 92.47.244.164.megaline.telecom.kz: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:18.083697 IP 109.70.186.216 > 81.163.55.134: ICMP echo request, id 2, seq 2011, length 40
09:57:18.083919 IP 81.163.55.134 > 109.70.186.216: ICMP echo reply, id 2, seq 2011, length 40
09:57:18.165035 IP 81.163.55.134 > pppoe189.net31-148-50.se1.omkc.ru: ICMP 81.163.55.134 udp port 5550 unreachable, length 69
09:57:18.179039 IP 81.163.55.134 > ip-67-18.rev.kli.lt: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:18.265129 IP 81.163.55.134 > 92.43.188.10: ICMP 81.163.55.134 udp port 5550 unreachable, length 101
09:57:18.574410 IP 81.163.55.134 > ip.178-71-8-89.avangarddsl.ru: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:18.694449 IP 81.163.55.134 > 91.195.137.203: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:18.707540 IP 81.163.55.134 > www.yandex.ru: ICMP echo request, id 1, seq 104, length 40
09:57:18.741804 IP www.yandex.ru > 81.163.55.134: ICMP echo reply, id 1, seq 104, length 40
09:57:18.773552 IP 81.163.55.134 > ppp92-100-20-196.pppoe.avangarddsl.ru: ICMP 81.163.55.134 udp port 5550 unreachable, length 66
09:57:18.993926 IP 81.163.55.134 > 109-167-192-228-nat-pool-gal1.westcall.net: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:19.084625 IP 109.70.186.216 > 81.163.55.134: ICMP echo request, id 2, seq 2012, length 40
09:57:19.084729 IP 81.163.55.134 > 109.70.186.216: ICMP echo reply, id 2, seq 2012, length 40
09:57:19.404143 IP 81.163.55.134 > cpc3-cove12-2-0-cust241.3-1.cable.virginm.net: ICMP 81.163.55.134 udp port 5550 unreachable, length 56
09:57:19.708663 IP 81.163.55.134 > www.yandex.ru: ICMP echo request, id 1, seq 105, length 40
09:57:19.741482 IP www.yandex.ru > 81.163.55.134: ICMP echo reply, id 1, seq 105, length 40
09:57:19.866515 IP 81.163.55.134 > l37-194-127-134.novotelecom.ru: ICMP 81.163.55.134 udp port 5550 unreachable, length 66

iptables mangle PREROUTING 

 iptables -t mangle -L PREROUTING -vn
Chain PREROUTING (policy ACCEPT 110K packets, 7724K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa
    0     0 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa

iptables mangle POSTROUTING 

Chain PREROUTING (policy ACCEPT 4658 packets, 314K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa
    0     0 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            protocol ip_icmp MARK set 0xa

Возможно ли что в ядре что-то отключено? Ndpi попробую заново собрать.

as_lan ★★
()
Ответ на: комментарий от as_lan

Я бы тоже потестил с радостью. Да только мануал Вы сняли с публикации. Там все по-старому, кроме пропатчивания ядра?

firebolt
()
Ответ на: комментарий от firebolt

Вернул. Сильных изменений нет. Просто патчить ядро теперь нужно только в случае использования imq.

as_lan ★★
()
Ответ на: комментарий от vel 
wget -O /dev/null http://www2.epfr.ru:8080/
--2015-01-13 14:09:29--  http://www2.epfr.ru:8080/
Resolving www2.epfr.ru (www2.epfr.ru)... 79.110.251.208
Connecting to www2.epfr.ru (www2.epfr.ru)|79.110.251.208|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19043 (19K) [text/html]
Saving to: ‘/dev/null’

/dev/null                                            100%[=======================================================================================================================>]  18.60K  --.-KB/s   in 0.1s   

2015-01-13 14:09:29 (195 KB/s) - ‘/dev/null’ saved [19043/19043]

iptables -nvxL OUTPUT
Chain OUTPUT (policy ACCEPT 5470 packets, 693597 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 protocol http

Я что - то не так делаю? https://github.com/betolj/ndpi-netfilter - с этим работает.

yalexeyka
()

Собираю nDPI r8636-v3 под Debian Wheezy 7.8. Ядро 3.17.3 (64-bit), было проверено два варианта - с патчем (версия 3.4.97) и без. При сборке ndpi-netfilter выводится следующее: 

/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src/main.c:69:2: error: #error NF_CONNTRACK_LABELS not defined
/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src/main.c: In function ‘ndpi_mt_init’:
/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src/main.c:1293:22: error: ‘NF_CT_EXT_LABELS’ undeclared (first use in this function)
/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src/main.c:1293:22: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src/main.o] Ошибка 1
make[3]: *** Ожидание завершения заданий...
make[2]: *** [_module_/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src] Ошибка 2
make[2]: Leaving directory `/usr/src/linux-3.17.3'
make[1]: *** [modules] Ошибка 2
make[1]: Leaving directory `/usr/src/nDPI-1.5.1.r8636_v3/ndpi-netfilter/src'
make: *** [all] Ошибка 2
В результате в каталоге ipt создается libxt_ndpi.so, который вручную копирую в /lib/xtables. После этого делаю make modules_install, который проходит без ошибок. Но при создании правила 
iptables -A FORWARD -m ndpi --bittorrent -j DROP
пишет 
iptables: No chain/target/match by that name.
Команда 
iptables -m ndpi -h
выводит мануал нормально, включая ndpi match options. В чем может быть дело?

denmmx
()
Ответ на: комментарий от vel

Пересобрал ядро с 

CONFIG_NF_CONNTRACK=y|m
CONFIG_NF_CONNTRACK_LABELS=y
всё тоже самое. Вывод 
 grep NF_CONNTRACK_LABELS /boot/config-`uname -r`
пустой и при добавлении правила iptables:

iptables: No chain/target/match by that name.

В чем еще может быть дело?

denmmx
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11 12
← Загрузка CPU после обновления
General
bttv automute option →