По вопросу статистики в общем, и netflow в частности, есть довольно много довольно обширных статей (изучение которых требует приличного времени). Здесь я приведу свои скрипты as-is для не очень сложного ТЗ по сбору и отправке месячной статистики арендаторам.
Несколько арендаторов получают интернет через NAT (сам NAT завязан через policy-routing на двух провайдеров). У каждого арендатора свой вилан. Вилан «разворачивается» в сеть арендатора через управляемый коммутатор. Каждому арендатору выдаётся свой сегмент локальной сети с запретом ходить в соседние сегменты.
Задача: сказать каждому арендатору и управляющему зданием в конце месяца сколько он съел интернетов и ткнуть на тех пользователей, кто перепользовал слишком много трафика. Т.е. нам нужны: суммарная статистика по сегменту, потребление интернета каждым адресом (destination) в учитываемой сети.
Инструменты: используется netflow на циске, flow-tools на линуксе, MTA, cron.
Маршрутизатор объединяет информацию о похожих пакетах в течения (flows). Похожими считаются пакеты с одинаковой комбинацией src/dst IP/port. Т.е. ip-пакеты файла, скачанного с файлопомойки будут объединены в одно течение. Информация о каждом течении включает в себя от кого кому (4 поля, адрес и порт), количество пакетов, интерфейс, через который пакет отправили, размер переданных данных и время (timestamp). Эти данные отсылаются периодически в udp-пакетах на коллектор — сервер, готовый принять эти данные. Понятно, что коллектор может собирать данные от нескольких отправителей, так что при сохранении данных туда обычно ещё пишут и отправителя. Нужно понимать, что статистика собирается на всех портах, где сказано её собирать. Если сказать «собирать всё на всех портах», то трафик будет посчитан дважды — в момент приёма (как входящий) и в момент отправки в интерфейс клиента (как исходящий). К счастью, nat'ирование происходит между приёмкой и отправкой, так что при NAT'е мы будем внутренние адреса видеть в flows только для одного (внутреннего) интерфейса.
Не буду её цитировать целиком, покажу только часть, относящуюся к netflow (т.е. опущены ACL'ы, NAT, DHCP для попросивших его и т.д.), кроме того, показан только один интерфейс арендатора (остальные строго по аналогии):
Как понятно, vlan31 (192.168.31/24) — арендаторы, аналогично ± остальные арендаторы. Vlan255 — Vlan, через который отправлять данные (служебный). Остальные значения понятны и так. (обратите внимание на версию netflow, flow-tools не поддерживают 9ую версию).
Его нужно установить (для дебиана:
Обратите внимание: netflow жрёт МНОГО места. Приготовьтесь к десяткам гигабайт данных, которые ещё и хранить нужно. Лучше эти данные класть на отдельном разделе.
Собственно, именно это и есть тема статьи. Нам нужно настроить во-первых фильтры по которым мы будем отбирать информацию, а во-вторых скрипт, который эту информацию отправит кому надо. В настоящий момент арендаторов не очень много, так что для каждого всё конфигурируется отдельно.
Фильтры нужны для программы flow-nfilter, которая принимает на вход двоичный flow, фильтрует его и выдаёт на выход опять же двоичный flow.
Фильтры в /etc/flow-tools/cfg/filter.cfg. Состоят из примтивов (грубо говоря, названия для элементов фильтра) и фильтров. При вызове flow-nfilter ему указывается имя фильтра, по которому фильтровать.
Вот пример для двух арендаторов:
Собственно, основное:
Ключевые моменты: скрипт отправляет статистику за прошлый месяц. (спасибо соответствующей опции date). flow обрабатывается дважды (меня скорость пока устраивает, если начнёт тормозить, нужно будет делать фильтрацию в файл и запускать два отчёта раздельно). Первая обработка даёт нам человекочитаемую цифру в мегабайтах, вторая — табличку о том, кто сколько жрёт.
При необходимости (конфликте/споре) можно будет руками (с помощью flow-print и grep) выдать полную статистику по каждой цепочке.
Я использую фичи cron'а в debian, это чуть более удобно обычного в unix — у него есть каталог /etc/cron.monthly. В нём файл /etc/cron.monthly/rent-acc:
Этот файл, заодно, является и файлом конфигурации для арендаторов (однако, фильтры для новых нужно руками прописывать!). Не забываем про chmod +x на этот файл.
Выглядит примерно вот так:
Обратите внимание, что оказание услуг связи требует лицензии. Единственная лазейка — перевыставление счёта от провайдера за услуги. Именно для этого и нужно считать статистику. Однако, всё вышенаписанное не является сертифицированным биллингом, т.е. требует некоего дружелюбия со стороны платящего.
Вводная
Несколько арендаторов получают интернет через NAT (сам NAT завязан через policy-routing на двух провайдеров). У каждого арендатора свой вилан. Вилан «разворачивается» в сеть арендатора через управляемый коммутатор. Каждому арендатору выдаётся свой сегмент локальной сети с запретом ходить в соседние сегменты.
Задача: сказать каждому арендатору и управляющему зданием в конце месяца сколько он съел интернетов и ткнуть на тех пользователей, кто перепользовал слишком много трафика. Т.е. нам нужны: суммарная статистика по сегменту, потребление интернета каждым адресом (destination) в учитываемой сети.
Инструменты: используется netflow на циске, flow-tools на линуксе, MTA, cron.
Теория
Маршрутизатор объединяет информацию о похожих пакетах в течения (flows). Похожими считаются пакеты с одинаковой комбинацией src/dst IP/port. Т.е. ip-пакеты файла, скачанного с файлопомойки будут объединены в одно течение. Информация о каждом течении включает в себя от кого кому (4 поля, адрес и порт), количество пакетов, интерфейс, через который пакет отправили, размер переданных данных и время (timestamp). Эти данные отсылаются периодически в udp-пакетах на коллектор — сервер, готовый принять эти данные. Понятно, что коллектор может собирать данные от нескольких отправителей, так что при сохранении данных туда обычно ещё пишут и отправителя. Нужно понимать, что статистика собирается на всех портах, где сказано её собирать. Если сказать «собирать всё на всех портах», то трафик будет посчитан дважды — в момент приёма (как входящий) и в момент отправки в интерфейс клиента (как исходящий). К счастью, nat'ирование происходит между приёмкой и отправкой, так что при NAT'е мы будем внутренние адреса видеть в flows только для одного (внутреннего) интерфейса.
Конфигурация маршрутизатора
Не буду её цитировать целиком, покажу только часть, относящуюся к netflow (т.е. опущены ACL'ы, NAT, DHCP для попросивших его и т.д.), кроме того, показан только один интерфейс арендатора (остальные строго по аналогии):
interface Vlan31 description RENT: OOO AVTOTRADE room 315,316,317,318 ip address 192.168.31.1 255.255.255.0 ip flow ingress ip flow egress ip nat inside ip flow-export source Vlan255 ip flow-export version 5 ip flow-export destination 192.168.255.254 3000
Как понятно, vlan31 (192.168.31/24) — арендаторы, аналогично ± остальные арендаторы. Vlan255 — Vlan, через который отправлять данные (служебный). Остальные значения понятны и так. (обратите внимание на версию netflow, flow-tools не поддерживают 9ую версию).
Конфигурация flow-tools
Приёмник
Его нужно установить (для дебиана:
aptitude install flow-tools). Настройки в /etc/flow-tools/capture.conf:-w /srv/netflow/ 0/0/3000
Обратите внимание: netflow жрёт МНОГО места. Приготовьтесь к десяткам гигабайт данных, которые ещё и хранить нужно. Лучше эти данные класть на отдельном разделе.
Обработка статистики
Собственно, именно это и есть тема статьи. Нам нужно настроить во-первых фильтры по которым мы будем отбирать информацию, а во-вторых скрипт, который эту информацию отправит кому надо. В настоящий момент арендаторов не очень много, так что для каждого всё конфигурируется отдельно.
Фильтры
Фильтры нужны для программы flow-nfilter, которая принимает на вход двоичный flow, фильтрует его и выдаёт на выход опять же двоичный flow.
Фильтры в /etc/flow-tools/cfg/filter.cfg. Состоят из примтивов (грубо говоря, названия для элементов фильтра) и фильтров. При вызове flow-nfilter ему указывается имя фильтра, по которому фильтровать.
Вот пример для двух арендаторов:
filter-primitive rent31-range type ip-address-prefix permit 192.168.31.0/24 default deny filter-primitive rent3233-range type ip-address-prefix permit 192.168.32.0/24 permit 192.168.33.0/24 default deny filter-definition rent31-out match dst-ip-addr rent31-range filter-definition rent3233-out match dst-ip-addr ren32t33-range
Скрипт
Собственно, основное:
#!/bin/sh
#args:
# $1 - rent (01,02,...),
# $2... $N - email adresses to be sent
year=`date --date='-1 month' +%Y`
month=`date --date='-1 month' +%m`
net=$1
total=`flow-cat /srv/netflow/$year/$year-$month|flow-nfilter -F rent$net-out |flow-stat -f 15|grep -v "#"|awk '{print $3}'`
shift
(echo "Total incoming: $total Mb"; flow-cat /srv/netflow/$year/$year-$month|flow-nfilter -F rent$net-out |flow-stat -f 8)|mail -s "report for net 192.168.$net.0/24 for $year-$month" $*
Ключевые моменты: скрипт отправляет статистику за прошлый месяц. (спасибо соответствующей опции date). flow обрабатывается дважды (меня скорость пока устраивает, если начнёт тормозить, нужно будет делать фильтрацию в файл и запускать два отчёта раздельно). Первая обработка даёт нам человекочитаемую цифру в мегабайтах, вторая — табличку о том, кто сколько жрёт.
При необходимости (конфликте/споре) можно будет руками (с помощью flow-print и grep) выдать полную статистику по каждой цепочке.
Cron
Я использую фичи cron'а в debian, это чуть более удобно обычного в unix — у него есть каталог /etc/cron.monthly. В нём файл /etc/cron.monthly/rent-acc:
/usr/local/bin/rent-acc 31 admin@domain.ru rentuser@example.com manager@company.ru /usr/local/bin/rent-acc 3233 admin@domain.ru rentuser2@foobar.baz manager@company.ru
Этот файл, заодно, является и файлом конфигурации для арендаторов (однако, фильтры для новых нужно руками прописывать!). Не забываем про chmod +x на этот файл.
Результат
Выглядит примерно вот так:
Total incoming: 67673.187 Mb # --- ---- ---- Report Information --- --- --- # # Fields: Total # Symbols: Disabled # Sorting: None # Name: Destination IP # # Args: flow-stat -f 8 # # # IPaddr flows octets packets # 192.168.2.16 1321968 4301821906 24858456 192.168.2.2 2118220 62029649663 51512160 192.168.2.3 226383 193301694 1129250 192.168.2.8 105319 350858966 3027875 192.168.2.5 3240 60888068 681056 192.168.2.4 31289 13434866 217217 192.168.2.15 200 32104404 97818 192.168.2.14 1356 137727274 1977666 192.168.2.7 35310 553217946 10290038
Disclamer
Обратите внимание, что оказание услуг связи требует лицензии. Единственная лазейка — перевыставление счёта от провайдера за услуги. Именно для этого и нужно считать статистику. Однако, всё вышенаписанное не является сертифицированным биллингом, т.е. требует некоего дружелюбия со стороны платящего.
