Вопрос: DSA-3100: аутентификация и аккаунтинг через RADIUS

Ответ: 

Всем известно, что в DSA-3100 встроена биллинговая система, которая умеет тарифицировать пользователей на основе использованного времени. Данная биллинговая модель является идеальным решением для заграничных интернет кафе, потому как во всём развитом мире интернет тарифицируют по времени доступа (и/или по толщине канала). В России тоже есть определённое движение в данном направлении, прежде всего - это быстрое снижение цен на трафик. Конечной точкой этого движения скорее всего также будет переход на тарификацию по времени, и случится это когда себестоимость подсчёта трафика превысит его стоимость (как предрекают многие). Но пока, к сожалению, везде тарифицируется трафик и в связи с этим поступает огромное количество просьб сделать так, чтобы "DSA-3100 умел считать трафик".

На самом деле DSA-3100 всё-таки "умеет считать трафик" =) и делает он это когда работает в качестве NAS-сервера (Network Autentification Server). Аутентификация при этом проводится через RADIUS-сервер. Единственным минусом такого решения является невозможность использования совместно с DSA-3100 принтера для распечатки чеков-доступа DSA-3100P. Т.е. в конкретный момент времени шлюз может проводить аутентификацию только одим из возможных способов (если используется тикет-принтер, то аутентификация проводится через локальную базу, если RADIUS - то через внешнюю). Ещё одним важным свойством такой системы является то, что её скорее всего придётся немного доработать "ручками", что подсилу в основном опытным сетевым интеграторам или конечным пользователям; но не боги горшки обжигают, так что неопытным тоже есть над чем подумать, тем более что готовая биллинговая система стоит обычно немалых денег.

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

- предоплата услуги (prepaid billing model): пользователь покупает где-либо карту предоплаты, активирует её через веб-сайт открытый в хотспоте для свободного просмотра (напомню, что DSA-3100 позволяет задавать такие адреса или целые подсети), или же пользователь оплачивает доступ в офисе оператора, или каким либо другим способом.

  • оплата по факту (postpaid billing model): пользователь ничего не оплачивает, пользуется услугой, затем оператор выставляет ему счёт за пользование услугой.
  • биллинг может быть построен как на учёте трафика, так и на учёте времени.

Теперь более подробно о том, как будет выглядеть наша учётно-биллинговая система и как она будет работать. Схема сети при этом стандартная для архитектуры с RADIUS: LAN ---> NAS--->RADIUS--->WAN: (NAS в нашем случае работает как прокси-сервер (в DSA-3100 включён NAT)).


В качестве RADIUS'a используем компьютер под управлением Win2k server c WinRadius 2.21. WinRadius - это стандартный RADIUS сервер, который умеет работать с различными базами данных (MSAccess (по умолчанию), MSSQL, Oracle). Самое главное, что когда пользователь аутентифицируется на DSA-3100 через RADIUS, шлюз отправляет в базу данных, с которой он работает, аккаунтинговые пакеты, содержащие информацию о количестве использованного трафика.

Demo версию WinRadius 2.29 можно взять здесь: www.itconsult2000.com
/ограничение демо версии : можно создать не более пяти пользователей /

WinRadius - небесплатная программа, обе версии и под Windows и под Linux стоят более-менее приличных денег (цена зависит от типа лицензии). WinRadius довльно легко устанавливается под Windows, поэтому его используем в качестве плацдарма для экспериментов.

Итак, проделаем следующее:
- поставим WinRADIUS и немного настроим его
- настроим WinRADIUS на взаимодействие с БД MSAccess ( настроим драйвер базы данных ODBC)
- настроим шлюз DSA-3100 на работу с нашим WinRADIUS'ом
- создадим пользователя на сервере RADIUS
- аутентифицируемся и посчитаем трафик (посмотрим как это всё записалось в БД)
- сделаем маленький веб-интерфейсик к биллинговой системе, реализующий некоторый функционал

.:: Настройка WinRADIUS

Settings---->System


