Разработка модуля Netflow для STG 2.4

[Max 0]

Давно возникла идея создать модуль Netflow для STG 2.4+

Идея такова:

Есть центральный роутер с СТГ 2.4+ и модулем Netflow.

Есть много различных NASov тоесть серверов доступа (FreeBSD+ng_netflow/Linux) или цысок. С даннх серверов по Netflow 5.0 льётся инфа о трафике на центральный роутер. Выигрыш очевиден >> Централизация БД юзеров и снижение нагрузки на NAS.

 

Задача програмистам поставлена (так как сам в С++ ничего не понимаю), результат будет где-то через месяц.

 

Сам модуль будет представлен в виде колектора Netflow с интерфейсом к СТГ (аналог DIVERT).

 

Желающие поучавствовать присоединяйтесь.

 

За работу програмисты хотят примерно 3000 рублей. Готов взять на себя часть расходов. После завершения проекта опубликовать исходные коды. Один осилю но струдом. Мне бы не хотелось торговать данным модулем в дальнейшем, вот и решил предложить совместное участие.

 

Сам нахожусь в РФ г. Челябинск, как будут новости о тестировании отпишусь.

Відредаговано 2006-08-04 06:59:49 Max

[Max 0]

Есть хорошие новости, модуль почти готов, окончательно готов будет через неделю.

[Den_LocalNet 1 474]

если будет что показать готов помочь финансово...

если я правильно понял то это чуть больше 100 у.е.

если да то 40-50 готов перечислить

но хотелось бы рабочий продукт.

 

но опять же стг 2.4 как я понял не совсем стабилен???

[Max 0]

ура, хоть кто нибудь откликнулся.

 

если я правильно понял то это чуть больше 100 у.е.

Около 150.

но опять же стг 2.4 как я понял не совсем стабилен???

Но он имеет модульную структуру, и поэтому писали под него. Но я сейчас думаю что мона попросить програмера написать патч под 2.0.16 но это совсем другая песня.

 

Значит так, начну с начала:

Модуль написан под стг-2.4 так как он имеет модульную архитектуру.

Сам модуль готов, и сейчас проходит стрессовое тестирование, а так же пишется дока к нему и удобная инсталяха.

При стандартной реализации схема взаимодейсвия будет следующей:

#########################################

IMG поскипал за ненадобностью, новая картинка ниже

#########################################

Плюс ко всему к нему будет в ближайшее время дописан плагин который реализует следующую схему:

#########################################

IMG поскипал за ненадобностью, новая картинка ниже

#########################################

Данный плагин заменяет поток передоваемый по сети по udp на tcp плюс организует копию потока на hdd если установить соединение с коллектором (модулем стг-2.4 netflow) не удалось. Как только связь появляется поток отправляется на колектор. Тоесть получается своеобразная прокся для netflow потока.

Відредаговано 2006-08-04 06:40:01 Max

[sypper-pit 0]

я занимаюсь траблами с VPN типа чтоб он с mpd нормально работал единственно е что могу предложить это еще подождать .. или огласить исходники чтоб народ копался ... я к примеру совмещаю вот это http://npj.ru/cake с СТГ пока не очень ну просто времени маловато на рр данный проект

 

а вообще предлогаю просто переделывать логи с netflow на логи для СТГ и всё должно рр нормально , а насчёт отправки их по TCP это умедляет на 30% зато нет повторного лога или потери трафика клиента

[Max 0]

я занимаюсь траблами с VPN типа чтоб он с mpd нормально работал

А в чём заключается ваша работа? Радиус модуль? Или поддержка ng*|ppp*|tun* интерфейсов? Просто модуль Netflow это разминка, за ним последует модуль mysql | postgresql а за ними и ВПН модули, далее голос, единственное что за разработку данных модулей нужно платить програмисту, за каждый модуль выходит примерно 150 баксов, а срок разработки примерно месяц.

единственное что могу предложить это еще подождать .. или огласить исходники чтоб народ копался ... я к примеру совмещаю вот это http://npj.ru/cake с СТГ пока не очень ну просто времени маловато на рр данный проект

Исходники оглашу со временем, когда расплачусь с програмером для меня сумма в 150 уе не такая уж и малая, и обкатаем модуль на себе немного.

а вообще предлогаю просто переделывать логи с netflow на логи для СТГ и всё должно рр нормально

Не понял вашей мысли. На самом деле модуль Netflow.so занимается приёмом потока нетфлоу обработкой его до нужного формата для стг-2.4 и отдаче его стг-2.4 для дальнейшей обработки.

а насчёт отправки их по TCP это умедляет на 30% зато нет повторного лога или потери трафика клиента

Лично я готов пожертвовать 30% но не потерять не байта. Помойму оно того стоит.

[egor2fsys 5]

Просто модуль Netflow это разминка, за ним последует модуль mysql | postgresql а за ними и ВПН модули, далее голос, единственное что за разработку данных модулей нужно платить програмисту, за каждый модуль выходит примерно 150 баксов, а срок разработки примерно месяц.

