Pull to refresh

Cake — биллинг для небольших.

Reading time 10 min
Views 14K
Практически каждая современная компания, использует в своей работе компьютеры подключенные к сети интернет. Производит ли эта компания какие-либо продукты, занимается их продажей или предоставляет услуги, интернет помогает людям вести свой бизнес. Как всякий ресурс, доступ в интернет нуждается в учёте.


Учет может производится как постфактум при помощи анализа различных лог-файлов прокси-серверов. Но это не позволяет контролировать ресурсы в реальном времени. Для решения этой проблемы существуют специализированные программные комплексы которые обычно называют биллингами. Давайте определимся что такое биллинг и какие функции он может выполнять.

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

Данный функционал может быть реализован различными средствами. Наиболее популярна реализация биллинга на базе счетчиков фаерволла. Для этого используются скрипты которые считывают их, заносят данные в СУБД (обычно это MySQL), затем проверяют не достиг ли пользователь лимита, если достиг то формируют и запускают правила фаерволла запрещающие ему доступ. СУБД используется только из соображений удобства работы с данными. Минусы такого решения в привязке пользователя к ip адресу, отсутствия авторизации пользователя в системе и привязки системы к конкретной. Плюсы такого решения в простоте реализации и возможности модификации решения под себя.

Еще одной популярной реализацией является установка прокси-сервера squid с использованием external_acl и анализатора заносящего данные в СУБД в режиме реального времени. Это работает таким образом: когда пользователь вырабатывает свой лимит он удаляется из группы доступа, которые считывают external acl. Минусом такого решения является достаточно высокая инерционность системы, а так же не слишком высокая стаблильность работы системы и учет трафика который проходит через прокси-сервер. Плюсы же заключаются в наличии авторизации пользователей, возможности детализации статистики и кросплатформенности решения.

Как видим и первая и вторая реализации не лишены своих минусов и плюсов. Давайте рассмотрим третью реализацию. Основная ее идея это использование VPN для обеспечения доступа, учета и ограничения потребления услуг связи. Для этого используется менеджер pptpd соединений, pppd – демон для работы с ppp протоколом и RADIUS сервер. Каким образом это все работает: клиент подключается к pptpd, он запускает pppd и передает управление ему. После чего клиент отправляет ему параметры аутентификации. Pppd демон получив их делает запрос к RADIUS серверу. Он получив данные формирует ответ о разрешении или запрещении соединения. Затем отправляет его pppd. В случае если pppd получил запрещение соединение разрывается. Если же было получено разрешение, то pppd открывает соединение и уведомляет RADIUS о начале сессии. В зависимости от настроек pppd во время сессии могут отправляться ее промежуточные состояния RADIUS серверу. Как только пользователь завершает работу и отключается, pppd отправляет RADIUS серверу уведомление о завершении сессии и о количестве потребленных ресурсов. Как видите решение довольно интересное. Но и у него есть свои минусы и плюсы. Минусами является довольно высокая сложность установки решения, а так же отсутствие детализации трафика. Плюсы заключаются в наличии системы авторизации которую достаточно сложно взломать, возможность привязки ip адреса к имени пользователя, а так же возможности указания лимитов на сессию и автоматическое отключение при из достижении, кроме этого за счет применения стандартных компонент система хорошо масштабируется и стабильна в работе.
Систем использующих эту реализацию довольно много. Но наша цель рассмотреть системы для малых и средних офисов с количеством компьютеров не более 100-200. Среди таких систем представляют интерес FreeNIBS и Cake.

Рассказ о Cake.
В этой статье пойдёт речь о (пока что) малоизвестном биллинге Cake («пирог» в переводе с английского). Эта система предназначена для учёта и контроля трафика, потребляемого на работу в Интернет. Он может с успехом применяться как малыми провайдерами интернет-услуг, так и средних размеров компаниями для внутреннего учёта. Так как принципиальной разницы в каком качестве вы используете биллинг нет (в качестве провайдера или внутри компании), то и заострять на этом внимания не будем.

Этот проект разрабатывается энтузиастами в свободное время и является полностью открытым. Ведут проект всего два человека. Работы по улучшению ведутся постоянно. Биллинг Cake уже был успешно внедрён в нескольких небольших компаниях, занимающихся предоставлением интернет-доступа. А так же в нескольких компаниях для ведения внутреннего контроля по использованию интернет-ресурсов сотрудниками Количество таких компаний увеличивается.

На это есть несколько причин:
• Биллинг распространяется бесплатно под лицензией GPL v.2.
• Просто устанавливается. (Разумеется, иногда возникают сложности, однако, вопросы пользователей разбираются достаточно оперативно на форуме поддержки проекта.)
• Биллинг строится на стандартных GNU компонентах и, фактически, использует то, что уже есть (или есть возможность лёгкой установки) в любой системе.
• Низкий уровень вхождения. Понять принцип работы биллинга не представляет никакой сложности.
• Удобство использования – после установки вся работа ведётся через веб-интерфейс.
• Так как проект открытый, всегда есть возможность изменить какую-либо часть системы под индивидуальные пожелания пользователя. (Например, интерфейс. Об этом чуть ниже.)