Settings---->Logs


Settings---->Multisecret


.:: Настраиваем драйвер базы данных ODBC
Для работы нашего RADIUS'а с БД MSAccess (файл базы данных есть в дистрибутиве WinRADIUS - WinRadius.mdb).
ODBC - это абривеатура от Open DataBase Connectivity (примерный перевод - открытая система связи с базами данных) - это некий универсальный интерфейс к различным базам данных. Что-то вроде прослойки между пользовательскими приложениями и базами данных, которая позволяет скрыть особенности той или иной БД и унифицировать свойства всех источников данных.

Заходим вот сюда "Control Panel" ---> Administrative Tools ---> Data Sources (ODBC) ---> жмём "Add"

Выбираем "Driver do Microsoft Access (*.mdb)" ---> жмём "Finish"



--> В поле "Data Source Name" вписываем "WinRadius"
--> В поле Description пишем что хотим
--> нажимаем "Select", находим директорию, в которой установлен WinRADIUS, и находим там файл WinRadius.mdb
--> press "OK"

.:: Настраиваем DSA-3100 на работу с сервером RADIUS
Задаём DSA-3100 внешний и внутренний IP адреса, далее заходим в HOME-->UserManager-->ManagementType-->RADIUS, где задаём IP адрес сервера RADIUS и другие необходимые атрибуты, как это показано на скриншоте.

.:: Заводим пользователей на RADIUS'е: Жмём на плюс, выскакивает форма создания юзера:

"User name" и "Password" - имя и пароль

"Group" - пользователей в винрадиусе для удобства можно относить к какой-либо группе, впишем, например, "1".

"Cash prepaid" - в этом поле вписывается сколько денег на счету пользователя, если используется биллинговая модель с предоплатой.

"Expiry date" - время, до которого будет действовать аккаунт.

"Prepaid user / Postpaid User" - здесь выбирается по какой схеме пользователь будет оплачивать услугу. С предоплатой или нет; учитыватся будет трафик или время. Если юзер предоплачивает услугу, то есть возможность задать сумму на счете, по достижении которой доступ блокируется. Делается это вот здесь: Settings--> Authentification-->Prepaid-->Desposit. Следует отметить, что принудительного разрыва открытой сессии, если лимит трафика превышен, в проведённых экспериментах получить не удалось, скорее всего этот функционал должен поддерживатся со стороны сервера RADIUS. При превышении установленного лимита, после logout'a (самостоятельного или наступившего по неактивности пользователя), открыть новую ссессию пользователь не сможет .

