LINUX.ORG.RU
ФорумAdmin

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

 , ,


14

12

Продолжение длинной истории

Оригинальный рецепт для тех кто умеет самостоятельно прикладывать патчи и собирать ядра/софт.

Отдельно и более подробно для Ubuntu и CentOS от as_lan

На большом потоке ( ~300мбит/с ) cо всеми протоколами используется примерно 50-60% одного ядра Intel(R) Xeon(R) CPU E31230@3.20GHz. Если поток больше или процессор слабее, то включаем RPS или используем сетевые карты с multi-queue и irq-affinity. У меня оно тестируется на трафике до 400Мбит/~100к conntrack/~90kpps для x86 и x86_64.

В понятиях netfilter оно умеет проверять пакеты на принадлежность к протоколам (match) и ставить на пакеты метки/классы (target) по аналогии с MARK & CLASSIFY. Есть поддержка NET_NS и IPv6.

Требуется много памяти. На каждое соединение расходуется примерно ~850+280*0.7 байт. Этот объем варьируется в зависимости от 32/64 бита, с/без IPv6.

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

От основной ветки на github/ntop/nDPI/1.7-stable отличается меньшим потреблением памяти и «улучшением» определения bittorrent.

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

★★★★★

all - это все кроме unknown

есть еще any - это вообще все. Не помню зачем делал.

Нужно еще посмотреть на всякий мусор и ошибки. Оно не unknown и на него действует invert.

но на http://devel.aanet.ru/ndpi/ написано было:

Разница между all и any: all включает unknown, а any - нет.

и в iptables у меня any не отрабатывает вообще, ругается...

stasn77
()

«улучшением» определения bittorrent.

Почему они не хотят внести это в основную ветку?

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

Перепутал немного - any можно использовать только в /proc/net/xt_ndpi/proto

В "-m ndpi --all" unknown не входит.

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

Для улучшений нужно хранить историю ( bt_hash ). Они год назад отказались от этого.

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

vel ★★★★★
() автор топика

Сегодня опять пытался разобраться с bitorrent. Выяснилось, что детектируется точно транзитный трафик utorrent (как шифрованный так и без шифрования). Но вот трафик rtorrent, который крутится на шлюзе не ловит нормально. Ни исходящий, ни входящий. Ни с шифрованием, ни без. Иногда ловит первые 100-300мБайт. Но потом резко перестает определять, и из 45мбит торрент трафика, распознает только 2-5мбит. Есть ли смысл мне собрать трафик, чтоб мы могли взглянуть?

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

гм. вот это совсем странно.

Если не очень влом, то собери. Только сначала нужно запустить сбор, а потом запускать локальный торрент и собирать только локальный трафик. Собрать хотя бы гиг.

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

Я уже собрал. Так и сделал (сперва tcpdump потом rtorrent). Там вроде как только локальный. Размер 2 гига. При этом по iptables видно что под bitorrent попало в сумме только 1 гиг (700 на входящий и 300 исходящий). размер скаченного тоже 2 гига. Сейчас еще протестирую rtorrent на другой машине. Хочу понять это косяк потому что трафик с локальной машины, или потому что rtorrent используется. Одним словом куда копать.

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

IMHO не должно быть разницы локальный/транзитный трафик.

посмотри почту.

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

Установил на шлюз rtorrent с принудительным шифрованием. Подтверждаю, что попадаются некоторые пиры, которые не детектятся как торрент. Все offload'ы отключал где только можно, nf_conntrack_checksum включал, state INVALID дропаю до правил с ndpi.

Все случаи, что я видел - это исключительно TCP.

stasn77
()

Обновил версию.

Исправлена ошибка при работе с bittorrent/udp из-за которой часть пакетов BT определялась и как BT и как unknown

vel ★★★★★
() автор топика

А зачем нужен этот nDPI? где применяется? объясните для нуба. Неужели что бы резать трафик торренты/впн и тд?

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

до этого я пока не успел дойти.

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

у меня основное применение - приоритизация трафика.

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

++
Я так же раскидываю по приоритетам. Иными словами шейпер. Использовал на предыдущем месте работы. Планирую и на новом. Но для ограничения тоже годиться. Жаль что не все протоколы работают. Но 70-80% необходимого мне там есть.

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

а, да. Закрывающую скобку после !ip6h нужно переставить перед «return NDPI_PROCESS_ERROR» сегодня выложу подправленное.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel
sysctl -a | grep conntrack | grep timeout
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
as_lan ★★
()
Ответ на: комментарий от stasn77

шифрованный без dht не определить.

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

версия с коротким nf_conntrack_tcp_timeout_established неподтвердилась.

Я пока пытаюсь понять как бороться с conntrack.

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

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

as_lan ★★
()

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

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

Теоретически при компиляции можно попробовать закомментировать часть протоколов src/include/ndpi_protocol_ids.h. После этого в ndpi-netfilter/Makefile заремить отключенные протоколы и возможно оно соберется. Но скорее всего придется добавлять заглушки в файлы протоколов в виде функции

