Хотспот и с чем его едят…

Данная заметка вряд ли претендует на роль какого бы то ни было how-to. Скорее всего, это еще одна попытка «донести светочь знания» до тех, кто, как говорится в старом анекдоте, «угадал все буквы, но не смог угадать слово». Ну и параллельно, она является описанием тех базовых принципов, на которых построена система предлагаемого мной готового решения для хотспотов ^[1].

Итак, вы решили создать хотспот. Как это сделать? На первый взгляд – вариантов море! Но, опустим совсем «ламерский», типа просто повесить открытую точку доступа. Почему «ламерский»? Да потому что, «кормить бесплатным интернетом соседей и шаровиков», действительно неблагодарное занятие! Хотя, конечно – это ваше личное дело. (Но, просто погуглите немного на тему «где есть открытый wi-fi на шару», и смею вас заверить, через время на этих же форумах напишут и о вашей точке доступа!)

Какие еще могут быть варианты организации хотспота? В общем случае, чтобы управлять процессом так сказать «глобально» – есть только один единственный способ – вы включаете между интернетом и клиентами (точкой доступа) некое оборудование, которое впускает в интернет только ваших клиентов, а всевозможных «шаровиков» отсекает. Что это может быть за оборудование? В простейшем случае – это может быть компьютер с двумя сетевыми адаптерами, включенный между клиентами и интернетом (как показано на рис. 1 ниже) и установленным специализированным программным обеспечением (далее – ПО).

^[2]

С другой стороны, существуют и специализированные аппаратные решения, например, сервисный Hot spot шлюз DSA-3110 hotspot edition ^[3] от D-Link. Это далеко не единственный вариант, но сути дела это не меняет – подобные устройства в первую очередь не обладают достаточной гибкостью, а во вторых, цена их, по крайней мере, не ниже, чем цена упоминавшегося ранее компьютера (без ПО). Что же в таком случае может склонить чашу весов в сторону специализированного оборудования? Лишь одно – возможная цена того ПО, которое нужно будет установить на компьютер для выполнения поставленной задачи. Действительно, зачастую суммарная цена ПО, реализующего все необходимые для хотспота функции, и разработанного для установки на компьютер, работающий под управлением ОС Windows, намного превышает стоимость и самого компьютера, и даже стоимость тех специализированных аппаратных решений, которые существуют на рынке. А ведь еще нужно и за сам Windows заплатить! Нет, оно конечно, на просторах «бывшего союза» «бесплатный» Windows найти совсем не проблема. Но только вот, его использование значительно повышает шанс вплотную познакомиться с законодательством о защите авторских прав и его (законодательства) воплощением…

А с другой стороны, ведь существует еще и «мир иной» – так называемые open-source решения. Они не настолько популярны при использовании их в качестве настольных систем, но попробуйте поинтересоваться миром серверов, и окажется, что там они чувствуют себя намного увереннее. И в то же время, очень многие из этих решений абсолютно бесплатны для использования. Так, одно только использование в качестве ОС вместо Windows какого-нибудь дистрибутива Linux позволяет сходу сэкономить уже полторы сотни долларов. Теперь перейдем к специализированному ПО. Пока что я лишь перечислю службы (серверы), используемые хотспотом, а схему их взаимодействия рассмотрим ниже.

Контроллер доступа. Это аппаратное или программное решение, которое либо выпускает пользователя из локальной сети в интернет, либо нет. От аппаратных средств мы уже отказались, а из программных – взор остановился на Chillispot. Бесплатное ПО с открытым исходным кодом, которое может быть установлено практически на любую *nix операционную систему. Выполняет три функции – во первых, для организации локальной сети запускает свой собственный DHCP-сервер, во вторых, служит шлюзом, который выпускает авторизованных клиентов в интернет, а неавторизованных отсылает на страницу авторизации, и в третьих, предоставляет эту самую страницу авторизации. DHCP сервер используется для того, чтобы максимально упростить клиенту задачу подключения к хотспоту. Страница авторизации позволяет клиенту ввести логин и пароль. При этом страница авторизации — это обычная веб-страница, а следовательно, любой клиент хотспота сможет ввести логин и пароль легко и просто, не зависимо от того, какая ОС установлена на его компьютере, и какой он использует браузер!  Ну а шлюз сверяет предоставленные клиентом данные с базой учетных записей хотспота, и, если все верно, выпускает клиента в интернет. Что нужно для работы Chillispot? Во первых, так как страница авторизации – это обычная веб страница, требуется работающий веб сервер. С другой стороны, нужен сервер авторизации и учета, или говоря иными словами, та самая «база учетных записей хотспота».  Тут нам Chillispot, увы, выбора не оставляет – он может работать только с серверами RADIUS. По этому, использование сервера RADIUS нам, как говорится, «предопределено свыше»…

