Что нужно для организации хотспота? В общем случае, чтобы полностью управлять процессом доступа клиентов хотспота в интернет существует единственный способ – между интернетом и клиентами (точкой доступа) установлено некое оборудование, которое впускает в интернет только ваших клиентов, а всевозможных «шаровиков» отсекает. Это же оборудование ограничивает (при желании) скорость клиентов, считает либо время, проведенное клиентами в интернете, либо трафик, потребленный ими, и при превышении отведенных лимитов автоматически отключает их от интернета. Что это может быть за оборудование? В простейшем случае – это может быть компьютер с двумя сетевыми адаптерами, включенный между клиентами и интернетом (как показано на рис. ниже), и установленным специализированным программным обеспечением (далее – ПО).
Теперь рассмотрим это самое "специализированное ПО". Пока что я лишь перечислю службы (серверы), используемые хотспотом, а схему их взаимодействия рассмотрим ниже.
Контроллер доступа (NAS - Network Access Server). Это аппаратное или программное решение, одной из функций которого является как раз выпускать пользователей из локальной сети в интернет. Рассмотрим программный контроллер доступа Chillispot. Бесплатное ПО с открытым исходным кодом, которое может быть установлено практически на любую *nix операционную систему. Выполняет три функции – во первых, для организации локальной сети (присвоения IP-адресов клиентам хотспота) запускает свой собственный DHCP-сервер, во вторых, служит шлюзом, который выпускает авторизованных клиентов в интернет (управляя их скоростью и подсчитывая время и трафик), а неавторизованных отсылает на страницу авторизации, и в третьих, предоставляет эту самую страницу авторизации. DHCP сервер используется для того, чтобы максимально упростить клиенту задачу подключения к хотспоту. Страница авторизации, являясь по сути обычной веб-страницей, позволяет любому клиенту, независимо от ОС и браузера, используемых на его Wi-Fi устройстве, авторизоваться - т.е. ввести логин и пароль. Ну а шлюз сверяет предоставленные клиентом данные с базой учетных записей хотспота, и, если все верно, выпускает клиента в интернет. Что нужно для работы Chillispot? Во первых, так как страница авторизации – это обычная веб страница, требуется работающий веб сервер. С другой стороны, нужен сервер авторизации и учета, или говоря иными словами, та самая «база учетных записей клиентов хотспота». Тут нам Chillispot, увы, выбора не оставляет – он может работать только с серверами RADIUS. По этому, использование сервера RADIUS нам, как говорится, «предопределено свыше»…
Разновидностей серверов авторизации, аутентификации и учета (RADIUS) существует множество. Но, «так уж сложилось», что из числа бесплатных и с открытым исходным кодом наиболее популярным и распространенным стал FreeRADIUS. Присутствует в репозиториях (а следовательно – и легко устанавливается) у превеликого множества дистрибутивов ОС Linux. Настройка на корректную работу с конкретными контроллерами доступа осуществляется простым подключением соответствующих файлов т. н. «словарей» (dictionary). Также, сервер легко настраивается на работу с практически любой базой данных SQL, что во первых, рекомендуется сделать для ускорения работы сервера, а во вторых, позволяет легко организовать взаимодействие с практически любым биллингом, который может писать и читать данные в базах данных SQL.
Биллинг Это и есть как раз та «надводная часть айсберга», которую единственную видит тот, кто управляет хотспотом. И как следствие, считает ее не просто самым главным компонентом хотспота, а непосредственно самим хотспотом… Не буду спорить – биллинг во многом определяет возможности хотспота. Но без правильно настроенной связки «сервер авторизации и учета» – «контроллер доступа» – сам по себе биллинг не решает ничего. О чем это я? Например, для того, чтобы хотспот предоставил клиенту доступ в интернет только на 10 минут, контроллер доступа должен получить соответствующее указание (атрибут). Такое указание ему должен дать сервер авторизации и учета (RADIUS). Сервер авторизации и учета должен прочитать этот параметр (10-минутный лимит) в базе учетных записей клиентов. А в базу учетных записей этот самый лимит для данного клиента должен прописать биллинг. В итоге, как видим, даже в том случае, когда биллинг все сделает правильно, остаётся еще два компонента, которые могут «не понять» или «не правильно понять» параметр, и в итоге лимит будет проигнорирован. Таким образом, корректная работа хотспота возможна лишь в случае, если все три выше перечисленные системы правильно настроены на взаимную работу.
Вспомогательными службами в данном случае выступают веб-сервер и сервер баз данных. Из числа широко и бесплатно доступных, а также, легко устанавливаемых в любом дистрибутиве Linux были выбраны Apache и MySQL.
Итоговая схема взаимодействия всей системы выглядит следующим образом :
Рассмотрим процесс взаимодействия всей системы. Клиент подключается к хотспоту и пытается попасть на какой-то сайт в интернете. Chillispot перехватывает DNS-запрос клиента и проверяет — авторизован ли он. Если клиент не авторизован (не вводил логин и пароль ранее), то он перенаправляется на страницу авторизации (сиреневая стрелка на рис.). На странице авторизации клиент вводит выданные ему логин и пароль. Страница авторизации отдает полученные от клиента логин и пароль Chillispot-у (сиреневая стрелка). Chillispot полученные логин и пароль отсылает на проверку серверу авторизации и учета RADIUS (зеленая стрелка). Сервер RADIUS полученные данные (логин и пароль) сверяет с данными, хранящимися в базе учетных записей в сервере MySQL (синяя стрелка). По результатам проверки возможны два варианта. Первый — логин и/или пароль не верны. В этом случае сервер RADIUS отвечает Chillispot-у отказом и последний не пускает клиента в интернет, а снова выводит ему страницу авторизации.
Второй вариант - пароль и логин совпали с данными, присутствующими в базе учетных записей клиентов хотспота. В таком случае сервер RADIUS проверяет "баланс" клиента, считывает из базы возможные лимиты скоростей, времени, мегабайт и т.д. и отсылает эти данные контроллеру доступа. Контроллер доступа выпускает клиента в интернет. Когда клиент израсходует отведенные ему лимиты, Chillispot автоматически отключит его от интернета.
Таким образом, как мы видим, от системы требуется следующее:
- Chillispot корректно настроен на взаимодействие с сервером RADIUS, получает от него атрибуты и управляет подключением клиентов.
- Сервер RADIUS настроен на использование атрибутов контроллера доступа Chillispot, а также на использование базы учетных записей, хранящихся в сервере MySQL.
- Биллинг настроен на использование базы учетных записей, хранящихся в сервере MySQL, и, при создании клиентов корректно вписывает в нее все необходимые атрибуты, используемые контроллером доступа Chillispot и сервером авторизации и учета RADIUS.
К преимуществам такого построения системы можно отнести еще и следующее: данная система может быть легко разделена (разнесена) на несколько узлов. Наиболее логичным выглядит вариант, когда Radius, базы и биллинг расположены на одном сервере (учета), а контроллеры доступа (Chilispot) установлены непосредственно на Wi-Fi роутерах и настроены на использование учетных записей, хранящихся на этом серевре. Такой метод позволит построить систему из нескольких хотспотов (зон), использующих единый биллинг (то есть, много точек, расположенных в самых различных местах, управляемых от одного сервер учета, но об этом мы поговорим позже..).
Ну и напоследок пару слов про биллинговую программу. Лично для себя я выбрал биллинг Easyhotspot и модернизировал его. (Его возможности, преимущества и остальное - подробно описаны вот в этой заметке)...