struct proto <название_протокола>_search() {
return NDPI_PROTOCOL_NULL;
}
И не забыть все упоминания протокола сделать условной трансляцией. Тогда и Makefile не придется изменять.

Если это кому-то очень нужно, то пускай займется этим. Задача простая, знания C нужны минимальные. Но объем работы большой. Нужно сделать форк на github-e исправить и оформить issue. Модульность вещь полезная и такие изменения скорее всего сразу примут.

А запретить детектить - запросто

echo "http disable" >/proc/net/xt_ndpi/proto

Только делать это нужно до добавления правил iptables!

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

После 5 дней тестов могу уже точно сказать, что проблема с определением bitorrent в моем случае была в ... портах на которых работал торрент клиент! Уже перепробовав все заметил что трафик rtorrent на машине за шлюзом определяется нормально. Быстро и точно. Решил весь конфиг снести и заново по одному параметру настроить. В итоге когда включил рандомные порты, трафик начал определяться! Поменял на другие, но уже прописал их в конфиге и все так же определяется трафик. Проблема хоть и решилась, но вопросов теперь еще больше.

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

Вроде бы нет. 5550-5555 стоял диапазон. Клиент занимал в основном 5550.

as_lan ★★
()

При включении на входящих картах generic-receive-offload (gro on) резко падает процент пакетов детектируемых хоть как либо модулем ndpi. Можно ли как-то изменить это?

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

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

Когда приходит нелинейный (lro/gro) пакет > mtu, то он отбрасывается. По-умолчанию «mtu» 1520. Я бы больше 8К не стал ставить.

Параметр можно менять без перезагрузки модуля через

echo XXXX >/sys/module/xt_ndpi/parameters/mtu

Если пакет отброшен из-за длины, то увеличивается параметр jumbo. Посмотреть можно через «cat /sys/module/xt_ndpi/parameters/jumbo»

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

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

Закрутил для теста mtu аж до 64К, чтобы jumbo перестали расти совсем.Несколько часов теста - память вроде не течет.

stasn77
()

Анализируя содежимое файлика /proc/net/xt_ndpi/info обнаружил странности - в нем почти вся моя сетка /24 с одним и тем же портом (520), чего не может быть :(

Есть кое-какие подозрения, но чтоб их проверить придется долго и нудно собирать и анализировать трафик.

vel ★★★★★
() автор топика

Обнаружено, что не определяются подпротоколы http!

на github внес исправления.

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

C 4.3.1 ядром не собирается (

/opt/src/nDPI-git/ndpi-netfilter/src/main.c: In function 'seq_print_ndpi':
/opt/src/nDPI-git/ndpi-netfilter/src/main.c:973:15: error: void value not ignored as it ought to be
        return ct_ndpi && ct_ndpi->proto.protocol ?
               ^
/opt/src/nDPI-git/ndpi-netfilter/src/main.c:975:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

С 4.2.7 все норм. До коммита собиралось и с 4.3.

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

О! 4.3.1 еще не вышло судя по kernel.org. Но я подожду до выхода 4.3.3.

удали всю функцию seq_print_ndpi (с #ifdef NF_CT_CUSTOM до него и #endif за ним) и строку ".seq_print = seq_print_ndpi,"

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 2)
Ответ на: комментарий от vel

Скоро выйдет, это 4.3.1-rc1. )

Я на тестовой машинке обкатываю все новое перед тем как в бой пускать, заодно проверяю что собирается с новыми ядрами, а что нет.

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

Будем ждать... В основном для детектирования BT и использую. Как-то что-то определяет, но насколько полно и точно - сказать сложно.

P.S. после выпиливания функции с 4.3 собралось, спасибо.

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

удали всю функцию seq_print_ndpi (с #ifdef NF_CT_CUSTOM до него и #endif за ним) и строку ".seq_print = seq_print_ndpi,"

Это важная функция, что она делает? Без нее ничего принципиально не «поломается»?

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

А если не запрещать детектить не нужные протоколы

echo "http disable" >/proc/net/xt_ndpi/proto

Это дает какую-то нагрузку?

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

да.

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

В явном виде нет информации о зависимости одного протокола от других.

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

Установил я nDPI. Но что-то мало трафика он детектит.

~# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 94M packets, 85G bytes)
1516K  101M ndpi_p2p   all  --  ppp+   *       10.193.0.0/16        0.0.0.0/0            ctstate NEW
  94M   85G 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
 512K   44M ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol bittorrent
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol directconnect
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol fasttrack
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol edonkey
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol gnutella
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol applejuice
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol filetopia
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol openft
    0     0 ndpi_p2p_mark  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi protocol soulseek

Chain ndpi_p2p_mark (9 references)
 pkts bytes target     prot opt in     out     source               destination
 512K   44M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x1
 256K   22M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.50000000000
 256K   22M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x2

Эти счетчики говорят о количетсве скаченной информации? Или как проверить что оно работает?

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

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

1516K 101M ndpi_p2p all  — ppp+ * 10.193.0.0/16 0.0.0.0/0 ctstate NEW

IMHO это только новые входящие пакеты.

vel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.