Биллинговая система NoDeny. Настройка учета трафика

Регистрацией трафика занимаются внешние программы, называемые коллекторами трафика. NoDeny может работать с разными, каждый из существующих коллекторов имеет как преимущества так и недостатки. Вам важно понять какой наиболее подойдет вашим требованиям. Дадим краткую характеристику по каждому.

ipcad - надежен, по статистике автора не `вылетал` ни разу. Имеет несколько вариантов сбора статистики. Недостаток - выполняется в userland. Тем не менее, уменьшение производительности в допустимых пределах.

netflow-коллектор. Многие `несофтовые` решения могут экспортировать статистику по netflow. Сенсор работает на уровне ядра, что положительно сказывается на производительности.

ng_ipacct работает в ядре, т.е производителен. Недостатком является `забор` трафика не по сети, а с помощью консольной утилиты, из-за чего в NoDeny пока не реализовано удаленное снятие статистики, хотя и есть соображения по этому поводу.

Коллектор постоянно регистрирует проходящий через маршрутизатор трафик, а ядро NoDeny время от времени запрашивает у коллектора эти данные, потом обрабатывает и распределяет по клиентам.

В данном документе будет описана настройка коллектора ipcad, предварительно полезно изучить как NoDeny работает с ipcad.

При проектировании системы вы должны были решить на каких серверах будут установлены коллекторы трафика. Пойдем от простого к сложному и сначала рассмотрим вариант «все на одном сервере»:

bash# cd /usr/ports/net-mgmt/ipcad && make install clean

В конфигурационном файле /usr/local/etc/ipcad.conf можно настроить:

1) Способ, которым коллектор будет получать данные о трафике. Для нас интересны 2 варианта:

- ipcad самостоятельно ведет учет трафика, проходящего через определенный интерфейс(ы) системы;
- ipcad ведет учет трафика, который мы ему укажем путем посылки этого трафика из фаервола на порт ipcad.

В первом случае параметр interface должен указывать на имя интерфейса системы:

interface em1;

Во втором случае мы должны указать номер порта, на который следует посылать трафик из фаервола:

interface divert port 111 netflow-disable;

- в приведенном примере ipcad будет «слушать» порт 111 и считать все полученные пакеты.

Проще всего использовать первый способ, однако он обладает одним серьезным недостатком - в этом случае ipcad учитывает весь пришедший на интерфейс трафик, даже если он (трафик) фаерволом будет заблокирован. Что бы вы уловили суть проблемы, приведем пример: заблокированный клиент постоянно посылает в интернет запросы (специально либо это вирусы), этот трафик будет зарегистрирован ipcad, однако не будет пропущен в интернет т.к. ip заблокирован. Получится, что исходящий трафик будет постоянно начисляться клиенту - ведь клиент действительно формирует исходящий трафик. Однако мы не должны начислять этот трафик, поскольку он не отправлен в интернет. Забегая вперед, успокоим, что решить эту проблему можно - очевидно, что полезный трафик должен быть двунаправленным: послали запрос, получили ответ. Следовательно, если есть исходящий трафик, а входящий равен нулю - можно считать, что обмена трафиком не было. В NoDeny есть параметр, указывающий не считать исходящий трафик если нет входящего.

Тем не менее, автор предпочитает использовать второй, более управляемый вариант, когда ipcad считает строго тот трафик, который был отправлен и получен. В разделе настройка фаервола представлены схемы, где показано в каком месте в цепочке прохождения трафика мы считаем (отправляем в коллектор) этот трафик: при выходе пакетов из фаервола в пункт назначения.

2) Опция capture-ports включает/отключает сбор статистики не только «какой Ip на какой Ip посылал сколько байт», но и по портам и протоколам. Таким образом, имеется возможность оценивать трафик не только по объему, но и по его типу. Например, возможно выделить категорию «WWW-трафик» и засчитывать в нее трафик идущий на порт 80, весь остальной трафик считать другой категорией. Даже если вам не требуется разделять трафик по направлениям основанных на портах, возможно вы пожелаете вести детальную статистику по всем портам.

capture-ports enable; включает статистику по портам и протоколам. Обратите внимание, что при этом возникает несколько отрицательных моментов:

- объем передаваемой информации увеличивается в несколько раз, что предъявляет дополнительные требования к каналу, если ipcad запускается на удаленном сервере;
- увеличение объема увеличивает время обработки данных ядром NoDeny;
- увеличивает потребление памяти ipcad, хотя в текущее время это некритично.

