[alex39x]

В 20.10.2023 в 09:11, Cramac сказал:

Такого нет, видимо надо пересобирать

Если в дальнейшем планируете лить v5 в биллинг а v9 в сорм - можно этот модуль оставить для биллинга и собрать новый ipt-netflow модуль с natevents для v9 сорм-а. При сборке просто меняете название модуля. Примерно так:

cd ipt-netflow-2.5/

find -type f -name \* -exec sed -i -r 's/netflow/netflow2/g' {} \;
find -type f -name \* -exec sed -i -r 's/NETFLOW/NETFLOW2/g' {} \;
Ещё вроде есть особенность  не собирается на последних версиях ядер.

Изменено 20 октября, 2023 пользователем alex39x

[Antares]

Цитата

Они самые:

net.netflow.sndbuf = 16777216

net.netflow.hashsize = 32768

С такими значениями у нас на бордере процент NAT-сопоставлений стал >90%. По крайней мере, со стороны МФИ больше вопросов к нам не возникало.

У нас тот же МФИ требует более 95%

Ещё одна проблемы с Flow direction. Модуль скомпилен с --enable-direction. В iptables цепочки прописаны. ХЗ что им не нравится

Было у кого подобное, как решали?

[alex39x]

В 27.10.2023 в 06:49, Antares сказал:

У нас тот же МФИ требует более 95%

Ещё одна проблемы с Flow direction. Модуль скомпилен с --enable-direction. В iptables цепочки прописаны. ХЗ что им не нравится

Было у кого подобное, как решали?

У нас всё закончилось тем что они обновили ПО на съёмнике. 

Пересборка модуля на новую версию, увеличение всяких буферов/таймаутов проблему не решало.

Изменено 27 октября, 2023 пользователем alex39x

[hsvt]

ipt_NETFLOW 2.6-17-g0eb2092

 

6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
 

[Mon Mar 25 00:32:27 2024] ipt_NETFLOW: natevents already disabled.

[Mon Apr  1 01:12:24 2024] ipt_NETFLOW: natevents already disabled.

[Mon Apr  8 01:37:53 2024] ipt_NETFLOW: natevents already disabled.

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

[sgu]

ipt_NETFLOW 2.6 последний с git-а на текущий момнет на машине с RHEL 9.3 like дистрибутивом. kernek-5.14.0-362.24.1.0.1.el9_3.x86_64
 

Сообщение ipt_NETFLOW: natevents already disabled появляется спустя пару минут после логина пользователя по ssh.

Зависимость такая: после логина пользователя активируется сервис systemd-hostnamed.

Во время завершения этого сервиса и появляется данное сообщение.

09:25:03 bras systemd[1]: systemd-hostnamed.service: Deactivated successfully.
09:25:03 bras kernel: ipt_NETFLOW: natevents already disabled.

Так-же сервис systemd-hostnamed активируется при получении рута и при выполнении команды hostnamectl.
Результат один: при завершении сервиса systemd-hostnamed появляется сообщение ipt_NETFLOW: natevents already disabled.

 

Решил проблему маскированием сервиса systemd-hostnamed. Негативного влияния от этого действия не выявлено.

[nixx]

распоследний ipt_netflow с git'а не собирается на 4.19.304 ядре, ругается на вот этот коммит https://github.com/aabc/ipt-netflow/commit/122662f5c19864e3340cc44e703ae24b75a26ca7

при возвращении "как было" нормально собирается и даже работает.

 

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

так ли это? или можно всё же отфильтровать events разных подсетей с разных модулей на разные dst?

Изменено 2 июня пользователем nixx

[Cramac]

В 04.03.2023 в 12:29, myth сказал:

шлю v9. Всё норм

не подскажите, как сливаете нетфлоу?

Собрал модуль, вроде льет все в v9, но в потоке есть разные шаблоны, как лить только в 258?

 

Скрытый текст

# modinfo ipt_NETFLOW
filename:       /lib/modules/5.15.0-43-generic/extra/ipt_NETFLOW.ko
alias:          ip6t_NETFLOW
version:        2.6-17-g0eb2092
description:    iptables NETFLOW target module
author:         <abc@openwall.com>
license:        GPL
srcversion:     9D57791DE7AEF9589512DAB
depends:        x_tables,nf_conntrack
retpoline:      Y
name:           ipt_NETFLOW
vermagic:       5.15.0-43-generic SMP mod_unload modversions
parm:           destination:export destination ipaddress:port (charp)
parm:           inactive_timeout:inactive flows timeout in seconds (int)
parm:           active_timeout:active flows timeout in seconds (int)
parm:           exportcpu:lock exporter to this cpu (int)
parm:           debug:debug verbosity level (int)
parm:           sndbuf:udp socket SNDBUF size (int)
parm:           protocol:netflow protocol version (5, 9, 10=IPFIX) (int)
parm:           refresh_rate:NetFlow v9/IPFIX refresh rate (packets) (uint)
parm:           timeout_rate:NetFlow v9/IPFIX timeout rate (minutes) (uint)
parm:           scan_min:Minimal interval between export scans (jiffies) (uint)
parm:           natevents:enable NAT Events (int)
parm:           hashsize:hash table size (int)
parm:           maxflows:maximum number of flows (int)
parm:           engine_id:Observation Domain ID (int)
 

 

тот же норси-транс просит поправить

[nixx]

скажите, а кто-нибудь использовал PMAcct в виде его демона nfacctd для приема netflow от обсуждаемого модуля?

у меня он падает хронически. может через неделю, может через месяц.

это мне "везет", или оно по жизни такое?

Debian 6, версия pmacct 1.7.7 из пакетов.

 

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

[ne-vlezay80]

В 04.07.2024 в 17:45, nixx сказал:

Debian 6, версия pmacct 1.7.7 из пакетов.

И это в 2024 году...
Попробуй актуальную версия с github'а.

[nixx]

43 минуты назад, ne-vlezay80 сказал:

И это в 2024 году...
Попробуй актуальную версия с github'а.

таки у вас работает без падений месяцами и более, или же вам просто дебиан 6 понравился? )) дебиан 12, конечно же.

[ne-vlezay80]

3 минуты назад, nixx сказал:

таки у вас работает без падений месяцами и более, или же вам просто дебиан 6 понравился? )) дебиан 12, конечно же.

а тогда по какой причине падает?