Поддержка iptables ULOG и ipfw tee/divert sockets в ndsad

Технические вопросы по UTM 5.0
aospan
NetUP Team
Сообщения: 1639
Зарегистрирован: Чт янв 13, 2005 20:30

Поддержка iptables ULOG и ipfw tee/divert sockets в ndsad

Сообщение aospan »

Для получения обновленной версии ndsad необходимо выполнить:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad co -P ndsad

как собрать с нужными опциями описано в файле INSTALL.

Реализована поддержка учета трафика собираемого через файрволлы. В линуксе это iptables и интерфейс к ULOG. Для использования необходимо добавить в файрволл правило вида:
iptables -A OUTPUT -s 10.0.0.1 -d 10.0.0.2 -j ULOG --ulog-nlgroup 13

при этом в конфиге /netup/utm5/ndsad.cfg необходимо указать строку:
ulog_group 13

В FreeBSD это ipfw и tee/divert сокеты. Для использования необходимо добавить в файрволл правила вида:
ipfw add 10 tee 21000 ip from 10.0.0.2 to 10.0.0.1

при этом в конфиге /netup/utm5/ndsad.cfg необходимо указать строку:
bsd_div_port 21000

если указываете в правилах файрволл divert вместо tee, то дополнительно в конфиге необходимо указать:
bsd_div_copy yes
иначе пакеты проходить не будут.


В обоих случаях для предотвращения дублирования в конфиге ndsad.cfg можно указать опцию:
dummy all
в этом случае трафик через libpcap с интерфейсов собираться не будет. Соответсенно будет собираться только через ULOG либо tee/divert.

Данный функционал сейчас в стадии тестирования. В случае если будут замечены проблемы либо неточности просьба писать в эту тему .

Neo_vr
Сообщения: 2
Зарегистрирован: Пн янв 30, 2006 21:55

Сообщение Neo_vr »

вчера обнаружил в логах ndsad 1.33 , юзаю диверт ....

ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>

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

Аватара пользователя
dalex
Сообщения: 1306
Зарегистрирован: Пт янв 21, 2005 11:54

Сообщение dalex »

В тему - вчера поставил статик 1.33 c sourceforge
Вроде все работает, но в логе появилось
ndsad[17662]: ULOG:can't recvfrom!
(через ulog идут пакеты с eth интерфейса). Это что за ошибка?

aospan
NetUP Team
Сообщения: 1639
Зарегистрирован: Чт янв 13, 2005 20:30

Сообщение aospan »

dalex писал(а):В тему - вчера поставил статик 1.33 c sourceforge
Вроде все работает, но в логе появилось
ndsad[17662]: ULOG:can't recvfrom!
(через ulog идут пакеты с eth интерфейса). Это что за ошибка?
попробуйте:
sysctl -w net/core/rmem_max=1048576
sysctl -w net/core/rmem_default=1048576

возможно поможет ...

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

Запостил в хотлайн тикет 2006020310000087, но там как-то тихо сягодня, coldline похоже в связи с температурой за бортом. Дублирую сюда:
Итак, ndsad собраный из cvs с интерфейсом ULOG работает
исправно. На всякий случай прописал все возможные цепочки и
сделал dummy all (как это рекомендовал aospan на форуме -
viewtopic.php?t=1729). В итоге
имею правильные отчеты по траффику и по юзерам с реальными
адресами и с серыми, но, почему-то детальный отчет можно
сформировать только для юзеров с "белыми" адресами. Вот
кусок моего фаервольного скрипта, где я выбираю траффик под
ULOG:

VPN_NET=10.10.0.0/16
VPN_REALIP=62.x.y.z/25

iptables -A INPUT -d $VPN_NET -j ULOG --ulog-nlgroup 10
iptables -A INPUT -s $VPN_NET -j ULOG --ulog-nlgroup 10
iptables -A OUTPUT -d $VPN_NET -j ULOG --ulog-nlgroup 10
iptables -A OUTPUT -s $VPN_NET -j ULOG --ulog-nlgroup 10
iptables -A FORWARD -d $VPN_NET -j ULOG --ulog-nlgroup 10
iptables -A FORWARD -s $VPN_NET -j ULOG --ulog-nlgroup 10

# REALIP