Всё это позволяет в крайне сжатые сроки установить ваш «пирог» и приступить к учёту.

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

Наличие биллинга, учитывающего только количество трафика не ограничивает системного администратора никоим образом и не мешает использовать различные анализаторы лог-файлов, например, прокси-сервера. Таким образом предоставляя возможность видеть на какие ресурсы пользователь израсходовал выделенную ему квоту. Биллинг в данном случае будет просто помогать анализу расходов, указывая итоговый трафик пользователя.

Из особенностей биллинга:
Использование только 253 максимально возможных пользователей. Это ограничение вызвано тем, что Cake ещё не обладает должным функционалом работе с несколькими подсетями, поэтому максимум пользователей проистекает из физических ограничений адресации. Если у вас сеть большего размера – система Cake вам не подойдёт.
Каждый пользователь, единожды установив VPN соединение, получает уникальный ip адрес внутреннего пространства VPN сервера. С какого бы в последствии адреса не соединялся этот пользователь, его ip внутренней сети останется неизменным. Это крайне полезное свойство для тех, кто хочет видеть детализацию по трафику, так как позволяет настроить squid с любым анализатором его лог-файлов. Останется лишь привязать логины пользователей к адресам VPN сети и вот готовая детализация похождений пользователей.
Система Cake не может работать с несколькими внешними подсетями, поэтому если вы захотите каким-то пользователям выдавать внешние адреса, а каким-то внутренние — вас ожидает разочарование. Система может работать только с одной подсетью.

Как это работает.
На стороне клиента создаётся подключение к VPN сети. При попытке подключения к pptpd (VPN) серверу, производится запуск pppd для создания VPN туннеля. Для разрешения авторизации pppd обращается к radius, который в свою очередь ищет учётные записи в СУБД и формирует ответ. На основе полученной информации от radius, pppd, если пакет был разрешающий, устанавливает различные параметры соединения (время, трафик) на пользователя. После этого pppd отправляет radius серверу информацию о начале сессии. Сессия завершается, если пользователем (или по другим причинам) разрывается VPN соединение с сервером, а так же, сессию может завершить pppd при превышении лимитов.