Итак, создаём 5 юзеров (больше к сожалению нельзя - демо версия WinRadius'а не позволяет, но он не единственный на свете, просто он под виндовс и поэтому легко приводить на нём пример), всем назначаем аккаунтинг на базе использованного трафика. Затем пробуем аутентифицироватся: на компьютере, который подключён к Authentification порту DSA-3100, набираем какой-либо URL, шлюз перехватывает его и выдаёт нам форму для аутентификации (всё разумеется под защитой SSL). Процесс аутентификации, начала пользовательской сессии (отмечено красным), а также завершение пользовательской сессии (отмечено зелёным) отображается в окне WinRadius'a:

Все данные, которыми оперирует WinRadius, хранятся в базе данных (данные - это пользовательские аккаунты и логи). Откроем в MsAcsess файл WinRadius.mdb и посмотрим как выглядит база данных нашего RADIUS'a - а выглядит она довольно просто. Видим в ней три таблицы :

1. Таблица tbLogs (в которую чудесным образом записались все данные о количестве трафика, который прокачали 5 тестовых пользователей=)

"happen" - в это поле пишется время начала пользовательской сессии"username" - здесь всё ясно - имя пользователя"called" - поле осталось неопознанным"duration" - продолжительность пользовательской сессии в секундах"input/output"- количество входящего/исходящего трафика в байтах"fee" - стоимость входящего+ исходящего прокачанного трафика согласно тарифу, установленному здесь: Settings-->Accounting method-->Based on Traffic.

2. Таблица tbUsers (в которой мы видим созданных пользователей)

"username/password" - имя / пароль пользователя.
"groups" - группа к кот. относится пользователь (для чего нужны группы осталось непонятным, наверное на всякий случай).
"addr" - адрес юзера.
"cash" - cостояние счёта (очень важное поле). Обратите внимание, что у пользователя "user3" значение этого поля отрицательное, а учитывая то, что он тарифицируется по предоплате и то, что вот здесь (Settings--> Authentification-->Prepaid-->Desposit) мы поставили нолик (пользователи у кот будет нулевой или отрицательный балланс будут отключатся), аутентификацию он пройти не может до тех пор, пока не пополнит свой счёт.
"expire" - время, до которого действителен пользовательский аккаунт.
"others" - поле в кот. пишутся специальные заметки.
"method" - в поле помечается, на основе чего проходит таррификация - на основе трафика или времени.
"biltype" - здесь указывается биллинговая модель, применяемая к пользователю: с предоплатой, с оплатой после пользования услугой.

Третья таблица (tbVoIP) базы данных WinRadius'a предназначена для таррификации VoIP телефонии, поэтому её рассматривать не будем.

.:: Доработка системы
Итак, вроде бы всё очень хорошо - пользователи аутентифицируются, трафик считается, единая база данных позволяет осуществлять роуминг между хотспотами, роуминг между точками доступа внутри хотспота осуществляется средствами IAPP (Inter Access Point Protocol), но чего-то вроде бы и не хватает. А не хватает следующего: возможности пользователям просматривать текущее состояние своего счёта, возможности пополнять счёт (чтобы это мог делать сам пользователь или администратор/оператор системы), возможности для удобного администрирования системы, в которой, например, будет несколько NAS серверов DSA-3100 (сеть хотспотов или интернет кафе), т.е. количество пользователей будет довольно приличным.

Как же всё это реализовать? Ответ напрашивается сам собой: нужно сделать пользовательский и администраторский веб-интерфейс, который будет брать/класть данные в нашу базу данных. Пусть всё это работает на веб-сервере, работающем на том же компьютере, на котором работает RADIUS. Веб-сервер мы поместим в зону, свободную для просмотра (в DSA-3100 позволяет это сделать), чтобы даже пользователи, у кот. нулевой или отрицательный баланс, могли зайти на страницу статистики/пополнения счёта.

Выбираем веб-сервер: компьютер у нас под Win2k-server, значит скорее всего будем использовать Apache for Windows или IIS (Internet Information Services). Если выберем Apache, то будем писать веб-страницы со скриптами на PHP (Perl и т.д. и т.п.), если выберем IIS, тогда будем использвать технологию ASP (Active Server Pages) и веб-страницы со скриптами будем писать на VBS (Visual Basic Script - очень похож на бейсик, который все мы изучали в школе =) или на JavaScript'e (есть конечно ещё много разных вариантов - на чём писать и что использовать, перечислил то, что лежит на поверхности). Остановимся, пожалуй, на IIS'е с ASP'ом и VBS - вариант наиболее простой для понимания и освоения. Весь перечисленный функционал реализовывать не будем, но кое что всё-таки реализуем для примера.

В трёх словах, для тех кто всё ещё не понимает, что собираемся делать:

- IIS (Internet Information Services)- это веб-сервер, который "идёт в комплекте с виндовс2000 сервером"; веб-сервер это такая программа, которая отдаёт странички тем кто их запрашивает, а запрашивают их браузеры (браузер программа, через которую смотрим интернет =)

- ASP (Active Server Page) - технология "встроенная в IIS", которая позволяет создавать страницы, содержащие скрипты (наборы спец. команд); скрипты эти могут обращатся к базам данных для извлечения/записи каких-либо данных (то, что мы будем использовать) и ещё много чего они могут делать, эти скрипты. Точнее, скрипты сами по себе ничего делать не могут, они обращаются к объектам, которые встроены в веб-сервер и наделены определённой функциональностью ).