iptables -A OUTPUT -d $VPN_REALIP -j ULOG --ulog-nlgroup 10
iptables -A OUTPUT -s $VPN_REALIP -j ULOG --ulog-nlgroup 10
iptables -A INPUT -d $VPN_REALIP -j ULOG --ulog-nlgroup 10
iptables -A INPUT -s $VPN_REALIP -j ULOG --ulog-nlgroup 10
iptables -A FORWARD -d $VPN_REALIP -j ULOG --ulog-nlgroup 10
iptables -A FORWARD -s $VPN_REALIP -j ULOG --ulog-nlgroup 10

После этих правил есть еще такое:

iptables -t nat -A POSTROUTING -s $VPN_NET -o $EXTERNAL_INT
-j MASQUERADE

Тоесть VPN_NET это серая подсеть, которая "маскарадится".
Обсчет пользователей с этими адресами ведется правильно, но
детального траффика по этим адресам нету. Что посоветуете
сделать?
Добавлю от себя, что именно по такой схеме у меня работает связка ndsad+nfacctd и в БД nfacctd я вижу подробную инфу по подсети 10.10.0.0/16. А вот после того как я "отказался" от libpcap в пользу ULOG воявились грабли которые выше и описаны. Может быть порядок следования правил? Даже не знаю что делать теперь, чтобы подробные отчеты по траффику появились.

Аватара пользователя
dalex
Сообщения: 1306
Зарегистрирован: Пт янв 21, 2005 11:54

Сообщение dalex »

попробуйте:
sysctl -w net/core/rmem_max=1048576
sysctl -w net/core/rmem_default=1048576
возможно поможет ...
не помогло

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

Делюсь новой информацией:

Наконец-то "воссоздал" полный клон основного биллингового сервера с абсолютно идентичным ПО и настройками (только нет раздачи белых адресов). Установлен 17-й билд. Я продолжил эксперименты с ndsad_ulog. В моем посте выше указана проблема - нету детального отчета по траффику для подсети 10.10.0.0/16, но при этом траффик считается абсолютно верно (обычный отчет). Вот кусок debug.log во время того, как я жму кнопку "Сформировать" в админке в разделы отчеты.

Код: Выделить всё

?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call&#58; 0x2300
?Debug &#58; Feb 08 15&#58;19&#58;33 DBCtx&#58; SQL SELECT query&#58; SELECT id,t_class_name,graph_color,is_display,is_fill FROM t_class WHERE is_deleted='0'
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call finished...
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call&#58; 0x5014
?Debug &#58; Feb 08 15&#58;19&#58;33 BusClassif&#58; BusClassif&#58;&#58;giga_commit called.
?Debug &#58; Feb 08 15&#58;19&#58;33 BusClassif&#58; Comitting raw traffic ...
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; giga_commit&#58; Comitting raw traffic...
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCServer@10.10.252.254&#58; rpcf_get_traffic_detailed&#58; doing detailed report for account <0> user <0>
 Notice&#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Opening&#58; start/stop&#58; 1139396400/1139403960 slink_id&#58;0 for_all&#58;1 limit&#58;0 account_id <0>
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; get_nf&#58; iptraff.select return rows <0>.
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Fetched from active database&#58; 0 rows
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Open directory&#58; /netup/utm5/db/
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found file&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; File not matches&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found 0 raw .dbs files
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call finished...
Давайте остановимся на этих строчках:

Код: Выделить всё

?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found file&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; File not matches&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found 0 raw .dbs files
DBAGiga: Found file: iptraffic_raw.dbs - найден файл iptraffic_raw.dbs. Отлично, вот он у меня:

[utm-clone@kan5300]$ls -al /netup/utm5/db/iptraffic_raw.dbs
-rw-r--r-- 1 root root 4235264 2006-02-08 15:04 /netup/utm5/db/iptraffic_raw.dbs

?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs - тот файл, о котором писали выше не соответствует (не совпадает) с файлом iptraffic_raw.dbs

