From: Бесядовский Роман Александрович
Newsgroups: http://www.iplab-nnz.ru
Date: Mon, 22 Apr 2005 14:31:37 +0000 (UTC)
Subject: Подсчёт трафика в Linux посредством ulog
-----
Все разработки опробованы на компактном сервере Favourite IS на основе ОС UNIX,
предназначенном для предоставления Интернет-доступа и Интернет-сервисов.
Ссылка в Интернет: http://is.nnz.ru
Взять сервер Favourite IS на тестирование. Mail to: Boginsky@nnz.ru <mailto:Boginsky@nnz.ru.>
-----
Подсчёт трафика в Linux посредством ulog faciltynetfilter-а.
В Linux пакеты проходят через встроенный в ядро netfilter.
Harald Welte <laforge@gnumonks.org.>, написал патч к нему, позволяющий
пересылать информацию о пакетах в user-space, и библиотеку, которая
это инфу ловит. (см http://www.gnumonks.org/projects/ulogd) и
может на её основе собирать информацию о трафике.
Патч ULOG писался как альтернатива стандартному LOG для ведения
протоколирования прошедших через netfilter пакетов.
Я столкнулся с 2-мя реализациями подсчёта трафика на этой технологии
ulogd (автора патча) и ulog-acctd (alioth.debian.org/projects/pkg-ulog-acctd)
by Hilko Bengen
Я не пробовал ставить ulogd т.к. технология одинаковая, а возможностей
ulog-acctd мне вполне достаточно (на данный момент), хотя ulogd имеет
встроенные plug-ins для прямой записи в mysql, pgsql, sqlite базы, что
в дальнейшем может быть востребовано, а также предоставляет много
различной информации о пакете включая ToS (если это кому-то может быть
нужно при биллинге)
Итак, остановимся на ulog-acctd.
Возможности:
* Умеет вынимать из пакетов и складывать данные о протоколе;
* IP адресе источнике и получателе;
* Типа протокола;
* Количестве байт и количестве пройденных пакетов по этому сокету;
* Входящий и исходящий интерфейсы.
Несомненным плюсом является то, что можно настраивать формат записи в
log file. Что позволяет упростить задачу занесения трафика в базу
данных.
При этом, как написано в документации
`ulog-acctd' only collects, aggregates, and logs the all data it is
fed by netfilter. If only traffic for specific networks needs to be
collected, selection for this should be done in the netfilter
rulesets, as `ulog-acctd' has no way to ignore some packets and log
others.
`ulog-acctd' does not analyze them nor paint pretty pictures for
traffic visualization. In the "one tool for one job" spirit of UNIX,
Other tools should be used for these tasks.
Ulog-acctd может только считать трафик переданный ему из netfilter. Он
не умеет его обрабатывать, он не умеет строить графики.
Для того чтобы иметь возможность использовать такой подсчёт трафика
нужно ядро kernels >= 2.4.18-pre8 (в котором уже включена поддержка
ULOG) или нужно патчить ядро. Более подробно можно прочитать в
документации к ulogd (например
http://svn.gnumonks.org/cgi-bin/viewcvs.cgi/trunk/ulog/ulogd/README)
Также в ядре должна быть установлена опция CONFIG_IP_NF_TARGET_ULOG
Установка очень проста - скачать, распаковать
make
make install
Причём проверить работу можно даже не устанавливая его, а запустив
прямо после компиляции.
./ulog-acctd -c ulog-acctd.conf
Ключ -с указывает какой брать конфигурационный файл.
ps ax | grep ulog
3768 ? T 0:00 ./ulog-acctd -c ulog-acctd.conf
3875 pts/2 S 0:00 grep ulog
Видим, что демон успешно запустился.
Для того чтобы демон начал получать пакеты нужно добавить
соответствующее правило в netfilter (эта часть является почти
дословным переводом документации)
Здесь мы добавляем в цепочку FORWAD (пакеты проходящие через
маршуризатор) отправлять все пакеты в target ULOG, задать им префикс
'FORWARD' (чтобы можно было различать статистику полученную с разных
правил)
--ulog-nlgroup 1 - номер multicast group, в которую будут посылаться
заголовки пакетов. Ulog-acctd должен быть настроен на прослушивание
этой группы.
--ulog-cprange 48 - количество байт из пакета передаваемых в
userspace. При этом может возникнуть ситуация, когда при наличии в
пакете большого количества флагов заголовок может 'не влезть', тогда
пакет будет не посчитан. При этом в syslog будет выдано сообщение
"Short IP header. Increase copy range to RANGE" по которому можно
будет обнаружить и исправить эту ситуацию. Если же cprange настолько
мало, что даже не может вместить ip адрес, то в лог дополнительно
будет помещено сообщение 'copy range is too short to even capture IP
headers. ALL IP PACKETS WILL BE DROPPED!'
--ulog-qthreshold 50 сколько пакетов должно собрать ядро прежде чем
передать данные о них в user-space.
Конфигурационный файл чрезвычайно прост, там нужно указать multicast
group (указанный в правиле netfilter), формат лога, файл лога и т.д. Я
запускал демон с конфигурационным файлом, идущим в архиве.
Запустив ulog-acctd в файле /var/log/ulog-acctd/account.log мы получим
записи вида
В конфигурационном файле ulog-acctd.conf есть параметр, отвечающий за
то, как часто данные из демона будут записываться в файл.
При подсчёте трафика, таким образом, нужно учесть, что после обработки
правила -j ULOG пакет идёт дальше по цепочке (в этом можно убедиться,
поставив сразу за ним правило -j ACCEPT и посмотреть на одинаковое
кол-во пакетов попавших в оба правила), а это значит, что если
последним правилом стоит -j DROP то пакет будет посчитан но не пройдёт
физически. Хотя с другой стороны прохождение пакета дальше, упрощает
построение всего firewall в целом, и создает возможности по-разному
организовать фильтрацию и подсчёт трафика.
далее мы можем спокойно обработать файл /usr/local/traffic/data/account.log
Об остальных сигналах можно прочитать в документации.
В итоге:
+ Несомненным плюсом является возможность фильтрации того, что нужно
считать до того как будем собственно считать и то, что эта фильтрация
осуществляется на уровне ядра.
+ Возможность задавать формат вывода лога ~ User Space, что, вообще
говоря, при большом трафике может привести к тому, что трафик не будет
передан демону подсчёта (ядро не будет успевать это сделать) хотя
подсчёт только нужного трафика (см выше), а также возможность
изменения параметров
--ulog-cprange и --ulog-qthreshold дают возможность для маневра, дабы
избежать данной ситуации.
Что касается ulogd и прямой записи в базу, то у меня есть сомнение
(аналогичное тому, что возникает при разговоре о netflow), а что
произойдёт, если база лежит? Куда денется инфа о трафике в этом
случае? Если она будет копиться в памяти то, что произойдёт при
перезагрузке рутера? По этому, я предпочитаю работать через файл,
пусть медленнее, однако более надёжно к критическим ситуациям, и к
тому же при записи в базу нет необходимости в высокой скорости т.к.
файл может туда записываться раз в час и реже. Если же говорить о
производительности при записи в файл то здесь, я думаю, разницы особой
нет.
Резюмируя, демон ulog-acctd мне понравился. Т.к. при поиска считалки
трафика под linux я нашёл его раньше, то сейчас я не вижу
необходимости переходить на ulogd (хотя аргументы "За" с удовольствием
выслушаю).
Если нужен простой способ получить трафик в базе данных, то это,
наверное, всё-таки ulogd (хотя ulog-acctd тоже грозиться сделать такой
модуль), если работать с файлами - то ulog-acctd.
Бесядовский Роман Александрович
Системный администратор отдела телекоммуникаций и
Интернет решений ЗАО "Ниеншанц"
1573 Прочтений • [Подсчёт трафика в Linux посредством ulog (linux traffic filter iptables ulog)] [08.05.2012] [Комментариев: 0]
Vova
