Linux: iptables + ulogd + ?

Ответить
ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Linux: iptables + ulogd + ?

Сообщение ran »

Для снятия статистики по трафику лично я использую iptables. Тоись трафик, который нужно считать я заворачиваю иптейблами в ULOG. На мой взгляд это гораздо удобнее и эффективнее, чем снимать статистику с интерфейсов (те, кто хорошо знают иптейблс, меня поймут). На сегодняшний день я вынужден использовать следующую цепочку: iptables -j ULOG + ipcad interface ulog + flow-capture + traffic2sql и она мне активно не нравится. По многим причинам, не буду углубляться. Слишком уж коряво и громоздко. Хотя в линухе есть прекрасный демон ulogd, который собсно и предназначен для снятия статистики с улога и передачи куда-нить в юзерспейс. Там и плагин для мускл есть. То есть, с помощью улогд можно можно формировать статистику в таблице мускла. Вот такого формата:

Код: Выделить всё

CREATE TABLE ulog (     id              INT UNSIGNED AUTO_INCREMENT UNIQUE,

                        raw_mac         VARCHAR(80),

                        oob_time_sec    INT UNSIGNED,
                        oob_time_usec   INT UNSIGNED,
                        oob_prefix      VARCHAR(32),
                        oob_mark        INT UNSIGNED,
                        oob_in          VARCHAR(32),
                        oob_out         VARCHAR(32),

                        ip_saddr        INT UNSIGNED,
                        ip_daddr        INT UNSIGNED,
                        ip_protocol     TINYINT UNSIGNED,
                        ip_tos          TINYINT UNSIGNED,
                        ip_ttl          TINYINT UNSIGNED,
                        ip_totlen       SMALLINT UNSIGNED,
                        ip_ihl          TINYINT UNSIGNED,
                        ip_csum         SMALLINT UNSIGNED,
                        ip_id           SMALLINT UNSIGNED,
                        ip_fragoff      SMALLINT UNSIGNED,

                        tcp_sport       SMALLINT UNSIGNED,
                        tcp_dport       SMALLINT UNSIGNED,
                        tcp_seq         INT UNSIGNED,
                        tcp_ackseq      INT UNSIGNED,
                        tcp_window      SMALLINT UNSIGNED,
                        tcp_urg         TINYINT,
                        tcp_urgp        SMALLINT UNSIGNED,
                        tcp_ack         TINYINT,
                        tcp_psh         TINYINT,
                        tcp_rst         TINYINT,
                        tcp_syn         TINYINT,
                        tcp_fin         TINYINT,

                        udp_sport       SMALLINT UNSIGNED,
                        udp_dport       SMALLINT UNSIGNED,
                        udp_len         SMALLINT UNSIGNED,

                        icmp_type       TINYINT UNSIGNED,
                        icmp_code       TINYINT UNSIGNED,
                        icmp_echoid     SMALLINT UNSIGNED,
                        icmp_echoseq    SMALLINT UNSIGNED,
                        icmp_gateway    INT UNSIGNED,
                        icmp_fragmtu    SMALLINT UNSIGNED,

                        pwsniff_user    VARCHAR(30),
                        pwsniff_pass    VARCHAR(30),

                        ahesp_spi       INT UNSIGNED,

                        KEY index_id    (id)
                );
В этой таблице не обязательно должны присутствовать все поля - достаточно тех, что нужны, лишь бы имена совпадали. Улогд определяет динамически при установлении связи с мусклом.

У меня уже давно руки чешутся прикрутить ulogd к абиллсу (или наоборот :) ). И тут есть 2 пути:

1. Идеальный. Написать плагин для улогд, заточенный под абиллс и возложить на него... да собсно всё, что делает traffic2sql. И мы имеем биллинг, действительно работающий в реальном времени.

2. С извращениями, но простой в реализации (из серии на безрыбье и ворона раком станет). Юзается улогд со своим мускловым плагином и формирует вышеописанную таблицу. Ну а traffic2sql просто "научить" забирать данные оттуда (не забывая при этом удалять обработанные записи). Собсно всё.

Я думаю, что Автор мог бы реализовать вариант 2... ну, скажем, за полчаса (эх, не промахнуться бы, скажешь меньше - подумает ваще офигел, скажешь больше - обидится :lol: ). Со своей стороны могу предложить отладку и тестирование. То есть настройка иптейблс, улогд, формирование таблицы и заполнение корректными данными - это мой геморрой...

Ну что, сделаем? :D