Кроме того, вы должны учитывать, что при серьезных сканированиях, а также вирусных эпидемиях, идет перебор большого количества портов, для каждого создается отдельная строка в статистике - это значительно увеличит нагрузку и на канал и на ядро NoDeny. Поэтому крайне рекомендуется воспользоваться агрегированием - когда группа портов в статистике будет отображаться под одним номером. Например порты с 1..79 будут считаться портом 0, 80й будет считаться 80м, 81..65535 - тоже нулевым, таким образом мы выделим трафик на порт 80 (www), а любой другой сагрегируем.

На начальном этапе настройте сокращенную статистику: capture-ports disable;

3) rsh enable at 127.0.0.1;

- на адресе 127.0.0.1 будет запущен rsh-сервер, принимающий соединения. Через этот сервер статистика будет "забираться" ядром NoDeny.

4) rsh root@127.0.0.1 admin;

- разрешаются rsh-соединения пользователя root с сервера 127.0.0.1.

5) memory_limit = 50m;

- установили лимит памяти выделенной для ipcad в 50 Мб.

Упрощенная настройка описана в разделе инсталяции NoDeny здесь.


При настройке удаленного ipcad, rsh необходимо запускать уже не только на локальном адресе, но и на внешнем, а также разрешить коннекты с сервера NoDeny. Например, ядро запускается на сервере 10.1.1.1, коллектор на сервере 10.1.1.2, конфиг этого коллектора:

capture-ports disable;
interface em1;
rsh enable at 127.0.0.1;
rsh enable at 10.1.1.2;
rsh root@10.1.1.1 admin;
rsh root@127.0.0.1 admin;
rsh ttl = 6;
rsh timeout = 30;
dumpfile = ipcad.dump;
chroot = /tmp;
memory_limit = 50m;

- rsh-сервер запускается на адресах 127.0.0.1 и на 10.1.1.2, последний для того, чтобы сервер 10.1.1.1 мог получать статистику трафика.

Не забудьте правильно настроить фаервол на запрет коннектов с других, отличных от 10.1.1.1, ip - это повысит безопасность системы.

В настройках NoDeny, в разделе «Коллекторы трафика» укажите в списке коллекторов адрес 10.1.1.2, удалив при этом 127.0.0.1, если, конечно, не требуется снимать статистику и с этого коллектора.

Параметр «Сети клиентов, для которых будет учитываться трафик» указывает, какой коллектор ответственен за какую сеть клиентов. В зависимости от проектирования вашей сети, возможны такие ситуации, когда пакет, идущий к/от клиента, проходит более чем через один сервер с коллектором трафика. Например, трафик идущий от клиента в одном районе к клиенту в другой район. Считаем что в каждом районе стоит свой маршрутизатор, на котором запущен свой коллектор. В таком случае этот трафик будет зафиксирован обоими коллекторами и, следовательно, начислен дважды, что не есть правильно.

Конечно, если вы не собираетесь учитывать трафик между абонентами распределенной сети, а регистрируете только интернет-трафик, то эта проблема вас не коснется, поскольку интернет-трафик попадает к клиенту, пройдя всего один маршрутизатор с коллектором. В этом случае, сколько бы у вас не было серверов с коллекторами, вы можете указать в параметре «Сети клиентов, для которых будет учитываться трафик» в левой колонке значение «0.0.0.0/0», а в правой - «*_*»

Последнее означает следующее: трафик любого клиента (0.0.0.0/0) учитывать в каком бы коллекторе он не встретился (*_*).

Звездочка перед символом подчеркивания означает «любой коллектор», а после - «любой интерфейс сервера». Вместо звездочки, перед символом подчеркивания, может стоять число, указывающее на номер коллектора в списке коллекторов. При этом трафик идущий на/от клиента в заданной сети будет засчитат клиенту только если он появится в коллекторе с указанным номером.


Для чего «выдуман» этот параметр? На самом деле, вам он может и не понадобиться никогда. А, возможно, без него не сможете осуществить задуманное. Чтобы понять суть проблемы, которая привила к появлению этого параметра, написана целая статья.

Допустим, необходимо считать трафик между клиентами. Клиентская сеть 10.1.2.0/24 подключена к серверу с ip 10.1.2.1, на котором запущен коллектор трафика ipcad. Допустим в настройках указано 3 коллектора, 10.1.2.1 по счету 3й. Поэтому в параметре «Сети клиентов, для которых будет учитываться трафик» указываем в левой колонке 10.1.2.0/24, а в правой - 3_*. К примеру, клиент 10.1.2.100 скачивает файл от клиента с адресом 10.2.2.100 - в результате сведения о трафике появятся как в коллекторе 10.1.2.1, так и в коллекторе 10.2.2.1. Однако трафик идущий к клиенту 10.1.2.100 будет засчитан только с его «родного» коллектора 10.1.2.1.