- VBS (Visual Basic Script) - это простой язык, на котором мы будем писать наши скрипты (которые по сути являются набором команд для веб-сервера).

.:: Создаём сайт на веб-сервере IIS

1. Control Panel ---> Administrative Tools ---> Internet Services Manager (оснастка управляющая IIS).

2. Правой мышкой по компьютеру ---> New ---> Web Site ---> запустился визард ---> пишем название сайта (любое) ---> назначаем ему IP адрес ---> указываем папку, которая будет домашним каталогом сайта (туда будем складывать веб-странички со скриптами)---> ничего не трогаем, жмём >next> ---> >Finish>. Сайт готов, он появился в левой половине оснастки.

.:: Script №1
Для начала сделаем страницу со скриптом, который просто обращается к нашей БД и полностью извлекает оттуда содержимое таблицы tbLogs. Делать можно в чём угодно, в том числе и в блокноте (номера строк писать не надо - это для удобства). Файл назовём bd.asp (можно его взять вот [здесь] --> правой мышкой-->сохранить как-->обязательно указать расширение "asp" ---> этот файл нужно скопировать в домашний каталог сайта).

bd.asp

 

Разбор bd.asp :

строки 1-6: здесь всё понятно - простой HTML

строка 8: Значок "".

строки 33-34: Конец страницы.

Результат обращения к данной странице (результат выполнения скрипта):
<%" открывает скрипт. При помощи метода CreateObject объекта Server создаётся соединение ADO - MyConnection (кот. в свою очередь тоже является обьектом и тоже имеет набор свойств и методов).

строки 10-13: При помощи метода OPEN объекта MyConnection открывается соединение с базой данных RADIUS'a. В строке соединения (строки 11-13) задаются параметры соединения с БД (по порядку): драйвер, имя файла БД, директория с файлом БД (не забудте вписать туда свою директорию), имя, пароль (пароль не задан и это, конечно же, надо тоже исправить).

строка 15: При помощи метода Execute объекта MyConnection Выполняем SQL-запрос и ответ кладём в переменную rsLogs (которая является рекордсетом - по сути это массив, содержащий результат запроса к БД). Структура этой переменной определяется запросом, т.е. если на выходе будет таблица, то rsLogs будет иметь структуру данной таблицы. Чтобы вывести данные из этого рекордсета, надо организовать цикл, выполняющийся до тех пор, пока рекордсет не будет прочитан, что мы и делаем в последующих строках (22-28).

строки 17-21: Делаем шапочку для таблицы, в которой будут отображены данные считанные из БД.

строка 22: Начало цикла, в котором будем читать и выводить рекордсет до тех пор, пока он некончится (not rsLogs.EOF).

строки 23-26: Выводим рекордсет в таблице на печать (всмысле на экран). Делаем это при помощи метода write объекта Response. Если содержимое вывода является HTML'ом, то помещаем его в кавычки; если содержимое вывода какая-либо переменная, то пишем её без кавычек. HTML и переменные можно чередовать в выводе, объединяя их символом "&".

строка 27: Перемещаемся на следующую строку рекордсета (ведь он есть таблица, а у таблиц обычно много строк =).

строка 28: Идём вначало цикла.

строка 30: Закрываем теги, которые мы открыли перед циклом вывода данных (22-28).

строки 31-32: Закрываем рекордсет и скрипт символом "%>

Набираем в браузере http://IP веб-сайта/bd.asp
В ответ получаем содержимое таблицы БД, в которую сложились логи с DSA-3100, выступающего в качестве NAS.
(думаю, что у всех всё заработало=).

.:: Script №2

Теперь реализуем функционал, позволяющий пользователю смотреть статистику своих соединений, страницу статистики защитим паролем. Вся обработка обращения пользователя будет осуществлятся одной страницей, в которой будет выполнятся та или иная часть скрипта в зависимости от того, что пользователь введёт в поля "логин" и "пароль" (этот метод называется "рекурсивная обработка формы"). Слева показано, как будет выглядеть приглашение для ввода логина и пароля ---------> Файл назовём bd2.asp --> правой мышкой-->сохранить как-->обязательно указать расширение "asp" ---> этот файл его тоже нужно скопировать в домашний каталог сайта).