это вы зря. :tongue:

модуль БД для Firebird уже готов и находится в стадии тестирования.

так же готов модуль queue для линукса. в след. бете уже будет включен в архив. для фри диверт будет немного попозже.

[Max 0]

понял учту. Вам в туду, можно было бы писать анонсы будующих релизов и состав текущих.

Кстати народ доку слёзно просит.

[egor2fsys 5]

угу, постараемся написать.

сейчас основная работа идет над выискиванием мелких и не очень багов.

 

по поводу доки, поменялся только главный файл сервера СТГ, все остальное осталось по старому. ну если не считать что из параметров юзеров ушел интерфейс.

 

главный конфиг думаю скоро опишу

[Max 0]

хорошие новости, 4.08.2006 будет закончен модуль netflow_cap.so для стг-2.4+

Данный модуль прошёл стрессовое тестирование на трёх серверах под управлением OC FreeBSD 4.9 & FreeBSD 5.4, а так же на линуксе RHEL. Подсчёт ведётся очень точно!

Единственный минус выявленный в процессе эксплуатации это то ограничение технологии NETFLOW, как известно протокол нетфлоу посессионный, а именно: поток нетфлоу с сенсора сбрасывается на коллектор только после завершения сессии (закачки)! Это значит что если кто то начал качать 600 метров то билинг узнает об этом только после скачивания этого объёма трафика со всеми вытекающими от сюда последствиями.

[sypper-pit 0]

Просто модуль Netflow это разминка, за ним последует модуль mysql | postgresql а за ними и ВПН модули, далее голос, единственное что за разработку данных модулей нужно платить програмисту, за каждый модуль выходит примерно 150 баксов, а срок разработки примерно месяц.

это вы зря. :tongue:

модуль БД для Firebird уже готов и находится в стадии тестирования.

так же готов модуль queue для линукса. в след. бете уже будет включен в архив. для фри диверт будет немного попозже.

вот с дивертом это вы класно ... а что если туда втыкнуть и VPN ??? тогда и авторизатор не нужен

[sypper-pit 0]

я занимаюсь траблами с VPN типа чтоб он с mpd нормально работал

А в чём заключается ваша работа? Радиус модуль? Или поддержка ng*|ppp*|tun* интерфейсов? Просто модуль Netflow это разминка, за ним последует модуль mysql | postgresql а за ними и ВПН модули, далее голос, единственное что за разработку данных модулей нужно платить програмисту, за каждый модуль выходит примерно 150 баксов, а срок разработки примерно месяц.

единственное что могу предложить это еще подождать .. или огласить исходники чтоб народ копался ... я к примеру совмещаю вот это http://npj.ru/cake с СТГ пока не очень ну просто времени маловато на рр данный проект

Исходники оглашу со временем, когда расплачусь с програмером для меня сумма в 150 уе не такая уж и малая, и обкатаем модуль на себе немного.

а вообще предлогаю просто переделывать логи с netflow на логи для СТГ и всё должно рр нормально

Не понял вашей мысли. На самом деле модуль Netflow.so занимается приёмом потока нетфлоу обработкой его до нужного формата для стг-2.4 и отдаче его стг-2.4 для дальнейшей обработки.

а насчёт отправки их по TCP это умедляет на 30% зато нет повторного лога или потери трафика клиента

Лично я готов пожертвовать 30% но не потерять не байта. Помойму оно того стоит.

и так по списку ...

1) ВПН реалезован на mpd соответственно работают nd интерфейсы которыые не считает СТГ

 

2) у netflow можно записывать весь лог что и куда ходило в такстовом виде ... а затем просто их отробатывать

+лёгкость решения

-оброботка будет отнимать значительное время и ресурсы сервера

 

3) ничего против этого не имею ... это даже + если они общаются не через общие каналы связи

[Den_LocalNet 1 474]

Единственный минус выявленный в процессе эксплуатации это то ограничение технологии NETFLOW, как известно протокол нетфлоу посессионный, а именно: поток нетфлоу с сенсора сбрасывается на коллектор только после завершения сессии (закачки)! Это значит что если кто то начал качать 600 метров то билинг узнает об этом только после скачивания этого объёма трафика со всеми вытекающими от сюда последствиями.

Ой как плохо....в нашей сфере это сильно плохо....

[Max 0]

ну я бы не стал всё так драматизировать, поголовное число лицензированных провайдеров считают именно по netflow снимая статистику с cisco, и ничего прекрасно живут и считают.

[egor2fsys 5]

а там нету всяких alive пакетов как это сделано в радиусе ?

 

кстати подсказка - в user.cpp есть fakedisconnect и fakeconnect

т. е. когда статистика записывается но скрипты не выплняются.

может поможет.

[Max 0]