Разновидностей серверов авторизации, аутентификации и учета (RADIUS) существует множество. Но, «так уж сложилось», что из числа бесплатных и с открытым исходным кодом наиболее популярным и распространенным стал FreeRADIUS.  Присутствует в репозиториях (а следовательно – и легко устанавливается) у превеликого множества дистрибутивов ОС Linux. Настройка на корректную работу с конкретными контроллерами доступа осуществляется простым подключением соответствующих файлов т. н. «словарей» (dictionary). Также, сервер легко настраивается на работу с практически любой базой данных SQL, что во первых, рекомендуется сделать для ускорения работы сервера, а во вторых, позволяет легко организовать взаимодействие с практически любым биллингом, который может писать и читать данные в базах данных SQL.

Биллинг. Это и есть как раз та «надводная часть айсберга», которую единственную видит тот, кто управляет хотспотом. И как следствие, считает ее не просто самым главным компонентом хотспота, а непосредственно самим хотспотом… Не буду спорить – биллинг во многом определяет возможности хотспота. Но без правильно настроенной связки «сервер авторизации и учета» – «контроллер доступа» – сам по себе биллинг не решает ничего. О чем это я? Например, для того, чтобы хотспот предоставил клиенту доступ в интернет только на 10 минут, контроллер доступа должен получить соответствующее указание (атрибут). Такое указание ему должен дать сервер авторизации и учета.  Сервер авторизации и учета должен прочитать этот параметр (10-минутный лимит) в базе учетных записей клиентов. А в базу учетных записей этот самый лимит для данного клиента должен прописать биллинг. В итоге, как видим, даже в том случае, когда биллинг все сделает правильно, остаётся еще два компонента, которые могут «не понять» или «не правильно понять» параметр, и в итоге лимит будет проигнорирован. Таким образом, корректная работа хотспота возможна лишь в случае, если все три выше перечисленные системы правильно настроены на взаимную работу.

Вспомогательными службами в данном случае выступают веб-сервер и сервер баз данных. Из числа широко и бесплатно доступных, а также, легко устанавливаемых в любом дистрибутиве Linux были выбраны Apache и MySQL.

Итоговая схема взаимодействия всей системы выглядит следующим образом (щелкните для увеличения):

^[4]

Рассмотрим процесс взаимодействия всей системы. Клиент подключается к хотспоту и пытается попасть на какой-то сайт в интернете. Chillispot перехватывает DNS-запрос клиента и проверяет — авторизован ли он. Если клиент не авторизован (не вводил логин и пароль ранее), то он перенаправляется на страницу авторизации (сиреневая стрелка на рис. 2). На странице авторизации клиент вводит выданные ему логин и пароль. Страница авторизации отдает полученные от клиента логин и пароль Chillispot-у (сиреневая стрелка). Chillispot полученные логин и пароль отсылает на проверку серверу авторизации и учета RADIUS (зеленая стрелка). Сервер RADIUS полученные данные (логин и пароль) сверяет с данными, хранящимися в базе учетных записей в сервере MySQL (синяя стрелка). По результатам проверки возможны два варианта. Первый — логин и/или пароль не верны. В этом случае сервер RADIUS отвечает Chillispot-у отказом и последний не пускает клиента в интернет, а снова выводит ему страницу авторизации.