Found 0 raw .dbs files - типа dbs файлов у меня нету, значит нет и детального отчета =(.

Как же быть? Может быть уважаемые разработчики создадут на своём стенде модель аналогичную моей и проверят сей аспект работы биллинга? Я в свою очередь попробую сделать апдейт до 18-го тестового билда, благо есть теперь тестовая машина.

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

Установил 18-й тестовый билд. Ситуация не изменилась.

aospan
NetUP Team
Сообщения: 1639
Зарегистрирован: Чт янв 13, 2005 20:30

Сообщение aospan »

kaN5300 писал(а):Делюсь новой информацией:

Наконец-то "воссоздал" полный клон основного биллингового сервера с абсолютно идентичным ПО и настройками (только нет раздачи белых адресов). Установлен 17-й билд. Я продолжил эксперименты с ndsad_ulog. В моем посте выше указана проблема - нету детального отчета по траффику для подсети 10.10.0.0/16, но при этом траффик считается абсолютно верно (обычный отчет). Вот кусок debug.log во время того, как я жму кнопку "Сформировать" в админке в разделы отчеты.

Код: Выделить всё

?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call&#58; 0x2300
?Debug &#58; Feb 08 15&#58;19&#58;33 DBCtx&#58; SQL SELECT query&#58; SELECT id,t_class_name,graph_color,is_display,is_fill FROM t_class WHERE is_deleted='0'
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call finished...
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call&#58; 0x5014
?Debug &#58; Feb 08 15&#58;19&#58;33 BusClassif&#58; BusClassif&#58;&#58;giga_commit called.
?Debug &#58; Feb 08 15&#58;19&#58;33 BusClassif&#58; Comitting raw traffic ...
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; giga_commit&#58; Comitting raw traffic...
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCServer@10.10.252.254&#58; rpcf_get_traffic_detailed&#58; doing detailed report for account <0> user <0>
 Notice&#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Opening&#58; start/stop&#58; 1139396400/1139403960 slink_id&#58;0 for_all&#58;1 limit&#58;0 account_id <0>
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; get_nf&#58; iptraff.select return rows <0>.
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Fetched from active database&#58; 0 rows
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Open directory&#58; /netup/utm5/db/
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found file&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; File not matches&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found 0 raw .dbs files
?Debug &#58; Feb 08 15&#58;19&#58;33 RPCConn&#91;SSL&#93;<molokanov@10.10.13.131>&#58; Call finished...
Давайте остановимся на этих строчках:

Код: Выделить всё

?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found file&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; File not matches&#58; iptraffic_raw.dbs
?Debug &#58; Feb 08 15&#58;19&#58;33 DBAGiga&#58; Found 0 raw .dbs files
DBAGiga: Found file: iptraffic_raw.dbs - найден файл iptraffic_raw.dbs. Отлично, вот он у меня:

[utm-clone@kan5300]$ls -al /netup/utm5/db/iptraffic_raw.dbs
-rw-r--r-- 1 root root 4235264 2006-02-08 15:04 /netup/utm5/db/iptraffic_raw.dbs

?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs - тот файл, о котором писали выше не соответствует (не совпадает) с файлом iptraffic_raw.dbs

Found 0 raw .dbs files - типа dbs файлов у меня нету, значит нет и детального отчета =(.

Как же быть? Может быть уважаемые разработчики создадут на своём стенде модель аналогичную моей и проверят сей аспект работы биллинга? Я в свою очередь попробую сделать апдейт до 18-го тестового билда, благо есть теперь тестовая машина.
выборка из "текущего" файла (iptraffic_raw.dbs) осуществляется всегда т.е. на эти строки можно не обращать внимания. Проверьте, льется ли у вас трафик и увеличивается ли размер файла iptraffic_raw.dbs ?

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

выборка из "текущего" файла (iptraffic_raw.dbs) осуществляется всегда т.е. на эти строки можно не обращать внимания. Проверьте, льется ли у вас трафик и увеличивается ли размер файла iptraffic_raw.dbs ?
1) Траффик льётся (tcpdump -i lo dst port 9996)

Код: Выделить всё

09&#58;33&#58;52.365903 IP localhost.1035 > localhost.9996&#58; UDP, length 120
09&#58;33&#58;57.415913 IP localhost.1035 > localhost.9996&#58; UDP, length 312
09&#58;34&#58;15.595906 IP localhost.1035 > localhost.9996&#58; UDP, length 72
09&#58;34&#58;16.605884 IP localhost.1035 > localhost.9996&#58; UDP, length 72
09&#58;34&#58;22.665888 IP localhost.1035 > localhost.9996&#58; UDP, length 120
09&#58;34&#58;31.755892 IP localhost.1035 > localhost.9996&#58; UDP, length 696
09&#58;34&#58;33.775886 IP localhost.1035 > localhost.9996&#58; UDP, length 72
09&#58;34&#58;34.785896 IP localhost.1035 > localhost.9996&#58; UDP, length 792
09&#58;34&#58;38.825878 IP localhost.1035 > localhost.9996&#58; UDP, length 72
09&#58;34&#58;41.856257 IP localhost.1035 > localhost.9996&#58; UDP, length 1464
09&#58;34&#58;41.856386 IP localhost.1035 > localhost.9996&#58; UDP, length 696
09&#58;34&#58;42.865934 IP localhost.1035 > localhost.9996&#58; UDP, length 216
09&#58;34&#58;44.885882 IP localhost.1035 > localhost.9996&#58; UDP, length 120
09&#58;34&#58;50.945882 IP localhost.1035 > localhost.9996&#58; UDP, length 120
09&#58;35&#58;09.125883 IP localhost.1035 > localhost.9996&#58; UDP, length 72
09&#58;35&#58;12.155891 IP localhost.1035 > localhost.9996&#58; UDP, length 312
09&#58;35&#58;15.185894 IP localhost.1035 > localhost.9996&#58; UDP, length 408
09&#58;35&#58;18.215885 IP localhost.1035 > localhost.9996&#58; UDP, length 120
09&#58;35&#58;25.285918 IP localhost.1035 > localhost.9996&#58; UDP, length 120
2) Размер файла /netup/utm5/db/iptraffic_raw.dbs не увеличивается. (как раз вчера собирался промониторить, но сбежал с работы).

