Обращаем внимание на биллинг для провайдера
Практически каждая современная компания, использует в своей работе компьютеры подключенные к сети интернет. Производит ли эта компания какие-либо продукты, занимается их продажей или предоставляет услуги, интернет помогает людям вести свой бизнес. Как всякий ресурс, доступ в интернет нуждается в учёте.
Учет может производится как постфактум при помощи анализа различных лог-файлов прокси-серверов. Но это не позволяет контролировать ресурсы в реальном времени. Для решения этой проблемы существуют специализированные программные комплексы которые обычно называют биллингами. Давайте определимся что такое биллинг и какие функции он может выполнять.
Итак биллинг для провайдера это программно-аппаратный комплекс обеспечивающий доступ, учет и ограничение потребления услуг связи, а так же предоставляющий интерфейс для управления пользователями, услугами и генерации отчетов потребления услуг.
Данный функционал может быть реализован различными средствами. Наиболее популярна реализация биллинга на базе счетчиков фаерволла. Для этого используются скрипты которые считывают их, заносят данные в СУБД (обычно это 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 дистрибутива.
Я установил систему за один день не встретив каких-либо препятствий при этом. Единственно, хочу обратить внимание на такую ошибку при работе windows клиентов, как 737: loopback detected. Ошибка крайне неприятная, так как при её возникновении данный клиент не сможет подключиться довольно продолжительное время. Это исправляется следующим образом: в конфигурационный файл options.pptpd добавляются строки «nologfd», а строки «silent» и «connect-delay» наоборот комментируются.
Использование.
После того, как система была установлена и заработала, пришло время ввести её в эксплуатацию. Для этого пройдём по адресу, который вы указали resin’у при настройке. Как правило, это ip/Cake или ip:8080/Cake в зависимости от настроек.
По-умолчанию, выставлены login: admin, password: 1234. После входа вы увидите основное окно, в котором показана основная наиболее часто востребованная информация. А именно, состояние биллинга по пользователям (в мегабайтах и денежном эквиваленте), а так же в отдельной таблице показаны пользователи, которые в данный момент соединены с вашим VPN сервером.