Нас же интересует как раз второй вариант — когда пароль и логин совпадают с данными, присутствующими в базе учетных записей. В таком случае сервер RADIUS не спешит подтверждать авторизацию клиента, а первым делом считывает из базы учетных записей ВСЕ атрибуты, которые там найдет для указанного клиента (поиск идет по логину). Атрибуты эти можно разделить на две группы. К первой относятся атрибуты для проверки — *check. Вторая группа атрибутов — это *reply. Атрибуты первой группы сервер RADIUS хранит в своей базе данных в таблице radcheck, атрибуты второй — в таблице radreply. Если же сервер RADIUS настроен на использование групп, и клиент (логин) принадлежит к какой-либо группе, то тогда сервер RADIUS считает еще и групповые атрибуты для данной группы, которые располагаются соответственно в таблицах radgroupchek и radgroupreply. В итоге, если логин и пароль клиента верны, сервер RADIUS сначала выполняет соответствующие проверки для всех тех атрибутов, которые относятся к группе *check. И только когда эти проверки завершены успешно, клиент имеет право получить доступ в интернет. В этом случае сервер RADIUS отсылает контроллеру доступа Chillispot положительный ответ. И в этот же положительный ответ RADIUS добавляет еще и все те атрибуты, которые были считаны для данного клиента и относятся к группе *reply. Что это за атрибуты такие?

К атрибутам группы *check относятся (для случая работы с контроллером доступа Chillispot) например такие как Max-All-Session или Simultaneous-Use.  Первый из них определяет максимальную суммарную длительность всех сессий клиента в интернете. Или, попросту говоря, это тот лимит времени, по истечении которого клиент будет отключен от интернета. При авторизации клиента сервером RADIUS из таблицы учета radacct извлекаются все записи о предыдущих сессиях клиента, их длительность суммируется и затем проверяется, что полученная сумма не превышает указанный лимит. Если лимит превышен, клиенту будет отказано в доступе в интернет. Второй приведенный для примера параметр определяет число клиентов, подключенных к интернету одновременно с указанными логином и паролем. То есть, допустим, указано для клиента, что аттрибут Simultaneous-Use равен 1. Тогда при авторизации клиента сервер RADIUS проверит — сколько на данный момент уже есть открытых сессий с данным логином. И если одна сессия уже открыта (то есть с указанными логином и паролем уже кто-то вошел в интернет), то второму «претенденту» в доступе будет отказано.

Теперь пару слов об атрибутах группы *reply. Это атрибуты, указывающие контроллеру доступа с какими параметрами подключать клиента к интернету. Типичным примером могут служить аттрибуты WISPr-Bandwidth-Max-Down и  WISPr-Bandwidth-Max-Up. Эти атрибуты ограничивают максимальную скорость передачи данных к и от клиента соответственно (лимит скорости). То есть, если если при авторизации клиента в ответе от сервера RADIUS контроллер доступа Chillispot получил в том числе и указанные атрибуты, то скорость подключения клиента к интернету будет органичена присланными значениями.

Приведенные примеры — это лишь малая часть того, что может быть использовано. С полным списком атрибутов, используемых контроллером доступа Chillispot можно ознакомится по данной ссылке ^[5].

Таким образом, как мы видим, от системы требуется следующее:

• Chillispot корректно настроен на взаимодействие с сервером RADIUS, получает от него атрибуты и управляет подключением клиентов.
• Сервер RADIUS настроен на использование атрибутов контроллера доступа Chillispot, а также на использование базы учетных записей, хранящихся в сервере MySQL.
• Биллинг настроен на использование  базы учетных записей, хранящихся в сервере MySQL, и, при создании клиентов корректно вписывает в нее все необходимые атрибуты, используемые контроллером доступа Chillispot и сервером авторизации и учета RADIUS.

К преимуществам такого построения системы можно отнести еще и следующее: данная система может быть легко разделена (разнесена) на несколько узлов. Наиболее логичным выглядит вариант, когда Radius, базы и биллинг расположены на одном сервере (учета), а контроллеры доступа (Chillispot) установлены непосредственно на Wi-Fi роутерах ^[6] и настроены на использование учетных записей, хранящихся на этом сервере. Такой метод позволит построить систему из нескольких хотспотов (зон), использующих единый биллинг (то есть, много точек, расположенных в самых разных местах, управляемых от одного сервер учета).

Ну и напоследок пару слов про биллинговую программу. Лично для себя я выбрал биллинг Easyhotspot ^[7]. (Дополнительно почитать о возможностях программы, самостоятельно попробовать поработать в ее демонстрационной версии и т.д. возможно, если перейти по указанной ссылке ^[8]).

Мои заметки по данной теме еще:

1. Настойка сервера авторизации и учетаRADIUS на совместную работу с MySQL ^[9].
2. Настройка контроллера доступа Chillispot ^[10].
3. Все мои заметки о хотспотах ^[11]