Была уже когда-то идея организовать систему дополнительных модулей в UTM, отключающих пользователей с NAS в режиме онлайн. При всей широте спектра поддерживаемого оборудования доступа, к каждой железке нужен свой особый подход, и, соответственно, для каждой железки разработать отдельный модуль, заточенный под нее.
Через эти модули можно осуществлять:
1. Онлайн мониторинг активных сессий на NAS. Каждый модуль знает как получить этот список со своего NAS, под который он заточен, и как этот список передать ядру биллинга в стандартизованном виде (Session ID, Login, IP Address и т. д.)
2. Сравнение полученного списка сессий с базой данных пользователей.
3. При обнаружении сессии с нулевым балансом передать модулю команду на сброс сессии. Соответствующий модуль отключит сессию пользователя приемлемым и корректным для данной железки способом.
Эти идеи взяты мной из одного интересного но мертвого биллинга, который нам непосчастливилось приобрести. Его бы довести до ума, но своих программистов нет. Надеюсь на NetUP. Если они это сделают, мы купим его.
Подобные предложения я уже выкладывал на форуме. Но пока от разработчиков нет ответа. Если среди перечисляемых преимуществ биллинга есть поддержка широкого спектра оборудования, то это должно оправдываться на сто процентов. Оборудование должно поддерживаться разносторонне, а не только со стороны сбора статистики (хотя и за это можно поблагодарить разработчиков).
Механизм прерывания ppp сессий на серверах доступа NAS.
-
NightOverZero
- Сообщения: 5
- Зарегистрирован: Пт окт 26, 2007 17:22
Тема вообщем то оставлена без внимания и заброшена. Но думаю кому то будет интересно ее продолжить.
по первому и второму пункту - для реализации подобного в свое время затачивал pppd/pptpd с привязкой portslave на обработку Alive запросов, таким образом билинг проверяет не только жив ли клиент, но и контролирует баланс, трафик, sess_id, login, ip-addr с обратной отдачей (что позволяет осуществлять наглядный мониторинг за сессиями). получается что alive пакеты и есть тот самый способ "сравнения" данных с базой.
на сегодняшний день схема может считаться морально устравшей, т.к. не позволяет ощутить всю прелесть real-time билинга, и лучше от нее отказаться в пользу netflow анализа, возможности которого куда более удачные
третий пункт реализован очень хитрым образом:
pppd получает информацию о возможном избытке трафика (traff_limit) для клиента, основываясь на его балансе, и далее с прогрессивным таймером проверяет его текущий трафик, сравнивая с исходным значением. при достижении отметки 0 (а она достигается с точностью до нескольких милисекунд) сессия pppd завершается.
в mpd4 обрыв сессии предотвращается при получении определенного атрибута от радиуса. что отлично состыкуется с utm5.
при использовании utm5 наилучшим выбором окажется сочетание freebsd + mpd + ng_netflow, ктому же в mpd4 теперь и шейпер есть на уровне ядра. использование pppd/pptpd на сегодняшний день если и нужен то только при условиях нестандартных решений.
по первому и второму пункту - для реализации подобного в свое время затачивал pppd/pptpd с привязкой portslave на обработку Alive запросов, таким образом билинг проверяет не только жив ли клиент, но и контролирует баланс, трафик, sess_id, login, ip-addr с обратной отдачей (что позволяет осуществлять наглядный мониторинг за сессиями). получается что alive пакеты и есть тот самый способ "сравнения" данных с базой.
на сегодняшний день схема может считаться морально устравшей, т.к. не позволяет ощутить всю прелесть real-time билинга, и лучше от нее отказаться в пользу netflow анализа, возможности которого куда более удачные
третий пункт реализован очень хитрым образом:
pppd получает информацию о возможном избытке трафика (traff_limit) для клиента, основываясь на его балансе, и далее с прогрессивным таймером проверяет его текущий трафик, сравнивая с исходным значением. при достижении отметки 0 (а она достигается с точностью до нескольких милисекунд) сессия pppd завершается.
в mpd4 обрыв сессии предотвращается при получении определенного атрибута от радиуса. что отлично состыкуется с utm5.
при использовании utm5 наилучшим выбором окажется сочетание freebsd + mpd + ng_netflow, ктому же в mpd4 теперь и шейпер есть на уровне ядра. использование pppd/pptpd на сегодняшний день если и нужен то только при условиях нестандартных решений.