Сделал небольшую биллинговую систему с помощью fprobe-ulog + flow-tools + PHP (web-интерфейс).Сбор информации о трафике идёт так:
Chain FORWARD (policy DROP)
target prot opt source destination
REJECT all -- !192.168.0.0/24 0.0.0.0/0
REJECT all -- 0.0.0.0/0 !192.168.0.0/24
ULOG all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 192.168.0.0/24
ACCEPT tcp -- 192.168.0.0/24 194.1.1.1 tcp dpt:110
ACCEPT tcp -- 192.168.0.0/24 194.1.1.1 tcp dpt:25
*на самом деле аналогичных правил чуть больше, но для примера подойдёт*Всё считается, всё работает, но есть одна проблема:
считается "лишний" трафик, который после прохождения через ULOG блокируется policy DROP!
Тоесть получается так, что пакет в интернет не ушёл, но посчитался.
Ситуация такая, что на одной из локальных машин Windows Update отчаяно долбилась напрямую (через шлюз) в инет, шлюз ни один из этих пакетов не пропустил, но ULOG их посчитал.Как проще всего сделать так, чтобы в ULOG попадали только те пакеты, которые реально уйдут в интернет, а то, что будет заблокировано - не считалось?
Дублировать каждое разрешающее правило с -j ULOG?
что-то не пойму -- исходящий трафик тоже платный ??
если нет -- то по платному входящему могу добавить только то, что мы (пров или кто там) -- за этот трафик уже нашему провайдеру уже заплатили, так что если мы его отфильтравали, то либо списываем на "общие" расходы -- либо на потребителя.правда , можно ещё перед тем как отбрасывать пакеты поститать их -- ну и соответственно вычитать из уже посчитаных ранне -- то есть всего два правила -j ULOG
>что-то не пойму -- исходящий трафик тоже платный ??
>если нет -- то по платному входящему могу добавить только то, что
>мы (пров или кто там) -- за этот трафик уже нашему
>провайдеру уже заплатили, так что если мы его отфильтравали, то либо
>списываем на "общие" расходы -- либо на потребителя.Проблема в том, что в ULOG попадают пакеты которые потом блокируются (policy DROP!).
Представим такую ситуацию:Локальная машина 192.168.0.2
Шлюз имеет внутренний адрес 192.168.0.1
Внешний: 123.123.123.123С локальной машины пользователь пытается открыть какой-нибуть сайт в инете:
запрос от 0.2 идёт к шлюзу 0.1 на котором пакет сначала попадает в -j ULOG (пакет считается!!), а потом не попадая ни в одно из разрешающих правил по policy DROP откидывается! Получается, что пакет на шлюзе был посчитан, а в инет (на шлюз провайдера) не ушёл!
(шлюз 0.1 - это наш офисный сервер, а не провайдерский)Так и нужно, чтобы пакет который не пройдёт FORWARD не попадал в ULOG
читаем что я назарапал выше и отвечаем на вопрос
"исходящий трафик тоже платный ?? "
>читаем что я назарапал выше и отвечаем на вопрос
>"исходящий трафик тоже платный ?? "да.
Да дело-то не в том, кто платит, а кто нет.Просто мне нужна "чистая" статистика
>Сделал небольшую биллинговую систему с помощью fprobe-ulog + flow-tools + PHP (web-интерфейс).
>
>
>Сбор информации о трафике идёт так:
>Chain FORWARD (policy DROP)
>target prot opt source
> destination
>
>REJECT all -- !192.168.0.0/24
> 0.0.0.0/0
>REJECT all -- 0.0.0.0/0
> !192.168.0.0/24
>ULOG all -- 0.0.0.0/0
>
>0.0.0.0/0
>ACCEPT all -- 0.0.0.0/0
> 192.168.0.0/24
>ACCEPT tcp -- 192.168.0.0/24
> 194.1.1.1
>tcp dpt:110
>ACCEPT tcp -- 192.168.0.0/24
> 194.1.1.1
>tcp dpt:25
>*на самом деле аналогичных правил чуть больше, но для примера подойдёт*
>
>Всё считается, всё работает, но есть одна проблема:
>считается "лишний" трафик, который после прохождения через ULOG блокируется policy DROP!
>Тоесть получается так, что пакет в интернет не ушёл, но посчитался.
>Ситуация такая, что на одной из локальных машин Windows Update отчаяно долбилась
>напрямую (через шлюз) в инет, шлюз ни один из этих пакетов
>не пропустил, но ULOG их посчитал.
>
>Как проще всего сделать так, чтобы в ULOG попадали только те пакеты,
>которые реально уйдут в интернет, а то, что будет заблокировано -
>не считалось?
>Дублировать каждое разрешающее правило с -j ULOG?
Попробуй следующее. Создай цепочку netflow, в которой будет правило ULOG. То, что разрешено (твои ACCEPT-ы) замени на перенаправление в пользовательскую цепочку netflow, остальное DROP как политика по умолчанию. А в твоей схеме пакеты сначала попадают под действие ULOG, а потом дропаются, соответственно они считаются.
PS: по другой теме netflow спрашивали по ICQ: 459-164-160.
>Попробуй следующее. Создай цепочку netflow, в которой будет правило ULOG. То, что
>разрешено (твои ACCEPT-ы) замени на перенаправление в пользовательскую цепочку netflow, остальное
В цепочке,получается, должно быть быть два правила:
-j ULOG
-j ACCEPT?
(чтобы сначала пакет посчитался, а потом ACCEPTed?)>DROP как политика по умолчанию. А в твоей схеме пакеты сначала
>попадают под действие ULOG, а потом дропаются, соответственно они считаются.
Да-да-да! именно об этом и говорил: сначала под действие ULOG, считаются, а только потом дропаются...
>>Попробуй следующее. Создай цепочку netflow, в которой будет правило ULOG. То, что
>>разрешено (твои ACCEPT-ы) замени на перенаправление в пользовательскую цепочку netflow, остальное
>В цепочке,получается, должно быть быть два правила:
>-j ULOG
>-j ACCEPT?
>(чтобы сначала пакет посчитался, а потом ACCEPTed?)Сделал! Завтра о результатах сообщу
>>>Попробуй следующее. Создай цепочку netflow, в которой будет правило ULOG. То, что
>>>разрешено (твои ACCEPT-ы) замени на перенаправление в пользовательскую цепочку netflow, остальное
>>В цепочке,получается, должно быть быть два правила:
>>-j ULOG
>>-j ACCEPT?
>>(чтобы сначала пакет посчитался, а потом ACCEPTed?)
>
>Сделал! Завтра о результатах сообщу
С помощью чего делал агрегацию и какой алгоритм? Не хочется в БД инсертить все записи netflow, планирую сделать агрегацию раз в 5-15 минут по ip адресам, желательно еще зоны как-то группировать, но еще не нашел наиболее подходящего средства. Может кто посоветует, как реализовывали это?