При всём при этом правильно работают общие отчёты по траффику, а из этого можно сделать вывод, что по netflow поступает правильная информация о траффике, который тарифицируется в соответствии с классами траффику 0.0.0.0/0.0.0.0 -> 10.10.0.0/255.255.0.0 и наоборот. Почему же может не изменяться размер файла iptraffic_raw.dbs?

aospan
NetUP Team
Сообщения: 1639
Зарегистрирован: Чт янв 13, 2005 20:30

Сообщение aospan »

Можно предположить, что у вас отмечена галочка "не сохранять" в свойствах классов трафика ?
Посмотрите в разделе Дополнительно - Статистика увеличиваются ли счетчики ?

Аватара пользователя
kaN5300
Сообщения: 480
Зарегистрирован: Пт янв 21, 2005 17:27
Откуда: Ыукзгрщм
Контактная информация:

Сообщение kaN5300 »

aospan писал(а):Можно предположить, что у вас отмечена галочка "не сохранять" в свойствах классов трафика ?
Посмотрите в разделе Дополнительно - Статистика увеличиваются ли счетчики ?
Так всё и было. Сам создал себе проблемы. Поставил когда-то галочку и забыл. Спасибо за консультацию.

Trec
Сообщения: 60
Зарегистрирован: Вт сен 27, 2005 14:13

Сообщение Trec »

Все равно не понятно как в биллинге настроить тарификацию на основе интерфейсов. Известны только dst адреса.
в /etc/sysconfig/iptables прописанны строки вида:
-A FORWARD -i eth0.2 -j ULOG --ulog-nlgroup 14
-A FORWARD -o eth0.2 -j ULOG --ulog-nlgroup 14
-A FORWARD -i eth0.3 -j ULOG --ulog-nlgroup 14
-A FORWARD -o eth0.3 -j ULOG --ulog-nlgroup 14
-A FORWARD -i eth0.4 -j ULOG --ulog-nlgroup 14
-A FORWARD -o eth0.4 -j ULOG --ulog-nlgroup 14
все строки из /netup/ntm5/ndsad.cfg
hash lo 64
hash all 32
heap 65536
log /var/log/ndsad.log
ulog_group 14
dummy all
А вот при попытки настроить биллинг даже не знаю с чего начать.
Пробую добавить в классах трафика интерфейс вида eth0.2 нажимаю Ok, после чего захожу туда снова, а там в интерфейсе стоит просто 0.
Так же не понятно, попадает ли в биллинг информация о входящем исходящем интерфейсе. Где это можно посмотреть?
Как вообще можно настроить такую схему? Видь возможность такой тарификации судя по всему в биллинге есть!

padre_cc
Сообщения: 1
Зарегистрирован: Сб мар 11, 2006 09:22

Сообщение padre_cc »

dalex писал(а):
попробуйте:
sysctl -w net/core/rmem_max=1048576
sysctl -w net/core/rmem_default=1048576
возможно поможет ...
не помогло
Решение данной проблемы так и не родилось?
Может кто нибудь скажет что это такое в принципе... а то не понятно бороться с этим или пусть гадит в логах.....

Dyr
Сообщения: 25
Зарегистрирован: Вт янв 17, 2006 12:51

Сообщение Dyr »

Neo_vr писал(а):вчера обнаружил в логах ndsad 1.33 , юзаю диверт ....

ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>
ndsad[1203]: BSD_DIV: Can't send data back to socket. Error <Message too long>

как я понял ндсад не смог отправить пакет обратно на сокет,
ето нормально ??
Аналогичная проблема.

Закрыто