Установка.
Система для своей работы использует следующие компонены (некоторые из них уже были названы выше):
Компьютер с *nix системой.
FreeRADIUS версия 0.9.3 и выше.
Pptpd версия 1.1.3 и выше.
PPP версия 2.4.2.b3 и выше.
PostgreSQL сервер версия 7.4.x (если у вас версия 8.x используйте вот эти Cake.opennet.ru/devel схему и веб-интерфейс).
JDK (Sun JDK, Blackdown JDK или BEA Jrockit JDK) версия 1.3 и выше.
Servlet/JSP контейнер. Тестировалось на resin 3.0.x и tomcat 4.1.31
PostgreSQL JDBC Driver используется версия 3x.
Установку можно смело разбить на несколько этапов, каждый из которых достаточно детально описан на сайте разработки (http://npj.ru/Cake/).
Необходимо уточнить, что документация по установке описана для системы gentoo linux, однако, если вы умеете пользоваться дистрибутивом, который выбрали (ведь это так, правда?) — информации с указанных ссылок будет для вас достаточно. В противном случае, вам придётся потратить некоторое время на дополнительное изучение установленного у вас linux дистрибутива.

Архив всех конфигурационных файлов (для Gentoo!) доступен по адресу: Cake.opennet.ru/release/etc/etc.tar.bz2

Я установил систему за один день не встретив каких-либо препятствий при этом. Единственно, хочу обратить внимание на такую ошибку при работе windows клиентов, как 737: loopback detected. Ошибка крайне неприятная, так как при её возникновении данный клиент не сможет подключиться довольно продолжительное время. Это исправляется следующим образом: в конфигурационный файл options.pptpd добавляются строки «nologfd», а строки «silent» и «connect-delay» наоборот комментируются.

Использование.
После того, как система была установлена и заработала, пришло время ввести её в эксплуатацию. Для этого пройдём по адресу, который вы указали resin'у при настройке. Как правило, это ip/Cake или ip:8080/Cake в зависимости от настроек.
По-умолчанию, выставлены login: admin, password: 1234. После входа вы увидите основное окно, в котором показана основная наиболее часто востребованная информация. А именно, состояние биллинга по пользователям (в мегабайтах и денежном эквиваленте), а так же в отдельной таблице показаны пользователи, которые в данный момент соединены с вашим VPN сервером.

Рис 1. Основное окно.
Рис 1. Основное окно.

По умолчанию биллинг содержит лишь одного пользователя администратора. На закладку пользователи стоит прейти для изменения его пароля и добавления пользователей АСР. Здесь вы можете внести всю информацию о пользователе, указав его ФИО, логин, пароль, а так же такую информацию, как тарифный план и необходимость блокировки доступа в интернет при отрицательном балансе пользователя. На этой же странице вносятся платежи на счёт, выделяя таким образом квоту на пользователя.

Рис 2. Упавление учетными записями пользователей.
Рис 2. Упавление учетными записями пользователей.

Если подразумевается использование системы Cake в качестве биллинга для провайдерства, то, вас безусловно заинтересует следующая вкладка «Тарифы». На этой странице задаётся такой параметр, как соотношение денег к мегабайтам или, попросту, цена за мегабайт.

Рис 3. Тарифы.
Рис 3. Тарифы.

Кстати, если вы используете биллинг внутри своей компании, то хорошей идеей будет установить цену за мегабайт ту, по которой продаёт трафик вам провайдер.

Если же вам по каким-то причинам это не удобно, то выставив цену за мегабайт равной одному рублю вы фактически уходите от рублей при выставлении квот. Таким образом внося условный «платёж» на странице пользователя, вы фактически указываете количество мегабайт, не ломая голову вычислениями. Звучит банально, но многие почему-то упускают такое очевидное удобство.

Следующая страница «Отчёты» поможет вам отслеживать интенсивность расхода интернет трафика. Указав интересующий временной интервал, можно вывести как индивидуальную статистику по пользователю, так и по всей системе.

Рис 4. Статистика.
Рис 4. Статистика.

Последняя вкладка в административной панели биллинга, это настройки. Здесь могут быть выставлены следующие параметры:
iddle_timeout – если пользователь не проявляет активности указанный период времени, происходит отключение;
ipnetmask – маска вашей виртуальной подсети;
ipsubnet – виртуальная подсеть в формате «Х.Х.Х»;
max_pool_ip – максимальный ip адрес, который может получить клиент;
max_timeout – максимальное время сессии (в секундах);
max_trafout – максимальный трафик на одну сессию;
min_pool_ip – минимальный ip адрес, который может получить клиент;
taffinterval – период обновления данных о расходе трафика (в секундах).
Оговорюсь, что при изменении параметра max_traffout (максимальный трафик, который может израсходовать пользователь за одну сессию, после чего pppd завершит работу и туннель будет разорван. и последующая переинициализация соединения) следует быть осторожным и не добавлять, как это сделал я, лишний разряд (нолик) в конце числа. К сожалению, после этого никто установить соединение с VPN сервером уже не сможет.

Рис 5. Настройки.
Рис 5. Настройки.

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

Рис 6. Персональная статистика пользователя.
Рис 6. Персональная статистика пользователя.

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

Для этого я изменил пару файлов. По адресу npj.akeeper.ru/akeeper/Cakemodified вы можете найти модифицированные мной jsp файлы. Это stat.all.jsp и report.list.jsp Файлы полные, так что вам потребуется только скопировать их и заменить существующие. Скомпилит их сам сервак. К сожалению, количество исходящего трафика отображается только для пользователей «on-line». Это связано с некоторыми сложностями модификации общей таблицы пользователей. Однако, таже самая полная информация по исходящему трафику слёгкостью доступна на странице отчётов. Как для конкретного пользователя, так и для всех в целом.

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

Текущие работы и дальнейшие планы разработчиков.
Разработчики биллинга, как уже говорилось выше, останавливаться на достигнутом не собираются и по мере возможности (читай по мере появления свободного времени) дорабатывают свой продукт. Из последних изменений можно назвать:
Внесены изменения в структуру базы для возможности работы с PostgreSQL версий 8.x
Схема базы данных приведена к читаемому виду.
Внесены некоторые правки в web-интерфейс системы. (Теперь при использовании web-интерфейса производится только одно соединение к базе данных, а не несколько, как раньше.)
Разрабатывается автоматическая чистка базы статистики.
Появилась возможность работы с нулевыми тарифами.
Учёт обоих направлений трафика (выше, я описал, как его можно увидеть уже сейчас).
Добавляется возможность выставления ограничений как на входящий, так и на исходящий трафик.
Планируется написание документации в gentoo guide xml формате.
Планируется дистрибутив на основе GNAP. (Если в двух словах, то это система сборки дистрибутива для встраиваемых систем. Подробнее можно ознакомиться здесь – www.gentoo.org/proj/en/base/embedded/gnap-userguide.xml). Это даст возможность быстро разворачивать систему по принципу «сел и поехал».
В данный момент разработчики занимаются доработками версии биллинга ветки 1.х Когда все необходимые правки в текущую версию будут внесены, начнётся работа над второй версией продукта. Все планы пока что не раскрываются, но уже известно о планах тарификации таких услуг, как, например, VoIP.

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

(с) akeeperКоршунов Алексей.
Впервый опубликовано в электронном приложении к журналу «Системный администратор» под названием OSA.

Дополнение: недавно мне сообщили, что проект Cake переехал.
Tags:
Hubs:
+3
Comments 7
Comments Comments 7

Articles