Логика работы страницы следующая:
1. проверяем введено ли что-нибудь в поля "логин" и "пароль"
- если оба поля не заполнены, или не заполнено какое-либо одно поле, то снова выдаём пустую форму (т.е. возвращаемся к пункту 1)
- если оба поля заполнены, то переходим к пункту 2
2. обращаемся к БД и проверяем правильность логина и пароля
- если пароль и логин правильные, то выдаём пользователю статистику его соединений
- если не правильные, выдаём сообщение "Неправильное или несуществующее имя пользователя или пароль!"

bd2.asp

 

Разбор bd2.asp :
строки 1-6: здесь всё понятно - простой HTML
строка 7: Значок "<%" открывает скрипт.
строки 8,9: Объявляем переменные, в которые считаем из формы логин и пароль.
строки 11,12: Получаем логин и пароль из POST запроса
строка 14: Начало условия (проверяем введено ли имя пользователя и пароль -сравниваем то, что получили из запроса с пустотой)
строки 16-22: Выводим чистую форму, если пользователь не заполнил оба или одно из полей "логин" и "пароль"
строка 24: Конец условия
строка 25: Конец скрипта
строка 26: Начало нового скрипта, который будет выполнятся в том случае, если имя и пароль введены
строка 27-32: Подключаемся к БД
строка 34: Формируем SQL запрос к БД, который выбирает пароль для пользователя с именем, которое введено в форму
строка 36: Выполняем запрос
строка 37: Объявляем переменную "pas" и приравниваем её к пустышке
строки 38-41: Читаем рекордсет и присваиваем его значение переменной "pas", если бы в базе не нашлось пароля для введённого имени, тогда бы переменная "pas" осталась бы пустышкой.
строка 43: Если выбранный пароль совпадает с введённым, то выполняем с 45 по 76 строку; если не совпадает, тогда выполняем строку 80 - выдаём "Неправильное или несуществующее имя пользователя или пароль!"
строки 45-76: Делаем запрос к БД, в ответ получаем выборку для нужного пользователя. Выводим статистику на экран в удобной форме. Response.End (76 строка) означает конец вывода.
строка 77: Конец условия.
строка 79: Если условие не выполнилось, т.е. пользователь ввёл неправильный пароль или имя - выдаём соответствующее сообщение.
строки 83-84: Конец страницы.

Результат обращения к bd2.asp (результат выполнения скрипта):

Заходим на страницу, получаем форму для ввода логина и пароля (неплохо было бы и здесь использовать SSL, чтобы враги не перехватили открытый POST-запрос c логином и паролем) вводим правильные логин и пароль, получаем результат --->

(если логин или пароль неправильные, то ничего не получаем)

.:: Заключение

На первый взгляд всё довольно сложно и запутанно. Но если приглядется ничего сложного нет: NAS серверы в роли которых выступают DSA-3100 проводят аутентификацию пользователей и пишут статистику в единую базу данных RADIUS'a. Для реализации различных дополнительных (практически любых) функций биллинга разрабатываем веб-интерфейс, для чего используем ASP или PHP.

Итак, подведём итоги:

RADIUS (найдём бесплатный или купим) + NAS (DSA-3100) + Access Points (DWL-1700AP, DWL-2100AP, DWL-2700AP, DWL-1040AP+ и т.д.) +WEB интерфейс (напишем сами) = ГОТОВОЕ РЕШЕНИЕ ДЛЯ ОРГАНИЗАЦИИ СЕТИ ХОТСПОТОВ.

Platonov@tayle.com

по материалам, подготовленным компанией "ТАЙЛЕ"
тел/факс: (095) 903-8300, 903-0091
e-mail: office@tayle.com