Добрый день!
Возникла необходимость перенести сбор статистики netflow с Mikrotik непосредственно на сервера Nodeny.
Общая информация
OS: FreeBSD 12.1
Nodeny:
```
$ svn info
Path: .
Working Copy Root Path: /usr/local/nodeny
URL: svn://nodeny-plus.com.ua/release/next
Relative URL: ^/next
Repository Root: svn://nodeny-plus.com.ua/release
Repository UUID: 2dcad6c2-3daf-43f6-9252-ff095f4c085f
Revision: 604
Node Kind: directory
Schedule: normal
Last Changed Author: sv
Last Changed Rev: 604
Last Changed Date: 2020-02-14 18:24:42 +0200 (Fri, 14 Feb 2020)
# Успешно работающая конфигурация
* Две БД: отдельно основная, отдельно трафик, конфигурация на серверах Nodeny:
cat /usr/local/nodeny/sat.cfg
package cfg;
$Passwd_Key = '********';
$Db_server = 'aaa.bbb.ccc.ddd';
$Db_name = 'nodeny';
$Db_user = '********';
$Db_pw = '********';
$Db_connect_timeout = 5;
$Trf_Db_server = 'aaa.bbb.ccc.eee';
$Trf_Db_name = 'nodeny_traffic';
$Trf_Db_user = '********';
$Trf_Db_pw = '********';
$Trf_Db_connect_timeout = 5;
* Экспорт netflow с Mikrotik.
* Приём стандартным способом:
/usr/local/bin/flow-capture \
-R /var/db/flows/netflow_8888.pl \
-p /var/run/flowtools/flow-capture.pid \
-w /var/db/flows \
-n1 -N0 \
0.0.0.0/0.0.0.0/8888
```
* Модуль `netflow`, `/usr/local/nodeny/kernel/_collectors.cfg`
```
# Сбор статистики трафика
run => 0,
period => 60,
# detailed statistic
detail => 1,
# round when insert into DB; 0 - do not round
round_minutes => 5,
list => [
{
type => 'netflow',
port => '8888',
flow_base => '/var/db/flows/',
capture_pid => '/var/run/flowtools/flow-capture.pid',
ext_iface => '24',
},
],
```
# Попытка собирать с помощью ng_netflow
Конфигурация серверов Nodeny наливается строго из системы управления конфигурациями, поэтому можно утверждать, что строго идентична, за исключением следующих изменений:
`/boot/loader.conf`:
```
...
netgraph_load="YES"
ng_ipfw_load="YES"
ng_ksocket_load="YES"
ng_netflow_load="YES"
ng_socket_load="YES"
...
`/usr/local/etc/ng_netflow.conf`
```
mkpeer ipfw: netflow 100 iface0
name ipfw:100 netflow
msg netflow: setdlt { iface = 0 dlt = 12 }
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow:export connect inet/127.0.0.1:8888
msg netflow: settimeouts { inactive=20 active=40 }
`ipfw`:
...
00420 ngtee 100 ip from any to any
...
00510 ngtee 100 ip from any to any
`/usr/local/nodeny/kernel/_collectors.cfg`
Убрана строка фильтра по интерфейсу. Пробовал также вариант с установленной, интерфейс определял с помощью способа, найденного на просторах этого форума: `flow-stat -f 17 < /var/db/flows/8888.txt`.
# Проблема
В этом варианте очень странно (и неполно?) отображается трафик в Nodeny.
Было:
скрин 1
Стало:
скрин 2
# Диагностика
* Статистика netflow доходит до коллектора, в репорте вижу нечто, похожее на вменяемые данные:
flow-print < /var/db/flows/tmp-v05.*
...
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 38861 10044 216 4
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 56007 80 6173 141
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 56896 443 22302 63
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 51290 443 219 3
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 43713 16759 1126 5
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 52420 443 2887 17
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 43092 443 135 2
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 52419 443 2887 17
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 49365 10041 164 3
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 17 0 0 38412 49
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 37777 63212 7475 34
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX 6 39048 10033 164 3
* В логах модуля `collector` вижу тоже вроде бы нормальную работу:
/usr/local/bin/flow-export: Exported 85128 records
Получили данные от netflow:
INSERT DELAYED INTO Z2020_9_21 (uid,time,bytes,class,direction,uip,ip,port,proto) VALUES ... (rows: 36)
UPDATE users_trf SET actual=0 , in1=in1+'4170', out1=out1+'0' WHERE uid='22637'
Строк: 1. Время выполнения sql: 0.0007 сек
UPDATE users_trf SET actual=0 , in1=in1+'1358', out1=out1+'0' WHERE uid='19243'
Строк: 1. Время выполнения sql: 0.0005 сек
UPDATE users_trf SET actual=0 , in1=in1+'4170', out1=out1+'0' WHERE uid='23749'
Строк: 1. Время выполнения sql: 0.0006 сек
UPDATE users_trf SET actual=0 , in1=in1+'432', out1=out1+'0' WHERE uid='24986'
Строк: 1. Время выполнения sql: 0.0006 сек
UPDATE users_trf SET actual=0 , in1=in1+'216', out1=out1+'0' WHERE uid='16387'
Строк: 1. Время выполнения sql: 0.0006 сек
INSERT INTO X2020_9_21 (uid,iface,class,time,`in`,`out`) VALUES ... (rows: 9)
UPDATE users_trf SET traf1=in1+out1
Строк: 24747. Время выполнения sql: 0.0188 сек
UPDATE users_trf SET traf2=in2+out2
Строк: 24747. Время выполнения sql: 0.0180 сек
UPDATE users_trf SET traf3=in3+out3
Строк: 24747. Время выполнения sql: 0.0178 сек
UPDATE users_trf SET traf4=in4+out4
Строк: 24747. Время выполнения sql: 0.0177 сек
Table 'nodeny_traffic.user_grp' doesn't exist
{
'sql' => 'SELECT g.grp_maxflow, u.id FROM user_grp g LEFT JOIN users u ON g.grp_id=u.grp WHERE g.grp_maxflow>0 AND u.state<>\'off\'',
'param' => []
};
За исключением сообщения "Table 'nodeny_traffic.user_grp' doesn't exist". Это выглядит странным, что модуль пытается искать эту таблицу в БД с трафиком, в то время, как она находится в основной БД (конфигурация sat.cfg приведена выше).
* Однако в БД вижу, что с момента переключения в таблице `X2020_9_21`, похоже, перестали появляться данные части пользователей, при том, что часть записей по прежнему есть:
MariaDB [nodeny_traffic]> select FROM_UNIXTIME(time),uid,`class`,`in`,`out` from X2020_9_21 order by time desc limit 10;
+---------------------+-------+-------+-------+-----+
| FROM_UNIXTIME(time) | uid | class | in | out |
+---------------------+-------+-------+-------+-----+
| 2020-09-21 12:50:00 | 18356 | 1 | 1390 | 0 |
| 2020-09-21 12:50:00 | 16387 | 1 | 216 | 0 |
| 2020-09-21 12:50:00 | 656 | 1 | 320 | 0 |
| 2020-09-21 12:50:00 | 24986 | 1 | 4290 | 0 |
| 2020-09-21 12:50:00 | 22637 | 1 | 12637 | 0 |
| 2020-09-21 12:50:00 | 19243 | 1 | 4074 | 0 |
| 2020-09-21 12:50:00 | 0 | 4 | 0 | 0 |
| 2020-09-21 12:50:00 | 0 | 3 | 0 | 0 |
| 2020-09-21 12:50:00 | 0 | 2 | 0 | 0 |
| 2020-09-21 12:50:00 | 0 | 1 | 0 | 0 |
+---------------------+-------+-------+-------+-----+
* В таблицу `Z2020_9_21` данные также поступают, однако консистентности оценить не могу:
[nodeny_traffic]> select uid,FROM_UNIXTIME(time),bytes,direction,class,INET_NTOA(uip),INET_NTOA(ip),port,proto from Z2020_9_21 order by time desc limit 100;
+-------+---------------------+-------+-----------+-------+-----------------+-----------------+------+-------+
| uid | FROM_UNIXTIME(time) | bytes | direction | class | INET_NTOA(uip) | INET_NTOA(ip) | port | proto |
+-------+---------------------+-------+-----------+-------+-----------------+-----------------+------+-------+
| 24986 | 2020-09-21 12:50:00 | 643 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 22637 | 2020-09-21 12:50:00 | 52 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 22637 | 2020-09-21 12:50:00 | 643 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 24986 | 2020-09-21 12:50:00 | 643 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 24986 | 2020-09-21 12:50:00 | 216 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 24986 | 2020-09-21 12:50:00 | 707 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 22637 | 2020-09-21 12:50:00 | 52 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 24986 | 2020-09-21 12:50:00 | 164 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
| 24986 | 2020-09-21 12:50:00 | 52 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 80 | 6 |
...
| 771 | 2020-09-21 11:40:00 | 60 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 59678 | 17 |
| 23602 | 2020-09-21 11:40:00 | 180 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 36558 | 6 |
| 771 | 2020-09-21 11:40:00 | 62 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 50678 | 17 |
| 22352 | 2020-09-21 11:40:00 | 448 | 1 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49373 | 6 |
| 13112 | 2020-09-21 11:40:00 | 448 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 | 6 |
| 13112 | 2020-09-21 11:40:00 | 448 | 1 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 | 6 |
| 13324 | 2020-09-21 11:40:00 | 448 | 2 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49356 | 6 |
| 22624 | 2020-09-21 11:40:00 | 448 | 2 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49371 | 6 |
| 13112 | 2020-09-21 11:40:00 | 448 | 1 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 | 6 |
| 22352 | 2020-09-21 11:40:00 | 448 | 2 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49373 | 6 |
| 14409 | 2020-09-21 11:40:00 | 608 | 2 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49361 | 6 |
| 13407 | 2020-09-21 11:40:00 | 304 | 2 | 2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 8003 | 6 |
| 771 | 2020-09-21 11:40:00 | 65 | 2 | 1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 26064 | 17 |
```
* На данный момент для чистоты эксперимента все экспортеры трафика, кроме тестируемой схемы, отключены.
# Вопросы
* Нормально ли появление сообщения "Table 'nodeny_traffic.user_grp' doesn't exist" в логах `collector`?
* Что может быть причиной, как устранить или как диагностировать далее?
отсутсвие таблицы user_grp не должно влиять на продстчет трафика, она задействована в куске кода блокировки пользователей по превышению потоков.
Насчет интерфейса с номером 24 правильное замечание, скорее всего проблема в неверном номере. Поможет понять ситуацию просмотр дампа нетфлоу (не в бд, а от коллектора)