Cake: биллинг для малых ISP 0

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

Примечание: Статья была впервые опубликована в электронном издании «Open Source» (выпуск №011 от 30.08.2006). Ее размещение на nixp.ru производится в соответствии с разрешением со стороны редакции и автора материала.

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

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

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

Данный функционал может быть реализован различными средствами. Наиболее популярна реализация биллинга на базе счетчиков файерволла. Для этого используются скрипты, которые считывают их, заносят данные в СУБД (обычно это 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 уже был успешно внедрен в нескольких небольших компаниях, занимающихся предоставлением интернет-доступа, а также в нескольких компаниях для ведения внутреннего контроля по использованию интернет-ресурсов сотрудниками. Количество таких компаний увеличивается.

На это есть несколько причин:

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

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

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

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

Из особенностей биллинга:

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

Как это работает

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

Установка

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

• Компьютер с UNIX/Linux-системой.
• FreeRADIUS версии 0.9.3 и выше.
• pptpd версии 1.1.3 и выше.
• PPP версии 2.4.2.b3 и выше.
• Сервер PostgreSQL версии 7.4.x и выше.
• JDK (Sun JDK, Blackdown JDK или BEA Jrockit JDK) версии 1.3 и выше.
• Servlet/JSP-контейнер. Тестировалось на resin 3.0.x и tomcat 4.1.31.
• PostgreSQL JDBC Driver (используется версия 3).

Установку можно разбить на несколько этапов, каждый из которых достаточно детально описан (на русском языке) на сайте разработки.

Необходимо уточнить, что документация по установке описана для системы Gentoo Linux, однако, если вы умеете пользоваться дистрибутивом, который выбрали, информации с указанных ссылок будет для вас достаточно.

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

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

Использование

После того, как система была установлена и заработала, пришло время ввести ее в эксплуатацию. Для этого пройдем по адресу, который вы указали resin’у при настройке. Как правило, это http://ip/Cake/ или http://ip:8080/Cake в зависимости от настроек.

По умолчанию выставлены следующие значения для логина и пароля: admin и 1234 (соответственно). После входа вы увидите основное окно, в котором показана наиболее часто востребованная информация, а именно: состояние биллинга по пользователям (в мегабайтах и денежном эквиваленте), а также в отдельной таблице показаны пользователи, которые в данный момент соединены с вашим VPN-сервером.

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

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

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

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

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

Последняя вкладка в административной панели биллинга — это настройки. Здесь могут быть выставлены следующие параметры:

• iddle_timeout — если пользователь не проявляет активности указанный период времени, происходит отключение;
• ipnetmask — маска вашей виртуальной подсети;
• ipsubnet — виртуальная подсеть в формате «Х.Х.Х»;
• max_pool_ip — максимальный IP-адрес, который может получить клиент;
• max_timeout — максимальное время сессии (в секундах);
• max_trafout — максимальный трафик на одну сессию;
• min_pool_ip — минимальный IP-адрес, который может получить клиент;
• taffinterval — период обновления данных о расходе трафика (в секундах).

Оговорюсь, что при изменении параметра max_traffout (максимальный трафик, который может израсходовать пользователь за одну сессию, после чего pppd завершит работу и туннель будет разорван, и последующая переинициализация соединения) следует быть осторожным и не добавлять, как это сделал я, лишний разряд (нолик) в конце числа. К сожалению, после этого никто установить соединение с VPN-сервером уже не сможет.

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

Текущие работы и дальнейшие планы разработчиков

Разработчики биллинга, как уже говорилось выше, останавливаться на достигнутом не собираются и по мере возможности (читай: по мере появления свободного времени) дорабатывают свой продукт. Из последних изменений можно назвать:

• Внесены изменения в структуру базы для возможности работы с PostgreSQL версий 8.x.
• Схема базы данных приведена к читаемому виду.
• Внесены некоторые правки в web-интерфейс системы. (Теперь при использовании web-интерфейса производится только одно соединение к базе данных, а не несколько, как раньше.)
• Разрабатывается автоматическая чистка базы статистики.
• Появилась возможность работы с нулевыми тарифами.
• Учет обоих направлений трафика (выше я описал, как его можно увидеть уже сейчас).
• Добавляется возможность выставления ограничений как на входящий, так и на исходящий трафик.
• Планируется написание документации в формате gentoo guide xml.
• Планируется дистрибутив на основе GNAP. (Если в двух словах, то это система сборки дистрибутива для встраиваемых систем. Подробнее можно ознакомиться здесь). Это даст возможность быстро разворачивать систему по принципу «сел и поехал».

В данный момент разработчики занимаются доработками версии биллинга ветки 1.х. Когда все необходимые правки в текущую версию будут внесены, начнется работа над второй версией продукта. Все планы пока что не раскрываются, но уже известно о планах тарификации таких услуг, как, например, VoIP.

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