сдесь дело не в модуле netflow, а в сенсоре именно он собирает статистику, и отправляет её на колектор/модуль стг, а так как спецификация протола netflow v.5 описывает по сессионную реализацию то и информацию о пройденом трафике СЕНСОР (а это может быть любая программа умеющая это делать) собирает по сессиям и отправялет на коллектор. А не постоянно шлёт инфу на колектор о проходящем трафике.

 

На счёт алив пакетов: такого в стандарте не предусмотрено, я думаю. Хотя спрошу у программиста.

 

Вобщем счас нарисую схему для тех кто не понял.

[Max 0]

А вот и схема:http://stg-tarif.narod.ru/shema_new.JPG

Собственно описание:

Случай 1. (Цыска 2620 умеющая нетфлоу):

У цыски есть аппаратный модуль который генерит нетфлоу поток, но так как стандарт посессионный то он отправит инфу о трафике только по закрытии сессии пользователем по протоколу UDP на колектор - что не гарантирует доставку статистики до биллинга.

Решили исправить данный недостаток, но об этом чуть позже.

Случай 2. (Сервер доступа Ос FreeBSD/Linux):

Так как это оси то под них есть куча сенсоров (программа для сбора статистики, превоащения её в формат netflow v.5 и отправки её на колектор по протоколу UDP) например: под FreeBSD ng_netflow-2.5, под линукс softflowd или fprobe. Данные сенсоры работают точно также как и цыска и отправляют статистику на колектор после завершения сессии пользователем по протоколу UDP. (Может конечно можно как то настроить сенсор что бы он лил постоянно на колектор инфу, но как это сделать на ng_netflow я не знаю, ну и мысль меня поддталкивает на то что это сделать нельзя, так как протокол так устроен (Netflow v.5))

Решили исправить недостаток Отправки по протоколу UDP, и заменить на протокол TCP.

Случай 3. (Сервер доступа Ос FreeBSD/Linux):

Сенсор настраивается так что он отправляt статистику не на колектор после завершения сессии пользователем по протоколу UDP, а на локальный Proxy (127.0.0.1:port) который сам пытается связаться с биоингом и если связи нет то Proxy зеркалирует данные о трафике на HDD, как только связь восстанавливается то он отправляет статистику на коллектор по TCP, что гарантирует доставку.

Відредаговано 2006-09-26 14:25:33 Max

[Max 0]

и так по списку ...

1) ВПН реалезован на mpd соответственно работают nd интерфейсы которыые не считает СТГ

 

2) у netflow можно записывать весь лог что и куда ходило в такстовом виде ... а затем просто их отробатывать

+лёгкость решения

-оброботка будет отнимать значительное время и ресурсы сервера

 

3) ничего против этого не имею ... это даже + если они общаются не через общие каналы связи

Впн модуль нужен для двух вещей, во-первых: он должен реализовывать функции радиус сервера (иметь такой же интерфейс (API еслихотите)) для внешних клиентов, таких как mpd, PPTPD,pppd,pppoed. А во-вторых: иметь возможность собирать статистику с данных клиенто, тоесть получается полноценный сервер радиуса с возможностью доступа к базе СТГ, пока такого нет, от сюда вывод: необходимо написать модуль который был бы прослойкой между уже существующим радиусом (FreeRadius например) (так как писать свой радиус геморно, да и кросплатформенность потеряется, так сделал Netup, у них свой радиус.) и стг. Данный модуль будет принимать инфу от радиуса и работать с СТГ, если я правильно понимаю то в принципе написать данный модуль вопрос времени и 150 уе., для меня сейчас после netflow стоит исправление и доработка багов стг-2.4.

Відредаговано 2006-08-04 06:41:10 Max

[Max 0]

Единственный минус выявленный в процессе эксплуатации это то ограничение технологии NETFLOW, как известно протокол нетфлоу посессионный, а именно: поток нетфлоу с сенсора сбрасывается на коллектор только после завершения сессии (закачки)! Это значит что если кто то начал качать 600 метров то билинг узнает об этом только после скачивания этого объёма трафика со всеми вытекающими от сюда последствиями.

Ой как плохо....в нашей сфере это сильно плохо....

Но это особенность протокола Netflow v.5 а не модуля, я тут ничего поделать не могу.

[Max 0]

Собственно всё, стабильный продукт получен (mod_netflow.tar), кому интересно обращайтесь.

[Max 0]

После расчётов с програмистами готов опубликовать исходные коды.

[Max 0]

Для тех кому интересно почитать про netflow вот есть статья: http://www.opennet.ru/docs/RUS/netflow_bsd/

[Pit 35]

Поток скидывать можно раз в минуту, в ipcad netflow timeout active 1;

Ndsad тоже так можно настроить, но в ndsad есть проблема, он потом кудает сумму траффика прошедшего потока, то есть траф увеличиться в двое.

[Pit 35]

Ну раз нетфлов сделали, делать теперь прейдется acl-module который по rsh ssh etc? будет по сервака бегать аклы блокировки-разблокировки выполнять.

[Max 0]

да дело за малым, модуль будем писать гдето с нового года.