Как было сказано ранее, в большинстве случаев настройка сетей заключается во внесении всего одной строки: 0.0.0.0/0 = *_*. Для того чтобы удостовериться «хватит» ли вам такой настройки, вы должны подумать может ли оплачиваемый трафик когда-либо для каких-либо клиентов «проходить» более чем через один коллектор. Возможно, не для всех клиентских сетей есть необходимость в привязке к номеру коллектора.

Еще более тонкая настройка может быть осуществлена после символа подчеркивания, где указывается интерфейс. Как упоминалось ранее, при capture-ports enable; ipcad в статистику вписывает название интерфейса, на котором он посчитал текущий трафик. Когда ipcad получает данные из фаервола, то в качестве интерфейса будет указан номер порта, который «слушает» ipcad.

Примеры:

2_em1 - интерфейс em1 коллектора №2;
*_em0 - интерфейс em0 любого коллектора;
3_ng* - любой интерфейс ng, например ng1, ng2, ng3 (и т.д). коллектора №3;
*_321 - трафик полученный через порт 321 любого коллектора.

Последний пример интересен тем, что вы можете на разных серверах указывать один и тот же номер порта, вернее оперировать номерами как угодно: на одних серверах одинаковые, на других разные, в зависимости от требований. Например у вас два PPPoE-сервера, к обоим могут подключаться клиенты из одной логической сети (что, правда, не совсем корректно), скажем 10.10.0.0/16. Если коллекторы установлены на обоих серверах, то не получится одним номером указать, что статистика может учитываться и с первого и со второго коллектора. Поэтому мы настраиваем ipcad на прослушивание порта 777 на обоих серверах (на других серверах порты должны быть другими) и в настройках указываем:

10.10.0.0/16 = *_777



Если ipcad настроен на сокращенный вывод, то интерфейс не подлежит проверке - будет проигнорирован. Также вы можете на разных серверах использовать разную настройку коллекторов - на одном сокращенный вывод, на другом полный.


Агрегирование трафика один из способов сократить объем обрабатываемых данных, т.е снизить затраты ресурсов. Суть заключается в том, то если по некоторым направлениям вам не нужна детализация по ip, скажем, в нашей сети нигде не используется подсеть 192.168.0.0/16 и нам неважно на какие ip в этой сети будут идти запросы, то мы можем любой ip от 192.168.0.0 до 192.168.255.255 считать как будто это ip 192.168.0.0. В самом деле, нам не важно на какой именно адрес был послан запрос в несуществующую сеть, нам важно чтобы при сканировании (вирусном/хакерском) этой сети не возникло много тысяч бессмысленных строк. Нам важно знать общий трафик и что он был отправлен в сеть 192.168.0.0/16.

По-простому, агрегирование это объединение диапазона ip в один ip. Приведем еще один реальный пример. К сети подключена школа, в которой несколько сотен компьютеров в диапазоне 10.255.0.0/24. Школа - один клиент, который оплачивает трафик всех компьютеров, не обращая внимания на то, сколько же трафика потребил каждый конкретный компьютер. Т.е необходимости заводить в NoDeny несколько сотен ip адресов нет - нам не нужно знать трафик каждого. Поэтому коллектор трафика был настроен на агрегирование сети 10.255.0.0/24, т.е на выходе статистики любой ip был виден как 10.255.0.0, этот ip и был занесен в NoDeny.

Для снижения нагрузки возможно появится необходимость в агрегировании, однако не забывайте, что сети, в которые попадают ваши клиенты не должны подвеграться агрегации, иначе мы теряем информацию о конкретном ip клиента. Например, наша сеть 10.33.0.0/16. Мы можем добавить в конфиг ipcad следующее:

aggregate 10.33.0.0/16 strip 32;
aggregate 10.0.0.0/8 strip 8; 

- первая строка указывает на то, что сеть 10.33.0.0/16 не должна агрегированться - strip 32 указывает урезать ip маской /32 (255.255.255.255), т.е фактически не урезать.

- вторая строка указывает урезать ip в сети 10.0.0.0/8 до значения 10.0.0.0 - strip 8 указывает урезать маской /8 (255.0.0.0).

как вы заметили учитывается порядок следования записей об агрегации, поскольку сеть 10.33.0.0/16 является частью сети 10.0.0.0/8.