Поддержка iptables ULOG и ipfw tee/divert sockets в ndsad
Поддержка iptables ULOG и ipfw tee/divert sockets в ndsad
Для получения обновленной версии 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.
Данный функционал сейчас в стадии тестирования. В случае если будут замечены проблемы либо неточности просьба писать в эту тему .
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.
Данный функционал сейчас в стадии тестирования. В случае если будут замечены проблемы либо неточности просьба писать в эту тему .
вчера обнаружил в логах 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>
как я понял ндсад не смог отправить пакет обратно на сокет,
ето нормально ??
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 писал(а):В тему - вчера поставил статик 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
- Откуда: Ыукзгрщм
- Контактная информация:
Запостил в хотлайн тикет 2006020310000087, но там как-то тихо сягодня, coldline похоже в связи с температурой за бортом. Дублирую сюда:
Добавлю от себя, что именно по такой схеме у меня работает связка ndsad+nfacctd и в БД nfacctd я вижу подробную инфу по подсети 10.10.0.0/16. А вот после того как я "отказался" от libpcap в пользу ULOG воявились грабли которые выше и описаны. Может быть порядок следования правил? Даже не знаю что делать теперь, чтобы подробные отчеты по траффику появились.Итак, 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 это серая подсеть, которая "маскарадится".
Обсчет пользователей с этими адресами ведется правильно, но
детального траффика по этим адресам нету. Что посоветуете
сделать?
- kaN5300
- Сообщения: 480
- Зарегистрирован: Пт янв 21, 2005 17:27
- Откуда: Ыукзгрщм
- Контактная информация:
Делюсь новой информацией:
Наконец-то "воссоздал" полный клон основного биллингового сервера с абсолютно идентичным ПО и настройками (только нет раздачи белых адресов). Установлен 17-й билд. Я продолжил эксперименты с ndsad_ulog. В моем посте выше указана проблема - нету детального отчета по траффику для подсети 10.10.0.0/16, но при этом траффик считается абсолютно верно (обычный отчет). Вот кусок debug.log во время того, как я жму кнопку "Сформировать" в админке в разделы отчеты.
Давайте остановимся на этих строчках:
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-го тестового билда, благо есть теперь тестовая машина.
Наконец-то "воссоздал" полный клон основного биллингового сервера с абсолютно идентичным ПО и настройками (только нет раздачи белых адресов). Установлен 17-й билд. Я продолжил эксперименты с ndsad_ulog. В моем посте выше указана проблема - нету детального отчета по траффику для подсети 10.10.0.0/16, но при этом траффик считается абсолютно верно (обычный отчет). Вот кусок debug.log во время того, как я жму кнопку "Сформировать" в админке в разделы отчеты.
Код: Выделить всё
?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call: 0x2300
?Debug : Feb 08 15:19:33 DBCtx: SQL SELECT query: SELECT id,t_class_name,graph_color,is_display,is_fill FROM t_class WHERE is_deleted='0'
?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call finished...
?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call: 0x5014
?Debug : Feb 08 15:19:33 BusClassif: BusClassif::giga_commit called.
?Debug : Feb 08 15:19:33 BusClassif: Comitting raw traffic ...
?Debug : Feb 08 15:19:33 DBAGiga: giga_commit: Comitting raw traffic...
?Debug : Feb 08 15:19:33 RPCServer@10.10.252.254: rpcf_get_traffic_detailed: doing detailed report for account <0> user <0>
Notice: Feb 08 15:19:33 DBAGiga: Opening: start/stop: 1139396400/1139403960 slink_id:0 for_all:1 limit:0 account_id <0>
?Debug : Feb 08 15:19:33 DBAGiga: get_nf: iptraff.select return rows <0>.
?Debug : Feb 08 15:19:33 DBAGiga: Fetched from active database: 0 rows
?Debug : Feb 08 15:19:33 DBAGiga: Open directory: /netup/utm5/db/
?Debug : Feb 08 15:19:33 DBAGiga: Found file: iptraffic_raw.dbs
?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs
?Debug : Feb 08 15:19:33 DBAGiga: Found 0 raw .dbs files
?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call finished...
Код: Выделить всё
?Debug : Feb 08 15:19:33 DBAGiga: Found file: iptraffic_raw.dbs
?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs
?Debug : Feb 08 15:19:33 DBAGiga: Found 0 raw .dbs files
[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 писал(а):Делюсь новой информацией:
Наконец-то "воссоздал" полный клон основного биллингового сервера с абсолютно идентичным ПО и настройками (только нет раздачи белых адресов). Установлен 17-й билд. Я продолжил эксперименты с ndsad_ulog. В моем посте выше указана проблема - нету детального отчета по траффику для подсети 10.10.0.0/16, но при этом траффик считается абсолютно верно (обычный отчет). Вот кусок debug.log во время того, как я жму кнопку "Сформировать" в админке в разделы отчеты.
Давайте остановимся на этих строчках:Код: Выделить всё
?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call: 0x2300 ?Debug : Feb 08 15:19:33 DBCtx: SQL SELECT query: SELECT id,t_class_name,graph_color,is_display,is_fill FROM t_class WHERE is_deleted='0' ?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call finished... ?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call: 0x5014 ?Debug : Feb 08 15:19:33 BusClassif: BusClassif::giga_commit called. ?Debug : Feb 08 15:19:33 BusClassif: Comitting raw traffic ... ?Debug : Feb 08 15:19:33 DBAGiga: giga_commit: Comitting raw traffic... ?Debug : Feb 08 15:19:33 RPCServer@10.10.252.254: rpcf_get_traffic_detailed: doing detailed report for account <0> user <0> Notice: Feb 08 15:19:33 DBAGiga: Opening: start/stop: 1139396400/1139403960 slink_id:0 for_all:1 limit:0 account_id <0> ?Debug : Feb 08 15:19:33 DBAGiga: get_nf: iptraff.select return rows <0>. ?Debug : Feb 08 15:19:33 DBAGiga: Fetched from active database: 0 rows ?Debug : Feb 08 15:19:33 DBAGiga: Open directory: /netup/utm5/db/ ?Debug : Feb 08 15:19:33 DBAGiga: Found file: iptraffic_raw.dbs ?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs ?Debug : Feb 08 15:19:33 DBAGiga: Found 0 raw .dbs files ?Debug : Feb 08 15:19:33 RPCConn[SSL]<molokanov@10.10.13.131>: Call finished...
DBAGiga: Found file: iptraffic_raw.dbs - найден файл iptraffic_raw.dbs. Отлично, вот он у меня:Код: Выделить всё
?Debug : Feb 08 15:19:33 DBAGiga: Found file: iptraffic_raw.dbs ?Debug : Feb 08 15:19:33 DBAGiga: File not matches: iptraffic_raw.dbs ?Debug : Feb 08 15:19:33 DBAGiga: Found 0 raw .dbs files
[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
- Откуда: Ыукзгрщм
- Контактная информация:
1) Траффик льётся (tcpdump -i lo dst port 9996)выборка из "текущего" файла (iptraffic_raw.dbs) осуществляется всегда т.е. на эти строки можно не обращать внимания. Проверьте, льется ли у вас трафик и увеличивается ли размер файла iptraffic_raw.dbs ?
Код: Выделить всё
09:33:52.365903 IP localhost.1035 > localhost.9996: UDP, length 120
09:33:57.415913 IP localhost.1035 > localhost.9996: UDP, length 312
09:34:15.595906 IP localhost.1035 > localhost.9996: UDP, length 72
09:34:16.605884 IP localhost.1035 > localhost.9996: UDP, length 72
09:34:22.665888 IP localhost.1035 > localhost.9996: UDP, length 120
09:34:31.755892 IP localhost.1035 > localhost.9996: UDP, length 696
09:34:33.775886 IP localhost.1035 > localhost.9996: UDP, length 72
09:34:34.785896 IP localhost.1035 > localhost.9996: UDP, length 792
09:34:38.825878 IP localhost.1035 > localhost.9996: UDP, length 72
09:34:41.856257 IP localhost.1035 > localhost.9996: UDP, length 1464
09:34:41.856386 IP localhost.1035 > localhost.9996: UDP, length 696
09:34:42.865934 IP localhost.1035 > localhost.9996: UDP, length 216
09:34:44.885882 IP localhost.1035 > localhost.9996: UDP, length 120
09:34:50.945882 IP localhost.1035 > localhost.9996: UDP, length 120
09:35:09.125883 IP localhost.1035 > localhost.9996: UDP, length 72
09:35:12.155891 IP localhost.1035 > localhost.9996: UDP, length 312
09:35:15.185894 IP localhost.1035 > localhost.9996: UDP, length 408
09:35:18.215885 IP localhost.1035 > localhost.9996: UDP, length 120
09:35:25.285918 IP localhost.1035 > localhost.9996: UDP, length 120
При всём при этом правильно работают общие отчёты по траффику, а из этого можно сделать вывод, что по netflow поступает правильная информация о траффике, который тарифицируется в соответствии с классами траффику 0.0.0.0/0.0.0.0 -> 10.10.0.0/255.255.0.0 и наоборот. Почему же может не изменяться размер файла iptraffic_raw.dbs?
Все равно не понятно как в биллинге настроить тарификацию на основе интерфейсов. Известны только 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.
Так же не понятно, попадает ли в биллинг информация о входящем исходящем интерфейсе. Где это можно посмотреть?
Как вообще можно настроить такую схему? Видь возможность такой тарификации судя по всему в биллинге есть!
в /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.
Так же не понятно, попадает ли в биллинг информация о входящем исходящем интерфейсе. Где это можно посмотреть?
Как вообще можно настроить такую схему? Видь возможность такой тарификации судя по всему в биллинге есть!
Аналогичная проблема.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>
как я понял ндсад не смог отправить пакет обратно на сокет,
ето нормально ??