Кстати вот здесь агрегация именно на уровне абиллса просто необходима, т. к. каждая запись таблицы ulog - это информация о каждом пакете, прошедшем через ядро, и завёрнутом в улог. Но для начала можно и без неё.

ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Сообщение ran »

мдя... видно самому писать придётся... :(

Aven
Сообщения: 168
Зарегистрирован: Чт сен 27, 2007 4:48 pm

Сообщение Aven »

Очень красивое решение, присоеденюсь к тестерам если будет модуль :)

ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Сообщение ran »

та я бы сам написал... в смысле плагин для улогд... на сях... времени нет совершенно :(

~AsmodeuS~
Site Admin
Сообщения: 5746
Зарегистрирован: Пт янв 28, 2005 3:11 pm
Контактная информация:

Сообщение ~AsmodeuS~ »

ran писал(а):та я бы сам написал... в смысле плагин для улогд... на сях... времени нет совершенно :(

Это был бы довольно существенный вклад

Tux
Сообщения: 27
Зарегистрирован: Чт мар 20, 2008 5:34 am
Контактная информация:

Re: Linux: iptables + ulogd + ?

Сообщение Tux »

ran писал(а):Кстати вот здесь агрегация именно на уровне абиллса просто необходима, т. к. каждая запись таблицы ulog - это информация о каждом пакете, прошедшем через ядро, и завёрнутом в улог. Но для начала можно и без неё.
Это безусловно, без агрегации никак не обойтись.

При большой активности сети, заворачивать КАЖДЫЙ пакет трафика в отдельную запись в мускуле - самоубийство. Любая БД на обычном железе раком станет. При хорошо нагруженном канале даже размер файлов с netflow-коллектора достаточно большой.
К примеру у меня на работе (abills там нет) за час из коллектора нетфлов поступает в среднем 2000000 -3000000 записей о трафике. И это уже агрегированных записей! Далее они агрегируются по субтрафикам и только потом сливаются в базу.
Представьте себе что будет если заводить запись в БД под каждый пакет?...
Ну а если не заводить для каждого пакета запись, то получается что перед добавлением сведений в базу об ОДНОМ пакетике, надо:
- сначала сделать SELECT на соответствующую этому пакету уже сагрегированную запись о трафике или завести новую
- далее добавить к сумме трафика этот пакет
- и завершить это дело UPDATE'ом.
И вот так обработать КАЖДЫЙ пакетик в сети!!!
При трафике в 5-10 тысяч PPS (это приблизительно средняя нагрузка линка в 100 Мбит) должно быть столько же циклов вышеприведённых операций с БД!

Либо ещё один вариант - добавлять пакетики в одну базу, и потом периодически агрегировать в другую. Но это практически не снижает нагрузку на БД, и вносит задержки между циклами агрегации, т.е. приходим к тому от чего изначально пытались уйти, но только теперь с огромным гемором. Оно нам надо?

Подытожим:
Для чего городить весь этот огород?
А ради того чтоб клиента МОМЕНТАЛЬНО отрубило от сети при достижении 0 на счету. Или ради того чтоб он СРАЗУ увидел статистику трафика а не через несколько минут (десятков минут) как в случае стандартного учёта с netflow.

Лично я мыслю здраво и не готов городить подобный огород. Поэтому для уменьшения вычислительных ресурсов выбираю метод когда сначала надо агрегировать трафик и только потом учитывать. При этом неизбежно возникают задержки агрегации, каким бы способом это не делалось. Источник + сборщик Netflow типичный тому пример.

Самый идеологически верный способ учёта трафика почти в реальном времени - это способ поступления данных о субтрафиках через аккаунтинг в радиусе, потому что трафик там промаркирован сессией, и мы точно знаем чей он, даже если сессия уже фактически закрыта, а клиентский IP здесь не играет никакой роли.!
Следовательно для такого учёта нужен NAS сервер умеющий это делать. EXPPP умеет, но всего 3 трафика.
Человек должен думать, машина - работать

ran
Сообщения: 2298
Зарегистрирован: Вс окт 21, 2007 2:29 pm

Сообщение ran »

ну можнож как я писАл выше юзать мускловый плагин улога, лить инфу в евойную таблицу, а traffic2sql чтабы забирал не из файлов флоу-каптуре, а из этой таблицы и грохал обработанные записи... ну и агрегировал... не думаю, что нагрузка будет больше, чем со всякими там ипкадами, флоу-каптуре, вызовом евойного принта да ещё и текстовый парсинг на пёрдле :D Через мускл-та уж всяко эффективнее, чем через файловую систему...

Ответить