LINUX.ORG.RU
ФорумAdmin

Помогите с архитектурой биллинга


0

0

Всем привет

В рамках дипломного проекта (а в общем-то и моей работы :) ) надо помимо всего прочего приделать человеческий биллинг. Исходные данные:

* 2 внешних провайдера. Пользователь может выбрать используемого провайдера в интерфейсе (веб-интерфейс всё равно писать, так что его реализация не входит в данный вопрос)

* Привязка к IP или МАС крайне нежелательна. Хочется, чтобы внутри биллинга везде, где только можно, фигурировало имя пользователя

* Имеется сервер доступа (rp-pppoe)

* Имеется единое хранилище учёток пользователей (к сожалению, только AD)

* Требуется вести live-аккаунтинг, то есть превышение квоты должно приводить к запрету доступа не позднее, чем через 1-5 минут

Я придумал такое решение:

При подключении rp-pppoe дёргает ррр. ррр после аутентификации напрямую через AD или через RADIUS (что предпочтительнее) запускает скрипт /etc/ppp/auth-up, который передаёт имя пользователя и имя интерфейса моей проге. Прога делает у себя запись с привязкой user-if, достаёт из базы квоты и сведения о выбранном провайдере и добавляет нужные правила в netfilter. При этом используется -m quota, чтобы обеспечить блокирование доступа при превышении квоты. При этом запущен программный netflow-сенсор, который сливает нетфлоу также моей проге. При приходе пакета нетфлоу происходит его обработка и собственно учёт.

Возник вопрос:

А можно ли как-то хитро воспользоваться возможностями freeradius в плане акаунтинга, чтобы уменьшить размер велосипеда или вообще отказаться от него? Вообще какие возможности аккаунтинга предоставляет протокол RADIUS? Возможно ли организовать live-учёт? И вообще правильно ли я понимаю третью букву А (если неправильно - где можно почитать, кроме RFC)? Какие у вас есть предложения по архитектуре решения?


Таки почитал RFC, на свой вопрос ответил. Появились некоторые идеи

Однако мне по-прежнему интересно услышать идеи других людей

hc ()

По радиусу можно получить количество трафика за каждую сессию пользователя, если этого хватит то netflow и не нужен. С отключением сложнее - вы, я так понял, планируете брать плату за трафик, тут видимо придется отключать юзера килом его pppd. Если вы захотите предоставлять анлим доступ, то просто вычисляйте и отправляйте на NAS атрибут Session-Timeout из расчета на сколько хватит денег.

Крайне не советую добавлять правила в нетфильтр. Когда у вас будет 1000 юзеров, получите тормоза, а скорее и гораздо раньше.

Разве выбор внешнего провайдера - это дело пользователя?

ventilator ★★★ ()
Ответ на: комментарий от ventilator

можно поискать инфу на предмет Drop-User патча к радиусу и ппп, когда писал биллинг встречались ссылки на реализации (в конечном итоге написал свое, если уж очень приспичит могу выковырять), в mpd уже реализовано....

jaw ()
Ответ на: комментарий от ventilator

Я не совсем провайдер. Вернее, совсем не провайдер. Я администратор на институтской кафедре. Поэтому выбор провайдера - таки дело пользователя (один провайдер быстрый и с немаленьким лимитом, но из-за глючных конвертеров иногда стал не работать; второй провайдер - сам институт, причём провайдер из института очень дорогой и быдлянский, зато если работает, то работает надёжно). Пользователей больше 100 не будет, вернее всего, то есть изначально не ставится задача получить очень масштабируемое и производительное решение.

Если не добавлять правила в нетфильтер - как отслеживать превышения квоты?

Нетфлоу нужен, ибо надо хранить все принятые пакеты для подбивания некоторой статистики и для детализации расходов (офигеваю от вопросов пользователей порой - «а откуда я столько накачал-то???111»)

hc ()
Ответ на: комментарий от jaw

Возможно, вы и правы...

Оцените ситуацию: я серьёзно занимаюсь администрированием линукса больше 3 лет, с bsd не сталкивался ни разу. Имеет ли смысл меньше, чем за полгода бросаться осваивать опенбзд только ради mpd? Я понимаю, что возможности mpd шире и в настройке он проще, но имеет ли смысл? Не получу ли я где-то в другом месте здоровенный минус (например, есть ли аналог -m quota в pf)?

hc ()
Ответ на: комментарий от hc

Может вам удобнее поставить просто squid? Вам ведь деньги считать не нужно. + скрипты которые канал переключат.

Какая пользователю разница откуда вы берете канал, ему важна работоспособность сервиса - переключение провайдера как раз дело администратора.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Да и pppoe в корпоративной сети - лишние проблемы. У вас разве могут быть какие то неавторизованные подключения? И зачем отключать пользователей?

Squid+Tproxy+sarg отлично решают вашу задачу.

ventilator ★★★ ()
Ответ на: комментарий от hc

как показала практика *bsd+mpd проигрывает linux+pptpd поэтому и переписывался ppp и freeradius дла получения практически такого-же функционала...

jaw ()
Ответ на: комментарий от ventilator

К сожалению, squid+<anything> решают проблему учёта только НТТР-трафика. А это далеко не всё, что нужно. РРРОЕ нужен, чтобы предоставить полноценный доступ в интернет всяким почтам и прочим приблудам, которые через НТТР не прокидываются. При этом ещё и аутентификация появляется, что тоже полезно, ибо студентам в интернете без разрешения преподавателя делать нечего

hc ()
Ответ на: комментарий от hc

freebsd+mpd при большей надежности, оказывает меньшую производительность

jaw ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.