Новости программы Easyhotspot, июнь…ноябрь 2018

Новости — июнь…ноябрь 2018

С момента прошлой публикации в программе произошли следующие изменения:

  • Изменения в веб-интерфейсе Easyhotspot («черной админке»);
  • Обновления и исправления модулей
  • Обновления и изменения скрипта-инсталятора
  • Изменения в документации

Изменения в веб-интерфейсе Easyhotspot («черной админке»)

  • Версия фреймворка Codeigniter (на котором написана «черная админка») обновлена до 3.1.9. Что при этом изменилось в самом Codeigniter можно прочесть в «Change Log» на их сайте. В свою очередь, для Easyhotspot это — банальное поддержание актуальности базового фреймворка;
  • Немного изменены настройки редактора TinyMCE: добавлена кнопка прямого редактирования html-кода и добавлен вызов текстовых сообщений на украинском языке, когда он украинский язык выбран в «черной админке»;
  • Исправлена ошибка нового кабинета: в меню вызова страниц платежных систем кнопка для п/с Mixplat открывала ошибочную ссылку (несуществующую страницу);
  • Изменен формат экспорта данных из программы — добавлена библиотека PHPExcel, и все отчеты, которые ранее выводилось в виде CSV-файлов, теперь выводятся в формате MS Office Excel (2007);
  • Параллельно ряд отчетов был сделан «более красивыми». Например, экспорт данных из архива теперь выводится на трех листах одного xlsx-файла. На первом листе выводятся сведения об аккаунтах, на втором — о платежах, и на третьем — о сеансах доступа в интернет;
  • При экспорте в xlsx-файл из архива данных об аккаунте возникала ошибка создания «многостраничного» файла электронной таблицы, ЕСЛИ В БАЗЕ НЕ БЫЛО СВЕДЕНИЙ О «ПОКУПКЕ». Ошибка исправлена;
  • Обновлен отчет о ваучерах при экспорте в xls-файл. Если ранее в нем выводились только логин и пароль, то теперь список параметров расширен, и в него входят такие сведения: Номер, Логин, Пароль, Имя Тарифного пакета, Дата и время создания ваучера, MAC-адрес клиента, Данные из графы «Паспорт», Дата и время активации ваучера, Дата и время окончания срока годности ваучера, Суммарное время доступа в интернет по ваучеру, Суммарный объем трафика, потребленный ваучером, ID хотспота (NASID);
  • Попутно была обнаружена и устранена ошибка, которая ранее во время экспорта (еще в CSV) результатов работы платежных модулей могла приводить к удалению из базы этих данных (уже после их экспорта), даже если администратор не ставил «птичку» о желании такого удаления;
  • Была обнаружена и исправлена ошибка редактирования «клиента с оплатой по счету» (postpaid). Для того, чтобы она проявилась, нужно было, чтобы сначала (когда-то ранее) в программе приключился глюк. Суть ошибки заключалась в следующем: Freeradius при проверке авторизации клиентов в том числе использует данные из таблицы radcheck. Одной из таких записей, размещенных в таблице radcheck, является пароль клиента. При редактировании учетной записи клиента с оплатой по счету код биллинга обновлял запись с паролем в таблице radcheck. Но в момент обновления сам факт наличия в базе radcheck такой записи (с паролем) биллинг не проверял. В нормальной ситуации все происходило успешно, и отредактированный клиент потом успешно авторизовался по новому паролю. Но отношение самого сервера MySQL к обработке запроса на обновление записи звучит так: «да, запрос на обновление был получен и выполнен. но, если самой обновляемой записи при этом не было, мы это ошибкой не считаем» 🙂 … В итоге ошибка проявлялась лишь В ТОМ СЛУЧАЕ, если по каким-то «неизвестным причинам» из таблицы radcheck (когда-то ранее) уже пропала запись о пароле клиента. И вот тогда — обновляй, не обновляй аккаунт клиента в биллинге, а пароля у него в таблице radcheck так и не появлялось! И в итоге такой клиент авторизоваться больше уже не мог и постоянно получал отказ. Ошибка исправлена! И, повторюсь, в нормальной ситуации эта ошибка вообще не проявлялась…
  • При редактировании (ОБНОВЛЕНИИ) настроек фирмы-агрегатора для функции отправки служебных СМС у клиента происходила ошибка — новые данные не записывались в базу программы (у себя эту ошибку так и не смог воспроизвести). Был изменен код функции (сам алгоритм записи настроек в базу), ошибка «ушла»;
  • В код биллинга была добавлена функция переключения ваучеру тарифа с «первого» на «второй» по истечении лимита, отведенного «первым» тарифным пакетом. Что дает этот «финт»? Такой себе «двухскоростной» режим обслуживания! Вы должны будете создать два тарифа: первый — «быстрый и недолгий», и второй — с длительным доступом, но с низкой скоростью. Затем создаете ваучер первого тарифа и даете его клиенту. Клиент по такому ваучеру сначала пользуется быстрым интернетом в течение какого-то времени, и по истечении номинала первого тарифа его отключит от интернета. Описываемая тут функция найдет ваучер «первого» тарифа с израсходованным номиналом, и сменит ему тариф на «второй». Клиент подключится к интернету снова, но уже на низкой скорости. И в таком медленном режиме он сможет пользоваться интернетом до тех пор, пока не израсходует «номинал» второго (более длинного) тарифа;
  • В биллинг добавлена функция, которая выгружает на указанный в (её) настройках SFTP-сервер xlsx-файл со сведениями обо всех сеансах доступа в интернет за предыдущий день, включая и сведения из графы «паспорт» для соответствующего аккаунта (в эту графу автоматизированные модули Easyhotspot-а вносят номер мобильного телефона клиента);
  • В список агрегаторов функции отправки служебных СМС добавлена фирма АЛЬФАSMS (Украина);
  • Немного изменен макет страницы авторизации, в тех случаях, когда она выводит «промежуточные сообщения» (такие как «Подключаемся…» и т.п.). Текст сообщений теперь отцентрирован по вертикали внутри div-а, выводящего эти сообщения;
  • Небольшие обновления во внешнем виде «чёрной админки» Easyhotspot (правка CSS-файлов: внесение изменений, небольшая оптимизация);
  • Исправлена функция показа рекламы после авторизации (а точнее — приведена к тому же принципу, что и выписка гостевых ваучеров — имя «гостевого тарифа» для проверки берется не из файла настроек (conf.txt), а из базы биллинга (выбирается т.н. «гостевой тариф», привязанный к данному NASID);
  • Изменены настройки размещения лог-файлов, генерируемых веб-приложением Easyhotspot. Теперь они располагаются в папке /var/www/easyhotspot/application/logs;
  • В процедуру ротации лог-файлов добавлен файл настроек, обязывающий раз в неделю проводить ротацию логов веб-приложения Easyhotspot (всех логов, найденных в папке /var/www/easyhotspot/application/logs);

Обновления и исправления модулей

  • Переписан модуль СМС-авторизации! Теперь он предлагает два способа авторизации клиентов — либо по паролю, присылаемому в СМС, либо по звонку на номер, указанному хотспотом. Кроме того, функции модуля были разделены между самим биллингом и страницей авторизации. Отдельное веб-приложение теперь не используется, а номер своего телефона клиент теперь вводит непосредственно в меню авторизации хотспота. Подробнее можно прочесть на странице с описанием модуля или в инструкции к нему;
  • В модуль Робокассы внесено изменение — убрана отправка символа валюты (RUB) при проведении платежей в рублях. В соответствии с текущей версией документации п/с Робокасса, платежи итак осуществляются в рублях и отправка информации о валюте — излишняя;
  • Исправлена ошибка в платежном модуле Onpay: при формировании ваучера модуль вписывал пароль с устаревшим аттрибутом User-Password. В современных версиях FreeRDIUS данный аттрибут вызывает ошибку, и клиент не может авторизоваться. Исправлено на рекомендованное Cleartext-Password. Клиенты успешно авторизуются по купленным ваучерам.
  • Пришло уведомление от платежной системы Liqpay о том, что с 01.07.2018 они окончательно отключают автоматическую переадресацию запросов с домена LiqPay.com на LiqPay.ua. Изменение адреса страницы платежной системы было внесено в код модуля;
  • Обновлен (а точнее — переписан заново) модуль обслуживания по СМС, отправляемым на т.н. «короткие номера». Теперь модуль написан на php (был — на perl). Страница Тарифов модуля теперь адаптируется под экраны мобильных устройств. Владельцы мобильных устройств могут, нажав кнопку, автоматически переходить в приложение отправки для СМС, куда уже будут вписаны и требуемый «короткий номер», и текст сообщения! Все подробности можно прочесть на обновленной странице с описанием модуля СМС («короткие номера»), либо в инструкции к нему;

Обновления и изменения скрипта-инсталятора

  • В системе полностью убрано использование perl-модуля Net::Ping::External. Это обусловлено тем, что в новых версиях дистрибутивов данная библиотека будет недоступна. Как показал поиск, причина изъятия указанной библиотеки заключается в том, что у нее были обнаружены уязвимости безопасности, которые разработчик не устраняет (и уже давно, благодаря чему складывается впечатление, что он просто забросил свою программу). Ранее в биллинге Easyhotspot библиотека Net::Ping::External использовалась дважды: во первых, в скрипте страницы авторизации с помощью ping МОГЛА выполняться проверка доступности интернета (по умолчанию была выключена). С другой стороны, скрипт контроля роутеров, обслуживаемых сервером Easyhotspot, выполнял ping роутеров, от которых были получены запросы. Первое «применение» — как мне кажется, фактически не использовал никто. И даже больше — реально это было лишено смысла, т.к., если у хотспота отсутствует доступ к интернету, то переадресация неавторизованнных клиентов на страницу авторизации не работает. В итоге, было принято решение полностью убрать из кода страницы авторизации как использование самой библиотеки Net::Ping::External, так и проверки доступности интернета с помощью ping. Для второй задачи было найдено альтернативное решение. Скрипт контроля роутеров был вписан в сам Easyhotspot (в «черную админку»), функция ping также легла на нее же (с использованием уже языка php), а вместо старого perl-скрипта была написана «заглушка», которая просто переадресовывает запросы на новый адрес проверки;
  • Выход дистрибутива Ubuntu 18.04 LTS послужил поводом для радикального обновления скрипта-инсталятора! С учетом того, что дистрибутив Ubuntu 18.04 LTS выпускается только в 64-битной версии, программу Chillispot устанавливать на него стало бесполезным (Chillispot не работает на 64-битных ОС!). И в итоге получалось так, что Easyhotspot, установленный на Ubuntu 18.04 LTS, мог бы работать только в «варианте 3» (удаленный сервер-RADIUS для управления «внешними» роутерами). Инсталятор был изменен так, что теперь на сервер Easyhotspot, если он используется в качестве шлюза локальной сети хотспота («варианты 1 и 2»), устанавливается не устаревший Chillispot, а его обновленный «форк» — Coova-Chilli! При этом приложение Coova-Chilli компилируется из «исходников» непосредственно на самом сервере, что позволяет устанавливать его как на 32-битных ОС, так и на 64-битных! Благодаря внесенным изменениям (с одной стороны) Easyhotspot на дистрибутив Ubuntu 18.04 LTS теперь можно также устанавливать в любом из вариантов! А с другой стороны — сервер Easyhotspot в «вариантах 1 и 2» теперь может быть установлен на 64-битную версию и иных дистрибутивов;
  • В скрипт-инсталятор добавлена новая функция. В «черной админке» для отображения лога авторизации используются разные команды для разных версий сервера FreeRADIUS, установленного в биллинге. Теперь скрипт-инсталятор прописывает цифру, соответствующую версии FreeRADIUS-а, в файл конфига веб-интерфейса Easyhotspot, и благодаря этому биллинг сам выбирает корректную команду для отображения лога авторизации (раньше команду нужно было выбирать вручную — править вручную файл конфига);

Изменения в документации

Обновлена инструкция «Mikrotik и Easyhotspot». В инструкцию добавлена информация о настройке NASID. Расширена информация по поводу HTTPS-авторизации, добавлены разъяснения.  На основании информации, изложенной в интернете, был написан дополнительный скрипт, который в комплексе с рядом дополнительных мер позволяет заставить продукцию Apple открывать страницу авторизации хотспота не в CNA, а в Safari (т.е., в полноценном браузере).

Обновлена инструкция «Индивидуализация вашего хотспота». В инструкцию добавлены такие разделы:

  • Автоматический показ меню авторизации сразу же
  • Запрет меню авторизации «прятаться»
  • Изменение сложности логина и пароля, генерируемых программой

Просмотреть все эти изменения в действии можно на сайте демо-версии модифицированной программы Easyhotspot (логин/пароль Кассира: vcool/vcool123, логин/пароль Администратора: admin/admin123)

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

Список предыдущих анонсов новостей программы Easyhotspot доступен тут.

Новости программы Easyhotspot — февраль 2018

С момента прошлой публикации в программе произошли следующие изменения:

  • Изменения в веб-интерфейсе Easyhotspot («черной админке»);
  • Обновления и исправления у страницы авторизации
  • Новые модули
  • Обновления иных модулей
  • Обновления и изменения скрипта-инсталятора
  • Написан новый кабинет пользователя
  • Изменения в документации

Читать далее «Новости программы Easyhotspot — февраль 2018»

Простой биллинг с веб интерфейсом — Easyhotspot

Вашему вниманию предлагается готовое интегрированное решение для организации своего собственного хотспота. Причем, «своего собственного» в том смысле, что именно вы будете решать «что, где, когда и почем»! У программы нет ограничений на число обслуживаемых клиентов, роутеров, тарифов и пр.! Не нужно «докупать лицензии на увеличившиеся число клиентов» либо платно «продлевать лицензию на пользование программой на (какой-то период)»!

Один из основных  способов обслуживания клиентов — с помощью продаваемых (или раздаваемых бесплатно) ваучеров.

Вторая функция программы — обслуживание «постоянных» клиентов, для которых биллинг подсчитывает время, проведенное ими в интернете, либо потребленный ими трафик, и затем формирует счета на основании этих данных. Об этом — см. ниже.

Третий способ обслуживания клиентов, предоставляемый программой, это режим «Гостевого доступа», при котором клиент хотспота сможет бесплатно выходить в интернет, просто нажав одну лишь кнопку на странице авторизации.  Никаких паролей для такого «гостевого» обслуживания сообщать клиенту не нужно! Всеми параметрами такого гостевого доступа (длительность, объем трафика, скорость, периодичность , и т.д.) — ВСЕМ ЭТИМ управляете непосредственно вы сами!

Ну и напоследок — программа предоставляет дополнительную разновидность гостевого доступа» — полностью автоматический допуск клиентов в интернет  после просмотра рекламы. Причем, клиент должен будет смотреть именно страницу с рекламой, а не переключившись на другое окно или приложение, ждать пока она закончится. В случае, если клиент переключается со страницы с рекламой на что-то другое, счетчик времени просмотра просто останавливается!

Также, программа позволяет предоставлять доступ в интернет после СМС-авторизации, как того требует российское законодательство! Модуль и записывает номера телефонов клиентов, и привязывает эти номера к mac-адресам оборудования клиентов, ив дальнейшем хранит эту информацию в архиве программы.

Дополнительные удобства в обслуживании клиентов предоставляют интегрируемые в Easyhotspot (приобретаются отдельно) автоматизированные платежные модули по приему оплаты с помощью СМС, оплаты с кредитных карт, оплаты через системы «мобильной коммерции», или же такие платежные системы как QIWI, Onpay, Robokassa, Assist, Яндекс-Касса, «Единый кошелек» , Paypal и пр. Все это позволит вам превратить ваш хотспот в истинный «автомат по продаже интернета»! Вам не нужен будет кассир, продающий ваучеры! Клиент сам подключится к хотспоту, сам произведет оплату в выбранной платежной системе, и в ответ получит от программы логин и пароль, чтобы ввести их на странице авторизации и получить доступ в интернет!!!

Система позволит вам абсолютно свободно управлять тарифами, ценами, лимитами и всеми прочими параметрами доступа в интернет ваших клиентов!

Система позволяет управлять как одним хотспотом, так и целой сетью, причем сеть эта может быть разнесена территориально. В качестве «внешних» хотспотов, обслуживаемых сервером, могут выступать роутеры Mikrotik (без каких-либо модернизаций), либо иные SOHO-роутеры, которые необходимо будет перепрошить прошивками либо DD-WRT, либо OPENWRT.

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

Система включает в себя сервер авторизации и учета RADIUS, страницу авторизации (контроллер доступа Chillispot) и биллинговую программу Easyhotspot. Система устанавливается на компьютер, работающий под управлением Linux, что с одной стороны, избавляет от необходимости покупки самой операционной системы, а с другой стороны повышает надежность и защищенность системы. Построение системы соответствует стандартам, устоявшимся в сфере предоставления услуг доступа в интернет, и было рассмотрено мной в заметке «Хотспот и с чем его едят». Кроме того, данная система может выступать в роли центрального сервера целой сети хотспотов. При этом, в непосредственных точках реализации достаточна установка одних лишь роутеров, настроенных на взаимодействие с центральным сервером. Такое построение позволит вам получить единый биллинг, обслуживающий ваших клиентов в самых различных заведениях (зданиях, зонах и т.п.). Последние нововведения программы позволяют привязывать клиентов к отдельным зонам, ограничивая их обслуживание указанной зоной и отказывая в обслуживании в иных зонах.

Непосредственное управление хотспотом осуществляет именно биллинговая программа. По этому, ниже я постараюсь вкратце изложить возможности и преимущества именно программы Easyhotspot, хотя фактически она – лишь «вершина айсберга» всей системы хотспота. Фактически, Easyhotspot является одним из наиболее простых и интуитивно понятных программных продуктов, предназначенных для управления не только именно беспроводным хотспотом, но и любой системой управления доступом в интернет, рассчитанной на работу с сервером RADIUS. Рассматриваемая тут модифицированная и переведенная на русский язык версия программы Easyhotspot в первую очередь отличается повышенной стабильностью работы, и отсутствием проблем, присущих ее исходному англоязычному оригиналу.

Easyhotspot является веб приложением, написанным на языке PHP. Благодаря этому, управление хотспотом происходит в браузере (любом), запущенном на компьютере под управлением любой ОС. Обеспечив доступ к программе из интернета, вы сможете управлять вашим хотспотом, находясь даже на море! Ввиду своей простоты программа является идеальным решением для организации услуги предоставления доступа в Интернет в публичных местах (Кафе, Гостиницы, Библиотеки, Аэропорты, Вокзалы и т.д.) – т. н. «HotSpot».

Программа Easyhotspot позволяет одновременно обслуживать две категории платных клиентов хотспота. Деление клиентов на категории осуществляется по способу оплаты ими услуги доступа в интернет. К первой группе относятся клиенты, которые сначала пользуются интернетом, а потом оплачивают выставленный вами счет (т.н. postpaid). Вторая группа – это клиенты, которые сначала оплачивают услугу доступа в интернет (покупают талоны-ваучеры), и лишь потом пользуются ей (т.н. prepaid).

Программа Easyhotspot позволяет учитывать как время, проведенное клиентом в интернете (в минутах), так и его трафик (объем данных в мегабайтах). Соответственно, для клиентов, оплачивающих по счету, вы можете назначить, что будет учитываться при оплате – минуты или мегабайты. И результирующий счет, полученный клиентом, будет сформирован простым умножением суммы либо минут, либо мегабайт, умноженных на соответствующий тариф. А для клиентов, покупающих ваучеры, вы можете указать т.н. «номинал» ваучера – число либо минут, либо мегабайт, после израсходования которых, клиент будет автоматически отключен от хотспота.

Программа Easyhotspot предоставляет вам абсолютную свободу в вопросах ценообразования на все предоставляемые вами услуги доступа в интернет – все расценки и тарифы вы назначаете сами! При этом нет никаких ограничений, и вы вольны назначать любые цены в пределах от нуля и до «потери сознания»! Также, в программе тарифы для клиентов с оплатой по счету (postpaid) никоим образом не связаны с ценами на ваучеры (prepaid) – эти два способа обслуживания двух различных категорий клиентов имеют абсолютно независимое ценообразование! Для категории клиентов с оплатой по счету (postpaid) вы назначаете стоимость одной минуты и одного мегабайта, и эти цены действуют только для этой категории клиентов! А для клиентов, покупающих талоны-ваучеры (prepaid), вы назначаете цену ваучера, и эта цена никоим образом не зависит от тарифов за минуту или мегабайт, установленных вами для категории postpaid и рассмотренных в предыдущем предложении!

Теперь рассмотрим, какие лимиты (ограничения) позволяет назначать программа Easyhotspot.

Номинал (ваучера) – это основной лимит ваучера; у клиентов с оплатой по счету такого параметра нет вовсе. Этот параметр определяет тот максимальный объем услуги доступа в интернет, после израсходования которого, клиент будет автоматически отключен от хотспота. Номинал ваучера может быть задан либо в минутах (то есть клиенту гарантируется некая продолжительность времени подключения к интернету), либо в Мегабайтах (клиенту гарантируется некий объем трафика). Этот лимит может быть израсходован клиентом за любое число сеансов – хоть за один, хоть за несколько. Как только выделенный лимит будет клиентом израсходован, хотспот автоматически отключит его от интернета.

Ограничение входящей скорости и Ограничение исходящей скорости – эти два параметра позволяют назначить ту максимальную скорость, с которой клиент хотспота будет соответственно получать данные из интернета и отправлять данные в интернет. Эти ограничения могут быть назначены как для ваучеров, так и для клиентов с оплатой по счету.

Таймаут – это не лимит, но тоже один из параметров, влияющих на подключение клиента к интернету. Этот параметр определяет время (в минутах), по истечении которого хотспот отключит клиента от интернета, если в течение этого времени клиент не проявлял активности (не было передачи/приема данных клиентом в/из интернета). Для ваучера вами может быть назначен произвольный таймаут. Для клиентов с оплатой по счету таймаут жестко прописан в программе и равен 3 минутам.

Срок годности ваучера – этот лимит, как видно из его названия, может быть назначен только для ваучеров. Позволяет «бороться» с «очень экономичными» клиентами – по истечении этого срока хотспот перестает пускать клиента в интернет, даже если тот так и не израсходовал свой лимит, отведенный ему номиналом ваучера. Параметр указывается в минутах/часах/сутках. Важным является то обстоятельство, что отсчет срока годности идет от момента активации ваучера (первого раза, когда клиент ввел в систему выданные ему на ваучере имя и пароль). Для примера, если у ваучера указать срок годности как 1 час, то в итоге мы получаем ваучер, который гарантированно становится недействительным по прошествии 1 часа с момента его активации, вне зависимости от того, сколько времени клиент реально провел в интернете!

ВНИМАНИЕ! При обслуживании клиентов по ваучерам ОЧЕНЬ ВАЖНО четко понимать различие между Номиналом ваучера и Сроком годности ваучера! Номинал (если он ограничивает именно время) ограничивает СУММАРНУЮ длительность ВСЕХ сеансов Клиента. Длительность пауз между сеансами при этом не имеет никакого значения. Например, номинал ваучера равен 60 минутам, а клиент пользуется интернетом ровно 2 минуты в день. В таком случае Номинал ваучера им будет израсходован за 30 дней. С другой стороны, Срок годности ваучера начинает отсчитываться с момента первой активации ваучера Клиентом. И при его подсчете не берется во внимание, пользовался клиент в это время интернетом все время беспрерывно, либо же между его сеансами были паузы. Рассмотрим тот же пример про ваучер, номинал которого равен 60 минутам, и клиента, который ежедневно использует только по 2 минуты. Но при этом мы дополнительно укажем, что Срок годности для этого ваучера равен 3 суткам. Допустим, Клиент активировал ваучер 3 сентября 2012 года в 12:00. В результате лимита, наложенного именно Сроком годности, начиная с 6 сентября 2012 года 12:00 этот Клиент уже больше не сможет авторизоваться и получить доступ в интернет. Если в этот момент Клиент был подключен к интернету, то хотспот отключит его. И, хотя, в данном случае Клиент (с учетом его «экономного» пользования интернетом) израсходовал всего лишь 6 минут из отведенных Номиналом 60-ти, доступ в интернет по данному ваучеру будет более не возможен, так как истек его Срок годности.

Число одновременных логинов – этот лимит указывает, какое количество клиентов может быть подключено к хотспоту с одними и теми же логином и паролем. Для ваучеров это число в программе изначально установлено равным единице (может быть изменено администрацией хотспота). То есть, по одному ваучеру несколько человек одновременно ходить в интернет не смогут никак – только один! Для клиентов с оплатой по счету это число может быть произвольным, и назначается вами. Это сделано на тот случай, если клиенту понадобится подключать в интернет несколько устройств одновременно, например, ноутбук, смартфон и планшет, и т.д.

График обслуживания – этот лимит позволяет вам создавать такие Тарифные пакеты, ваучеры(*) которых будут обслуживаться не «все 24 часа в сутки все семь дней в неделю», а по какому-то особому, составленному вами графику.  В графике указываются: день недели плюс время старта и время окончания периода, когда клиенту позволен доступ в интернет. Вы вольны составить самый «витиеватый» график, комбинируя дни и время старта/стопа, добавляя любое необходимое их количество. В остальное время клиенту будет отказано в авторизации и в доступе в интернет.

Дата окончания обслуживания – этот лимит позволяет вам установить точную дату, когда обслуживание выбранного клиента будет прекращено. Клиент будет отказано в авторизации и в доступе в интернет, если истек срок его обслуживания. При этом клиент получит сообщение о том, что «Обслуживание данного аккаунта прекращено».

ID хотспота – этот лимит позволяет вам «привязать» клиента к определенному хотспоту (точнее, к идентификатору хотспота). Если для клиента не назначен «ID-хотспота» (поле параметра оставлено пустым), то такой клиент будет обслуживаться ЛЮБЫМИ хотспотами, управляемыми посредством данной биллинговой программы. Если же идентификатор указать, то клиент будет проходить авторизацию и получать доступ в интернет только на тех хотспотах, у которых установлен точно такой же ID.

MAC-адрес клиента – этот лимит позволяет вам «привязать» клиента к MAC-алресу его оборудования. Если для клиента не назначен «MAC-адрес» (поле параметра оставлено пустым), то такой клиент сможет авторизоваться с любого устройства с любым MAC-адресом. Если же MAC-адрес указать, то клиент будет проходить авторизацию и получать доступ в интернет только на том устройстве, которое имеет этот MAC-адрес. Привязка к МАС-адресу выполняется «в один клик»! Для ваучеров по умолчанию в программе реализована «авто-привязка» к mac-у устройства в момент активации ваучера (самого первого подключения клиента к интернету). Данная «авто-привязка» может быть отключена администрацией хотспота  при необходимости!

Клиенту с оплатой по счету (postpaid) вы можете ограничить три параметра доступа в интернет:

  • Входящую скорость
  • Исходящую скорость
  • Число одновременных логинов
  • Таймаут
  • Дату окончания обслуживания
  • ID хотспота
  • MAC-адрес

Клиенту, использующему ваучер (prepaid), можно указать следующие параметры:

  • Номинал – фиксированное число минут или мегабайт
  • Входящую скорость
  • Исходящую скорость
  • Срок годности ваучера
  • Таймаут
  • График обслуживания
  • ID хотспота (привязывается не отдельный ваучер, а весь тариф)
  • МАС-адрес («привязывается» уже непосредственно ваучер)

Комбинирование этих параметров и ограничений позволит вам максимально гибко управлять доступом клиентов вашего хотспота в интернет.

С целью минимизации возможностей для злоупотреблений, работа в программе Easyhotspot разделена между несколькими категориями пользователей. Категорий пользователей (или т.н. «ролей») в программе существует три:

  • Суперадминистратор – это пользователь, наделенный максимальными административными правами. Суперадминистратор имеет право назначать тарифы для клиентов с оплатой по счету, создавать и удалять Тарифные пакеты (номиналы ваучеров), проводить инкассацию, удалять завершенные и израсходованные ваучеры, а также создавать и удалять пользователей программы: Кассиров, Администраторов и других Суперадминистраторов.
  • Администратор – это также административный пользователь программы, но в отличие от Суперадминистратора ему не позволено создавать, редактировать и удалять пользователей программы рангом выше Кассира (то есть, Администраторов и Суперадминистраторов он ни создавать, ни удалять, ни редактировать не имеет права, а Кассиров – может). За исключением этого ограничения, Администратор может выполнять все остальные административные действия, перечисленные выше для Суперадминистратора.
  • Кассир – пользователь, непосредственно работающий с клиентом. Он генерирует и продает (или раздает даром) ваучеры на основании уже имеющихся Тарифных пакетов, созданных ранее Администратором (или Суперадминистратором), а также создает аккаунты для клиентов, которые оплачивают доступ в интернет по счету. Также, Кассир закрывает аккаунты и выписывает счета клиентам с оплатой по счету после того, как те закончили пользование услугой. С целью предотвращения возможных злоупотреблений Кассиров, в программе введена специальная настройка про «Доверие Кассиру». Если вы доверяете Кассиру, в его меню присутствуют кнопки для удаления использованных ваучеров и выписанных счетов. Соответственно, Кассир сможет их самостоятельно удалять. Если же параметр «Доверие Кассиру» установлен как «нет», то у кассира нет такой возможности (удаления ваучеров и счетов), что в конечном итоге не позволит ему присвоить себе деньги, полученные от клиента, а проданный клиенту ваучер, или выписанный счет просто удалить из программы.

Но вернемся к способам обслуживания клиентов.

Вариант Postpaid (или «Оплата по счету») предполагает, что клиент является постоянным (на протяжении некоторого периода времени), и за полученные услуги рассчитывается по истечении учетного периода на основании выставленного ему счета. Типичным примером использования данного варианта учета может служить хотспот гостиницы или отеля. В этом случае доступ в интернет предоставляется клиенту в момент его поселения, а расчет за потребленную услугу осуществляется, когда клиент уже выписывается из номера. На протяжении некоторого периода времени система подсчитывает суммарный объем потребленного клиентом времени или трафика. По окончании учетного периода на основании результатов учета и установленных тарифов программа формирует счет для клиента. В данном случае распределение ролей пользователей программы осуществляется следующим образом:

  • Администратор заранее назначает в программе расценки для оплаты по счетам (сколько стоит каждая минута подключения, и сколько стоит каждый Мегабайт переданной информации). Обращаю внимание на то, что эти тарифы не имеют абсолютно никакого отношения к ценообразованию для второго метода (ваучеров).
  • Кассир создает учетную запись пользователя, самостоятельно назначает ему логин, пароль и тип учета. При необходимости устанавливает лимиты скорости и меняет число одновременных логинов. После этого кассир распечатывает клиенту талон, на котором указаны параметры для доступа в интернет (логин и пароль).
  • Дополнительно (при необходимости) Клиенту может быть назначена Дата окончания обслуживания. По наступлении указанной даты доступ в интернет для Клиента прекращается автоматически. Ряд платежных модулей позволяет таким клиентам вносить «помесячную» оплату, в результате чего Дата автоматически смещается еще на месяц вперед.
  • Клиент начинает пользоваться услугой. На протяжении установленного учетного периода программа хотспота подсчитывает объем потребленной клиентом услуги. В зависимости от выбранного типа учета суммируется либо время, проведенное клиентом в интернете, либо объем полученной им информации.
  • По истечении учетного периода кассир формирует счет клиенту. Сумма счета определяется простым умножением цен, указанных Администратором, на объем услуги, потребленный клиентом. Кассир, если параметр про «Доверие кассиру» выключен, во избежание финансовых злоупотреблений, не может просто удалить учетную запись клиента. Также, по тем же причинам Кассир не может удалить и сформированный счет.
  • В момент формирования счета учетная запись клиента (логин и пароль) автоматически удаляется, и клиент более не сможет получить доступ в интернет с этими параметрами.
  • После того, как клиент оплатит счет, Администратор может удалить его из базы данных программы.

Второй способ обслуживания — Prepaid (ваучеры) предназначен для предоставления разовых предоплаченных услуг. Иными словами, клиент сначала приобретает у кассира ваучер (талон) определенного номинала (в котором указаны логин и пароль), и лишь потом получает доступ в интернет. Номинал ваучера (талона) гарантирует клиенту предоставление определенного объема услуги доступа в интернет. Учет потребленной услуги возможен как по времени подключения, так и по объему израсходованного трафика. Иными словами, клиент автоматически будет отключен от хотспота после того, как либо время, которое он был подключен к интернету (в минутах), либо объем переданной и полученной им информации (в Мегабайтах) превысили указанный лимит (номинал ваучера). Ваучер также может иметь ограничения скорости. Кроме того, у ваучера фиксирован лимит одновременных логинов – только один (настраиваемое значение) клиент сможет подключиться в интернет с указанными логином и паролем. Второму клиенту, использовавшему эти же учетные данные, в доступе будет отказано. И напоследок, у ваучера есть срок годности (указывается Администратором). По его истечении клиент не сможет подключиться к хотспоту даже, если он не израсходовал еще все лимиты времени или мегабайт. Отсчет срока годности ведется от момента активации ваучера (первого подключения клиента к интернету через хотспот). Типичным примером использования данного варианта учета может служить хотспот в кафе.

Следует учесть, что ваучеры формируются (создаются) Кассиром на основании уже имеющихся в системе Тарифных пакетов. То есть, все параметры (лимиты) ваучера будут в точности такими, какими они есть у Тарифного пакета, на основании которого этот ваучер и был создан. Тарифные пакеты создает Администратор. И именно Тарифный пакет определяет, что будет подсчитываться – время или трафик, а также назначает тот лимит, по истечении которого клиент будет отключен. Тарифный пакет имеет собственную цену. Цена может быть указана произвольная (хоть и нулевая), и она никак не связана с тарифами, назначенными для оплаты по счетам. Кроме того, для Тарифного пакета при желании могут быть указаны ограничения входящей и исходящей скорости, с которой данные будут передаваться от/к клиенту. И срок годности, упоминавшийся ранее, также является параметром именно Тарифного пакета. При таком методе предоставлении услуги доступа в интернет роли пользователей программы распределены следующим образом:

  • Администратор создает Тарифные пакеты. Их число ничем не ограничено, и определяется лишь вашими потребностями. Например, можно создавать тарифные пакеты на разную длительность работы в интернете. Или, допустим, на одно и то же время доступа, но с различной скоростью. Или «мало и медленно» – задаром, а «много и быстро» – за деньги! В очередной раз напоминаю, что Администратор абсолютно свободен в вопросах ценообразования.
  • На основании имеющихся (созданных Администратором) Тарифных пакетов Кассир генерирует и распечатывает ваучеры, и продает их Клиентам (или же раздает даром, если указана нулевая цена).
  • Клиент начинает пользоваться услугой. В момент первого подключения к хотспоту система начинает отсчет срока годности ваучера. Также, система начинает подсчет объема потребленной клиентом услуги. По истечению лимита, указанного как номинал ваучера, клиент будет отключен от интернета автоматически.
  • Все ваучеры, использование которых клиентами было начато, попадают в отчет для инкассации. То есть, пока ваучеры были просто распечатаны и «тихо и мирно» лежат у кассира, они не попадают в этот отчет. Но как только логин и пароль из ваучера были хоть раз введены в систему для получения доступа в интернет, программа автоматически считает такой ваучер как проданный. Как следствие, такой ваучер попадает в отчет для инкассации. Отчет подсчитывает общее число проданных ваучеров для каждого из Тарифных пакетов и, с учетом их цены, выводит итоговую сумму, подлежащую инкассации (иными словами, выручку Кассира, полученную от продажи ваучеров).
  • После того, как Кассир оплачивает Администратору сумму, подлежащую инкассации за проданные ваучеры, Администратор помечает попавшие в отчет ваучеры, как инкассированные. В дальнейшем, при формировании нового отчета для инкассации, ваучеры, инкассированные ранее, уже не попадут в него.
  • После инкассации Администратор запускает команду, которая удаляет из базы хотспота все инкассированные ваучеры, лимит которых был израсходован, либо истек их срок годности.

Более подробно работа в программе Easyhotspot рассмотрена либо на этой странице, либо в данном полном руководстве.

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

Увидеть получившийся результат (в том смысле, что в онлайн попробовать поработать в «демонстрационной» версии модифицированной программы Easyhotspot) можно, если перейти по этой ссылке. Чтобы войти в программу как Администратор, Вам потребуется ввести логин admin и пароль admin123. Чтобы поработать в роли Кассира, нужно будет ввести логин vcool, и пароль vcool123.

Желающие сравнить, чем же все-таки модернизированный Easyhotspot отличается от «оригинального», могут легко сделать это самостоятельно! Достаточно просто сравнить старую версию программы с ее обновленным собратом. Чтобы войти в любую из версий программы как Администратору, Вам потребуется ввести логин admin и пароль admin123. Чтобы поработать в роли Кассира, нужно вводить логин vcool, и пароль vcool123.

Существует также вариант модернизированной программы Easyhotspot с английским языком интерфейса. Его демо версия доступна по адресу: http://wifi-hotspot.zp.ua/hotspot_demo_eng/ . Данные для входа — те же самые, что и для «русской» версии (приведены в предыдущем абзаце).

Полную подробную инструкцию по работе с модернизированной программой Easyhotspot можно прочесть или скачать по данной ссылке.

Мной составлено подробное руководство по установке и настройке хотспота с использованием программ и служб Easyhotspot, FreeRADIUS, MySQL, Apache, установленных на компьютере, работающем под управлением актуальных версий ОС Linux Ubuntu LTS (12.04, 14.04, 16.04, 18.04), а также актуальных версий ОС Debian (7.Х, 8.Х или 9.Х). Содержание руководства можно просмотреть по данной ссылке. Данное руководство плюс модифицированная и русифицированная версия программы предлагаются к продаже по цене $90.

Программа поставляется в виде скрипта-инсталлятора, который самостоятельно полностью устанавливает и настраивает весь хотспот – контроллер доступа Chillispot, сервер авторизации RADIUS, а также все остальные необходимые для работы программы: сервер баз данных MySQL, веб сервер Apache, ну и собственно саму программу Easyhotspot. В результате вы получаете стабильно работающий (по нескольку месяцев без выключения) хотспот, у которого отсутствуют какие-либо ограничения. В двух словах, создание сервера хотспота состоит из двух этапов — установки самой ОС UBUNTU (или Debian), и последующего выполнения скрипта-инсталятора, который сам установит все компоненты сервера хотспота!!! Подробнее как пользоваться скриптом исталлятором описано в руководстве по быстрой установке, которое можно скачать по этой ссылке. Как видно из данного руководства, никаких «особых» познаний в Linux-е от устанавливающего не требуется! Дополнительно на Youtube выложены 2 видео-ролика. Первый ролик показывает процесс установки самой ОС Ubuntu 12.04 LTS. Второй ролик показывает процесс установки всего комплекса программ хотспота с помощью скрипта инсталятора.

Остальные видеоматериалы, доступные в интернете:

  • Процедура обновления программы Easyhotspot:

  • Авторизация Клиента по логину и паролю:

  • Гостевая авторизация кнопкой «Бесплатно» (Клиент не пользуется логинами и паролями):

  • Задержка на время показа рекламы при включении соответствующего режима:

  • Автоматическая авторизация Клиента после просмотра рекламы:

  • Режим, при котором Клиент смотрит рекламу до авторизации, а потом смотрит еще одну после авторизации (только «гости»):

Дополнительные детали – по почте. Альтернативные контакты – на странице «Обо мне».

Кроме того, за отдельную плату, предоставляется услуга по дистанционной установке и настройке сервера хотспота на ваш подготовленный компьютер. Детали о том, что нужно подготовить – в этом руководстве. Стоимость услуги – $10.

Отзывы о работе системы от тех, кто уже использует в работе описанное выше ПО, можно прочесть на этой странице.

У вас все еще остались вопросы, на которые вы так и не нашли ответа? Загляните на страницу FAQ, просмотрите еще целый ряд «вопросов и ответов«, почитайте форум, посвященный модифицированной версии программы Easyhotspot. И этого недостаточно? Напишите мне письмо с вашими вопросами, или просто задайте ваш вопрос в поле «Оставь комментарий» внизу страницы…

Программу можно приобрести либо связавшись со мной по е-мейл, либо же онлайн, если перейти по ссылке:

https://wifi-hotspot.zp.ua/file_sale/

Дополнительные ссылки:

Танцы с перцем!.. Ой, простите, с бубном!..

Один из первых вопросов, который зачастую задают после того, как Chillispot установлен, настроен и работает, звучит так:

— У меня есть необходимость нескольким клиентам присвоить статические ip-адреса. Как это сделать?

Увы, Chillispot сам по себе плохо относится к клиентам со статическими адресами, если они прописаны вручную. То есть, клиент видит, что у него адрес тот, который он написал, видит, что он подключен к тому шлюзу, которым является Chillispot, но вот все его попытки попасть на любую страницу в интернете дают сообщение о том, что сервер не найден. И это действительно так — клиент при этом не авторизован, и доступа в интернет у него нет. А вот страница авторизации клиенту, назначившему себе статический IP саостоятельно, увы, не выдается. И причина здесь в самом Chillispot и его внутренних алгоритмах работы. Ему нужны DHCP-запросы о клентов, ему нужны DNS-запросы от клиентов, без них, увы никак…  Подводя краткий итог — таким методом заставить «подружиться» клиента со статическим IP-адресом и Chillispot не получится.

И что, совсем никак?

Возможность есть. Ее таки предусмотрели сами авторы программы, по всей видимости понимая, что необходимость в статических IP-адресах все-таки периодически возникает. Нюанс лишь в реализации. И если понять механизм процесса, то настроить его потом уже не составит труда…

Итак, постулат №1 — у клиента в настройках протокола TCP-IP все-равно должно быть выставлено все в автомате, то есть — «Получить IP-адрес автоматически» и «Получить адрес DNS-сервера автоматически», даже в том случае, если он хочет работать со статическим IP-адресом.

Постулат №2 — Chillispot не присваивает статические адреса! В том смысле, что «сам не присваивает» — за него это делает сервер RADIUS. Для этого в Chillispot реализована поддержка радиусовского атрибута Framed-IP-Address.

Постулат №3 — RADIUS сам по себе в Chillispot ничего не скажет, пока не получит запрос авторизации. А на этапе подключения клиента к Chillispot от клиента еще не поступало никаких данных, требующихся для этого. И что же тогда Chillispot отправляет в RADIUS как имя клиента? Единственное, что Chillispot успел узнать от клиента  на этапе его подключения, а именно — его MAC-адрес.

Вот мы и добрались до финта (а может быть костыля?…) Chillispot. В конечном итоге, для клиента, который (впоследствии) будет работать со статическим IP-адресом процедура выглядит так:

  1. Клиент подключается к Chillispot.
  2. Chillispot определяет MAC-адрес сетевой платы клиента и вместе с паролем отсылает его на проверку серверу RADIUS.
  3. Если у сервера RADIUS в базе есть запись про клиента с таким MAC-адресом и с таким паролем, то авторизация клиента подтвеждается и Chillispot получает утвердительный ответ — Access:Accept.
  4. И кроме того, если в базе сервера RADIUS для этого клиента (с данным MAC-адресом) прописано конкретное значение IP-адреса (атрибут Framed-IP-Address), то тогда это значение также отсылается RADIUS-ом в утвердительном ответе контроллеру Chillispot.
  5. Chillispot, получив от RADIUS конкретное значение IP-адреса, присваивает его клиенту и выпускает его в интернет. Все, на этом авторизация клиента завершена, никаких окон с логинами/паролями ему не предлагается — в этом уже нет нужды.

Вот так все просто?

— Да.

А причем тут костыли?

— Нюансов два. Во первых в качестве имени клиента используется МАС-адрес его сетевой платы, который легко может быть подделан. А во вторых,  пароль, используемый при авторизации по МАС-адресу — он задается в настройках Chillispot, и он — один-единственный для всех, кто будет авторизоваться по МАС-у… Ну а про костыли я сказал, так как предполагаю, что этот финт (авторизация по МАС-у доделывался авторами уже потом, как решение проблемы когда и DHCP нужен, и адрес хочется иметь статический..

Ну да ладно. Наша задача теперь настроить Chillispot и RADIUS для того, чтобы задействовать эту возможность. Начнем с Chillispot. Собственно, все его настройки расположены в одном единственном файле — /etc/chilli.conf. Этот файл и нужно открыть в редакторе. Естественно, или залогинившись перед этим как root, или же через sudo (чтобы потом прав хватило для сохранения изменений). В этом файле (с учетом того, что, как было сказано в самом начале, Chillispot уже настроен и работает в составе хотспота) нас сейчас интересуют только те параметры, которые относятся именно к реализации использования статических IP адресов. Если же у вас есть нужда настроить Chillispot «с нуля», то тогда, добро пожаловать — читайте мою другую заметку о настройке этой службы. Но вернемся к нашим параметрам.

Во первых, при реализации возможности предоставления статических адресов, сеть, формируемую службой Chillispot (по умолчанию, 192.168.182.0/24) разделить на две части — одну для клиентов со статическими адресами, а вторую для тех, кому адрес будет выдаваться динамически. делается это с помощью двуп параметов — statip и dynip. При этом нужно не забывать о том самом значении параметра net, который задает всю сеть, создаваемую контроллером Chillispot для обслуживания клиентов.

statip —  определяет пул статических адресов, предоставляемых клиентам.

dynip —  определяет пул динамических адресов, предоставляемых клиентам.

Учтите, что эти оба поддиапазона обязательно должны во первых не перекрываться, а во вторых, умещаться в диапазон адресов сети, обслуживаемой Chillispot. Для случая использования сети 192.168.182.0/24 (значение, используемое для параметра net в настройках Chillispot по умолчанию), корректно получается поделить ее только лишь пополам. Точнее, для статической «половины» можно конечно указать и меньший диапазон допустимых адресов, но это все равно не позволит добавить свободных адресов «половине» динамической, увы. Таким образом, настройки сети и подсетей должны выглядеть следующим образом:

net 192.168.182.0/24

statip 192.168.182.0/25

dynip 192.168.182.128/25

При этом весь диапазон поделен ровно на две половины. Первая из них (в диапазоне от 192.168.182.2 и до 192.168.182.126) предоставляется для клиентов со статическими адресами, а вторая (от 192.168.182.128 до 192.168.182.254) — для тех, кому достанется динамический адрес. Если динамических адресов вам мало, то тогда можно попробовать следующий вариант настроек дележа сети:

net 192.168.182.0/23

statip 192.168.182.0/25

dynip 192.168.183.0/24

В таком случае для динамических адресов будет предоставлен пул в диапазоне от 192.168.183.1 до 192.168.183.254, а для статических, как и в первом варианте — с 192.168.182.2 по 192.168.182.126.

Далее. Необходимо включить авторизацию по МАС-адресам. Для этого в файле настроек нужно найти и раскомментировать (удалить # в начале строки) следующий параметр:

macauth — при включении этого параметра Chillispot при подключении к хотспоту каждого нового клиента первым делом будет пытаться авторизовать его на основании его МАС-адреса. То есть, допустим, у сетевой платы клиента МАС-адрес равен 00-11-22-33-44-55. При подключении этой сетевой платы серверу RADIUS будет отправляться запрос на авторизацию клиента, User-name которого будет составлен из значения параметра macsuffix (см. ниже) и MAC-адреса сетевой платы (в данном примере — 00-11-22-33-44-55). В качестве пароля при авторизации будет использовано значение параметра macpasswd (см. ниже). Не стоит бояться, что использование данного параметра помешает «нормальной» работе хотспота — клиентам, не прошедшим МАС-авторизацию, будет предложена «обычная» авторизация с помощью UAM (вебстраницы с возможностью ввода логина и пароля).

macsuffix — суффикс, добавляемый к реальному МАС-адресу сетевого адаптера. Именно итоговое полученное значение отсылается при авторизации в сервере RADIUS в качестве имени клиента. Параметр позволяет несколько повысить безопасность системы, добавляя некую с позволениря сказать «интригу» к имени. Если планируется использование, параметр нужно раскомментировать и указать свое собственное значение. Используйте буквы только латинского алфавита — для RADIUS-а русские буквы — пустой звук. Суффикс добавляется в конец МАС-адреса. Например, если вы указали суффикс «test», а МАС-адрес сетевой платы был как и в предыдущем примере 00-11-22-33-44-55, то серверу RADIUS будет послан запрос на авторизацию клиента с User-name «00-11-22-33-44-55test». Если вы суффикс использовать не желаете, то оставьте параметр закомментированным, и тогда на авторизацию RADIUS-у в качестве имени клиента будет отсылаться только сам МАС-адрес.

macpasswd — пароль, который служба Chillispot отсылает серверу RADIUS при попытке МАС-авторизации. Пароль, как говорится, «один на всех» — одинаков для любого пытающегося авторизоваться поМАС-адресу клиента. По умолчанию значение параметра весьма тривиально — «password». Не поленитесь, и придумайте свой собственный пароль! Чтобы использовать, параметр нужно раскомментировать и указать свое собственное значение. Используйте буквы только латинского алфавита — для RADIUS-а русские буквы — пустой звук.

Все. Как только вы настроили все вышеперечисленные параметры, ваш Chillispot готов к МАС-авторизации клиентов. Но это еще не значит, что к этому же готов и RADIUS…

Чтобы наш процесс завершился успехом, от сервера RADIUS требуется по сути выполнить всего лишь два  требования. Во первых, у него в базе должен быть прописан клиент с именем равным МАС-адресу того компьютера, которому мы хотим присвоить фиксированный IP-адрес. В случае, если у Chillispot включено еще и использование macsuffix, то имя клиента в базе должно быть «МАС-адрес + значение параметра macsuffix». Данному клиенту (в его учетной записи RADIUS-а) должен быть указан пароль, который был настроен как значение параметра macpasswd в настройках Chillispot.  А во вторых, для данного клиента в его учетной записи в сервере RADIUS должно быть также указано значение параметра (атрибут) Framed-IP-Address.

Рассмотрим на живом примере. Итак, у нас есть Chillispot, к которому мы будем подключать компьютер. У Chillispot пул статических адресов задан значением параметра statip, равным 192.168.182.0/25 (то есть, адреса от 192.168.182.2 и до 192.168.182.126). Сетевая плата компьютера имеет МАС-адрес равный 00-11-22-33-44-55. Мы хотим, чтобы после авторизации компьютер всегда получал адрес 192.168.182.5 (естественно, что выбраный нами адрес должен попадать в диапазон доступных статических адресов, приведенный ранее). У Chillispot включено использование суффикса (параметр macsuffix раскомментирован, и ему задано значение test), а для МАС-авторизации задан следующий пароль — super-puper-pass (указан как значение параметра macpasswd). Самый простой способ задать пользователя — вписать его в файл users, настроек RADIUS-а. Если все, что мы хотим задать для данного пользователя, это только взможность получить фиксированый адрес (ну и, естественно, выйти в интернет), то в файл users нужно добавитьвсегьо лишь две строки:

00-11-22-33-44-55test      Cleartext-Password := "super-puper-pass"
       Framed-IP-Address = 192.168.182.5

Как видите, в первой строке мы указали, что у нас будет клиент (пользователь) с логином 00-11-22-33-44-55test (то есть, как и было сказано выше — суммой МАС-адреса и суффикса) и паролем super-puper-pass. А во второй строке мы задаем для данного пользователя параметр (атрибут) Framed-IP-Address, равный тому самому IP-адресу (192.168.182.5), который мы хотим присваивать этому пользователю при каждом его подключении.

Если же вы учетные записи клиентов вашего хотспота храните в базе данных (например, MySQL), то создания указанного клиента нужно внести записи в две таблицы. Первую — в таблицу radcheck

id	username	attribute	op	value
1	00-11-22-33-44-55test	User-Password	:=	super-puper-pass

Эта первая запись указывает, что у нас в системе будет пользователь 00-11-22-33-44-55test с паролем super-puper-pass. А вторую запись нужно добавить в таблицу radreply

id	username	attribute	op	value
1	00-11-22-33-44-55test	Framed-IP-Address	:=	192.168.182.5

Это как раз запись, указывающая, какой IP-адрес (192.168.182.5) присвоить этому клиенту при авторизации.

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

Sun Jul 11 11:01:49 2010 : Auth: Login OK: [00-11-22-33-44-55test/super-puper-pass] (from client wifi-hotspot port 1 cli 00-11-22-33-44-55)

Причинами неудачи авторизации данного клиента могут быть лишь несответствие реальных данных введенным параметрам, а также, ошибки типа «опечатки» при вводе параметров, в результате которых параметры вписанные в настройки RADIUS-а и Chillispot различаются.

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

Дополнительные ссылки:
Заметка о настройке контроллера доступа Chillispot на компьютере под управлением ОС Linux

Все мо заметки о хотспотах

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

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

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

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

Рис. 1 — Компьютер в роли контроллера хотспота

С другой стороны, существуют и специализированные аппаратные решения, например, сервисный Hot spot шлюз DSA-3110 hotspot edition от 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.

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

Рис. 2 — Схема взаимодействия модулей хотспота

Рассмотрим процесс взаимодействия всей системы. Клиент подключается к хотспоту и пытается попасть на какой-то сайт в интернете. 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 можно ознакомится по данной ссылке.

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

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

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

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

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

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

Удаление «зависших» сессий из таблицы radacct (в б/д MySQL) сервера RADIUS

Ковыряясь с хотспотом, столкнулся с тем, что иногда в таблице radacct остаются строки, в которых отсутствует время окончания сессии (acctstoptime). То есть, речь идет не о записях текущих сеансов, в которых время окончания естественно отсутствует — по той причине, что сеанс еще не закончен. Речь о записях предыдущих сеансов. В биллинге Easyhotspot, который я использую, наличие таких строк мешает нормальной работе функции принудительного отключения.

Проблема была решена следующим способом:

  1. Был создан набор команд (скрипт) MySQL, удаляющий такие строки.
  2. Был настроен запуск данного скрипта.

Теперь подробнее.

Сам скрипт я создал в папке пользователя root, назвал его clear.sql, и содержимое его выглядит следующим образом:

USE easyhotspot;
DELETE FROM `radacct` WHERE `acctstoptime` IS NULL;

Ничего конгениального в скрипте нет. Первая команда скрипта выбирает базу в сервере MySQL. В используемом мной биллинге Easyhotspot база, с которой работает RADIUS, называется именно easyhotspot. В случае же другого названия базы, нужно всего лишь в первой строке скрипта изменить имя базы, выделенное синим цветом. Вторая команда удаляет из указанной в ней таблицы (radacct), строки, удовлетворяющие условию, а именно те, в которых поле acctstoptime —  пустое (шаблон — ‘ ‘).

Теперь пару слов про запуск. Собственно, чтобы запустить выполнение команд из указанного скрипта, нужно в консоли запустить следующую команду:

mysql -uroot -pпароль_рута < /root/clear.sql

В данной команде, на мой взгляд, все предельно просто и ясно — входим в консоль сервера MySQL и запускаем выполнение скрипта. В приведенной команде нужно лишь указать свой собственный пароль пользователя root для сервера MySQL (выделен синим цветом).

И про автоматизацию запуска. Данную команду имеет смысл выполнять в тот момент, когда у RADIUS-а нет подключенных пользователей.  Первый приходящий на ум вариант — при запуске компьютера. То есть, команду нужно добавить в файл rc.local. Но ведь компьютер может и сутками не выключаться (а как следствие — и не включаться). Тогда можно задействовать другой вариант — добавить ее в расписание (cron). При этом нужно указать время, в которое наименьшая вероятность наличия подключенных пользователей.

Ну и еще про один «вредный» файлик. RADIUS в своей работе создает файл ${logdir}/radutmp в котором хранит информацию о текущих сессиях.  Файл этот «мешать» начинает лишь при выполнении ряда условий. А именно; клиенту разрешен лишь один логин на его пару «имя/пароль», клиент был подключен (авторизован), и в этот момент сервер с RADIUS-ом аварийно выключился. В таком случае RADIUS не удаляет из файла radutmp информацию о сессии клиента, и в итоге клиент после того, как работа системы возобновилась, при попытке авторизоваться получает сообщение, что он уже вошел в систему.

Лечение простое — при  загрузке компьютера просто стереть файл  radutmp. Для этого в файл rc.local достаточно добавить команду:

rm -f /var/log/radius/radutmp

В данном случае команда приведена с учетом расположения файла в дистрибутиве Mandriva. Для других дистрибутивов оно может быть иным. Например, в дистрибутиве Ubuntu файл располагается по адресу /var/log/freeradius/radutmp. При необходимости, откорректируйте путь (выделен синим цветом) в соответствии с расположением файла radutmp в вашем дистрибутиве.

Ну и напоследок, для самых ленивых. Я написал скрипт, который в интерактивном режиме (вопрос-ответ) проделывает установку и настройку всего этого на компьютере. Скрипт запрашивает и пароль root для MySQL и имя базы для RADIUS и время, в которое, если что, запускать чистку базы…

Chillispot — ещё тот «перец»!..

К одной из моих заметок прислали комментарий — «Да это же очевидно!«. Абсолютно согласен! В блоге своем я пишу что-либо только после того, как уже разобрался с этим, и для меня то, что я написал тут тоже стало уже «очевидным». Но, до этого — зачастую приходится основательно перелопатить интернет, форумы, блоги и т.п. Вот возьмем, к примеру, тот же Chillispot 🙂 …

Начнем с простейшего — во многих интернет-источниках адрес сайта Chillispot указан как http://www.chillispot.org/. Но на сегодняшний день (и как пишут, это длится еще с середины 2007 года) сайт этот не существует, а информация, загрузки, FAQ, форум и пр. теперь находятся по новому адресу — http://www.chillispot.info/. Но к этому мы вернемся позже, а пока…

Вступление

Собственно, что это такое и зачем оно надо. Chillispot — это контроллер доступа. Его задача в максимально общей формулировке — пускать пользователей из одного сегмента сети в другой. То есть, если уже «приземленно», то с одной стороны (во внутренней подсети) находятся клиенты, а с другой стороны — бескрайние просторы интернета. И Chillispot с одной стороны на основании информации от сервера авторизации либо пускает этих клиентов в сеть либо нет. А с другой стороны, Chillispot осуществляет взаимодействие с сервером учета Radius, благодаря чему поставщик услуг (провайдер) знает сколько клиент провел времени в интернете, а также какой объем информации клиент принял и отдал в интернет. И, если совсем уж без намеков — Chillispot чаще всего используется тогда, когда кто-то хочет создать хотспот, работающий под управлением ОС Linux, и управляемый каким-нибудь биллингом, взаимодействующим с Chillispot посредством Radius-а.

При этом непосредственно Chillispot выполняет три задачи:

  1. Формирует LAN-подсеть для клиентов хотспота. Для этого он сам выступает в роли DHCP-сервера, раздавая клиентским компьютерам IP-адреса.
  2. Взаимодействуя с сервером RADIUS работает контроллером доступа, не пропуская в интернет неавторизованных клиентов, и предоставляя доступ с указанными (RADIUS-ом) параметрами — авторизованным.
  3. Предоставляет клиентам страницу авторизации (специальную веб-страницу) на которой они могут ввести логин и пароль, чтобы попасть в интернет.

Существует целый класс аппаратных устройств, у которых есть и своё собственное название — NAS (Network Access Server — сервер доступа в сеть). Chillispot можно считать «программным» NAS. Кстати, аббревиатуру запоминайте — она нам еще встретится при настройке…

1. Подготовка

Что нам нужно.

  • Две сетевые платы — одна из «смотрит» в интернет, вторая — во внутреннюю подсеть. Примем как исходное условие, что плата, «смотрящая» в интернет (WAN), в нашем Linux имеет обозначение eth0, а та, которая обращена во внутреннюю подсеть (LAN) — eth1. Номера эти тоже запомним — это также потребуется в процессе настройке.
  • Для сетевой платы, посредством которой компьютер подключен в интернет (WAN/eth0) ДОЛЖНО БЫТЬ НАСТРОЕНО ВСЁ! То есть, настройки его адреса, шлюза, маски подсети и пр. либо же работающий DHCP-клиент, одним словом, этот компьютер должен «нормально ходить в интернет». Для сетевой платы, к которой подключаются пользователи (LAN/eth1), в Linux НИЧЕГО НАСТРАИВАТЬ НЕ НУЖНО. Linux должен ее только лишь определить и «подставить» соответствующий драйвер. Chillispot сам «поднимет» на указанном интерфейсе все необходимое для подключения пользователей — DHCP-сервер и т.д и т.п.
  • В системе должен присутствовать модуль TUN-драйвера. Как утверждают, модуль этот присутствует в ядре Linux уже достаточно давно (не помню, начиная с какой версии), но по умолчанию он не загружается автоматически при старте системы.  По-этому, его предлагают включать в список модулей автоматически загружаемых при запуске системы (файл /etc/modules). Но, просмотрев скрипт запуска Chillispot, я увидел, что при его выполнении обязятельно запускается и модуль TUN-драйвера. По этому никаких дополнительных действий предпринимать я не стал. Как проверить, есть ли драйвер в системе? В консоли от имени root-а запускаем комманду (выделена синим)  и видим ответ (выделен оранжевым цветом):
[root@my-svr etc]# modprobe -l -a tun 

/lib/modules/2.6.24.7-desktop-2mnb/kernel/drivers/net/tun.ko.gz
  • Настроенный RADIUS-сервер. Именно он хранит записи о клиентах, имеющих доступ в интернет, а также результаты подсчета их времени и трафика. Собственно, у меня к этому времени уже был установлен и настроен FreeRADIUS.
  • Работающий веб-сервер с поддержкой SSL. Тут с меня советчик плохой — лично я себе по-быстренькому поставил apache-ssl, а чтобы он не мешал основному apache, запретил ему в конфиге «слушать» порт 80. На что стоит обратить внимание при таком, по сути, «варварском» подходе — файл конфигурации «секурного» сервера (это отдельный сервер, а не mod_ssl к обычному apache)  свой собственный и находятся в отдельной папке — /etc/httpsd/conf/httpsd.conf. Также отдельно расположена и папка html-документов этого сервера (/var/lib/httpsd/html), и папка cgi-скриптов (/var/lib/httpsd/cgi-bin). Думаю, правильнее будет все-таки воспользоваться одной из многочисленных инструкций, имеющихся в интернете, и настроить «обычный» apache с использованием mod_ssl. Но, при любом из подходов нужно будет, во-первых, запомнить папку в которой должны размещаться cgi-скрипты (потребуется при настройке), а во-вторых, «обзавестись» ssl-сертификатами для Вашего сервера. «По умолчанию», при установке apache с mod_ssl папка, куда нужно будет положить cgi-скрипт «безопасной» авторизации  это /var/www/cgi-bin (для случая моей установки на Mandriva), а ssl-сертификаты генерируются «автоматом» на этапе установки указанных пакетов. Лично я сертификаты для себя сгенерировал самостоятельно, воспользовавшись следующей командой, найденой мной где-то на просторах интернета (будьте внимательны, это одна строка):

openssl req -new -newkey rsa:4096 -nodes -keyout /etc/ssl/ca/ca.key -x509 -days 3650 -subj /C=UA/ST=Ukraine/L=Zaporozhye/O=EI/OU=IT/CN=my.server.adres/emailAddress=my@adres.com -out /etc/ssl/ca/ca.crt

Естественно, персональные данные (выделенные красным) в команду Вы подставляете свои собственные. Особое внимание нужно обратить на имя сервера, которое Вы впишите в команду — оно должно быть в точности таким же, как ответ Вашего компьютера на команду «hostname -f«. Также обратите внимание на ту часть команды — «/etc/ssl/ca/«,  которая обозначает путь, куда будут записаны сформированные сертификат и ключ (в команде присутствует дважды!!!).  Дополнительно почитать про сертификаты можно еще по следующим адресам:

  1. http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#ownca
  2. http://www.opennet.ru/base/dev/apache_mod_ssl.txt.html
  3. http://forum.oszone.net/thread-68700.html

После генерации сертификатов прописываете их использование в файл конфигурации сервера apache-ssl (ну или apache с mod_ssl). Это конечно не избавит в дальнейшем от сообщений браузеров об неизвестном центре сертификации, т.к. сертификаты «самоподписанные», но те, кого это не устраивает, могут приобрести настоящие сертификаты. Существует еще одна возможность, на тот случай, если у Вас есть возможность разместить свой скрипт на безопасном сервере, доступном с того компьютера, на котором планируется разместить Chillispot, Об этом — ниже…

2. Установка

Чем (для меня) хорош дистрибутив Mandriva? Обилием программ в «родных» репозиториях! Запустите «Центр управления», выберите «Установку и удаление программ», введите в поле поиска желаемое, и с определенной долей уверенности можно утверждать, что «оно там найдется»… Так же было и с Chillispot — он оказался в списке доступных пакетов, я всего-лишь поставил «птичку» и нажал кнопку «Применить»…

(Ничто не вечно под луной… Пока я собирался описать установку Chillispot, вышел новый дистрибутив Mandriva — версии 2009.1, в пакетах которого Chillispot, увы, уже  не оказалось. Но, на проверку, преспокойно устанавливается и работает пакет от дистрибутива версии 2009.0).

На всякий случай, я сохранил пакет у себя на FTP в соответствующей папке.

3.  Конфигурирование

Вся конфигурация Chillispot описывается одним единственным файлом — /etc/chilli.conf. Каждый параметр в нем прокомментрирован, единственное «неудобство» — «как всегда», на английском. Кроме того, можно в консоли запустить команду

"chilli --help"

, которая выведет подсказку с параметрами. Следует учесть (и это сказано в man к chilli, но как-то не явно), что все те параметры, которые выводит подсказка , могут быть прописаны в файл конфигурации /etc/chilli.conf, единственное — писать их нужно без двойного дефиса («—«).  Перейдем непосредственно к файлу конфигурации. Во-первых, обратите внимание на несколько фраз из комментариев к параметрам.

  • Фраза «For most instalation you need to modify this tag» обозначает, что данный параметр скорее всего Вам придется изменить с учетом потребностей и параметров Вашей инсталяции.
  • Фраза «Normally you do not need to uncomment this tag» обозначает, что если Вы не хотите «наконфигурировать» что-то совсем нетрадиционное и экстравагантное, не надо раскомментировать строку с данным параметром. Это не означает, что параметр не будет установлен. Будет использовано его значение «по-умолчанию», которое обычно устраивает почти все 100% пользователей.
  • Фраза «Do not uncomment this tag unless you are an experienced user» рекомендует не раскомментировать данный параметр, если Вы не являетесь опытным пользователем. (Практически, как старые таблички «Не влезай, убъет!»).

Теперь о самих параметрах. Все их я описывать не буду, опишу лишь те, которые необходимо было изменить. (Параметры выделены жирным, их значения — красным).

radiusserver1 127.0.0.1 — адрес (1-го) сервера RADIUS, у которого Chillispot запрашивает данные при авторизации клиентов.  То есть, чтобы Chillispot пропустил в интернет пользователя с «такими-то» логином и паролем, этот пользователь именно с этими логином и паролем должен быть записан в базе пользователей данного RADIUS-сервера. В моем случае указан адрес 127.0.0.1, так как мой RADIUS-сервер расположен (установлен) на том же самом компьютере, что и Chillispot. В качестве параметра можно указывать как ip-адрес, так и имя (например server.radius.net) сервера.

radiusserver2 127.0.0.1 — адрес (2-го) сервера RADIUS. Как пишут в комментарии к данному параметру, если Вы используете только один RADIUS-сервер, то в данном параметре укажите то же самое значение, что и для radiusserver1. Нигде явно  это не сказано, но рискну предположить, что данный параметр указывает на RADIUS-сервер аккаунтинга (того, который считает потребленные пользователем время и трафик). И в случае такой вот (раздельной) инсталяции, когда один RADIUS-сервер используется для авторизации, а второй для подсчета, данный параметр должен указывать на сервер учета. Но у меня нет возможности проверить правильность данного предположения… В моем случае указан адрес 127.0.0.1, так как у меня используется один RADIUS-сервер. В качестве параметра можно указывать как ip-адрес, так и имя (например server.radius.net) сервера.

radiussecret testing123 — пароль, который Chillispot использует при обмене с RADIUS-сервером. Данный пароль позволяет Вам быть уверенным в том, что никто другой не влезет в Ваш RADIUS-сервер (естественно, если Вы изменили пароль на свой собственный, а не оставили тот, что указан тут и который является паролем по умолчанию используемым на всех инсталяциях «с  нуля»). Что следует учесть при смене пароля. Как и любой пароль, его «должны знать двое». То есть, если Вы меняете этот пароль на свой собственный тут (в настройках Chillispot), то его нужно сменить и в настройках RADIUS-сервера! У RADIUS-сервера настройка данного параметра (в простейшем случае) находится в файле «/etc/raddb/clients.conf«. Комментариями там все это «разбавлено прилично», но если их выкинуть, то выглядеть все это будет так:

client localhost {
	ipaddr = 127.0.0.1
	secret		= testing123
	require_message_authenticator = no
	nastype     = other	# localhost isn't usually a NAS...
}

Как видим, присутствующий в списке параметр «secret» имеет то же самое значение — «testing123». Таким образом, меняя пароль в настройках Chillispot, необходимо изменить его и в настройках RADIUS-сервера в файле /etc/raddb/clients.conf. Если же Ваш RADIUS-сервер хранит настройки клиентов в SQL-базе, то менять нужно там. Как это сделать — решаете самостоятельно.

Возвращаемся к настройкам Chillispot.

dhcpif eth1 — номер (идентификатор) сетевой платы,  к которой подключены пользователи («сторона LAN»). Ее номер мы указывали в самом начале в условиях, помните? Для данной платы в Linux НИЧЕГО НАСТРАИВАТЬ НЕ НУЖНО. Linux должен ее только лишь определить и «подставить» соответствующий драйвер. Chillispot сам «поднимет» на указанном интерфейсе все необходимое для подключения пользователей — DHCP-сервер и пр. Что еще важно учесть — между Chillispot и пользователями (в случае необходимости) должно устанавливаться только т.н. «dumb»-оборудование — простые коммутаторы (switch), хабы (hub)  или точки доступа (AP). Использовать функции  NAT, masquarade, route, firewall  между Chillispot (выходом eth1) и пользователями нельзя.

#net 192.168.182.0/24 — данный параметр, как видите, в моих настройках остался закоментированным. Но он имеет непосредственное отношение к только что описанному параметру dhcpif. Параметр этот задает маску подсети LAN. То есть, сам Chillispot как шлюз будет виден под адресом 192.168.182.1, а пользователям при их подключении будут предоставляться адреса в диапазоне от 192.168.182.2 до 192.168.182.254. Параметр этот рекомендуют как раз не менять без особой нужды. Но, если «вдруг что», то Вы можете изменить номер самой подсети (например, 192.168.1.0). При этом важно, чтобы номер внутренней подсети не совпадал с внешней (если, допустим, Ваш компьютер подключен к ADSL-маршрутизатору). С другой стороны, может случиться так, что 250-и возможных пользователей Вам окажется мало. На этот случай, в FAQ, размещенном на сайте Chillispot, предлагают сменить маску подсети (указать значение параметра как net 192.168.182.0/20, ну и, естественно, раскомментировать его).

uamserver https://192.168.182.1/cgi-bin/hotspotlogin.cgi — страница авторизации (UAM — Universal Authorisation Metod).  Данный параметр указывает на  расположение страницы, которая позволяет пользователям вводить логин и пароль для доступа в интернет. Причем, на расположение ее в (скажем так) «внешней» адресации (URl), а не в виде «/var/www/cgi-bin/hotspotlogin.cgi».  Именно ради возможности размещения и обслуживания этой страницы нам и был нужен «защищенный» веб-сервер.  Страница авторизации НЕ ОБЯЗАТЕЛЬНО должна находиться на том же самом сервере, где установлен Chillispot. Помните, с самом начале я говорил, что можно использовать «чужой» веб-сервер. В таком случае, его адрес (включая и месторасположение самой страницы авторизации) нужно будет указать ИМЕННО В ЭТОМ параметре.  При этом, кроме того, потребуется разрешить доступ к указанному адресу без авторизации (см. ниже). Как видите, при авторизации пользователь перенаправляется на страницу, обмен с которой происходит с использованием SSL-шифрования (адрес начинается как https://). Данная страница (а точнее скрипт, написанный на языке perl) поставляется в пакете с Chillispot и после его установки находится в папке /usr/share/doc/chillispot/.  Данный скрипт нужно скопировать в папку, в которой Ваш веб-сервер хранит И ОБРАБАТЫВАЕТ исполняемые CGI-скрипты. Для случая использования apache с mod_ssl это папка /var/www/cgi-bin. А в «моем» случае использования отдельного сервера apache-ssl — папка /var/lib/httpsd/cgi-bin.  После того, как файл скопирован, его нужно сделать исполняемым (команда chmod +x hotspotlogin.cgi) а также назначить владельцем этого файла того пользователя, от имени которого запущен веб-сервер (в моем случае — chown apassl:apassl hotspotlogin.cgi, в Вашем — посмотрите в файлах конфигурации apache).  После этого данный файл ПОЧТИ готов к использованию, но об этом ниже.

#uamhomepage http://192.168.182.1/welcome.html — страница приветствия. Как видите, в моем случае этот параметр не используется. Что это за страница такая? Краткое описание работы Chillispot (возможно с него стоило начать?!..):

Когда неавторизованный (еще) пользователь из внутренней сети (LAN) пытается получить доступ к интернету (WAN), Chillispot перехватывает его запрос и пользователь перенаправляется на страницу авторизации по адресу, как указано в параметре uamserver (см. выше).  В «выпрыгнувшем» окошке пользователю предлагается ввести логин и пароль. Полученные значения логина и пароля Chillispot отправляет на проверку серверу RADIUS. Если они верны (RADIUS-сервер отвечает утвердительно), то Chillispot предоставляет пользователю полный доступ в интернет. Пользователь перенаправляется на запрошенный им адрес.  Вот так вкратце работает Chillispot.

С другой стороны, есть возможность перенаправить такого пользователя сначала не на страницу ввода логина и пароля, а на т.н. «страницу приветствия». На этой ОБЫЧНОЙ веб-странице Вы можете разместить любую информацию, которую посчитаете нужной (рекламу, правила пользования, еще что-то)… Вот адрес именно такой «страницы приветствия» и нужно указать как значение параметра uamhomepage. Ну и, естественно, раскомментировать строку с этим параметром. Что еще нужно учесть при этом? Первое — если эта страница находится на другом сервере (а такое тоже допускается), доступ к ней должен быть разрешен без авторизации (см. ниже). Далее — на этой странице обязательно должна присутствовать ссылка, вызывающая то самое всплывающее окошко ввода логина и пароля. Адресс такой — http://192.168.182.1:3990/prelogin (правильнее — адрес вида http://chilli.login.server:3990/prelogin, где абстрактное chilli.login.server обозначает адрес сервера, на котором расположена страница авторизации (нужно подставить РЕАЛЬНОЕ значение)). И последнее — в случае использования страницы приветствия автоматической переадрессации пользователя после успешной авторизации по запрошенному им адресу НЕ ПРОИСХОДИТ. Таким образом, если параметр uamhomepage задан (адрес страницы указан, и строка раскомментирована), то пользователь при авторизации будет переходить на страницу приветствия. Если же нет, то сразу на страницу ввода логина и пароля.

uamsecret ht2eb8ej6s4et3rg1ulp — пароль, который Chillispot использует в своем обмене данными со страницей авторизаци (hotspotlogin.cgi). По умолчанию эта строка закоментирована. Пусть этот факт не вводит Вас в заблуждение — это не значит, что пароль не используется! Это значит, что используется его значение по умолчанию! Почему я так заостряю на этом Ваше внимание? Помните, я написал ранее, что файл hotspotlogin.cgi почти готов к использованию? Дело в том, что в нем использование этого самого пароля по умолчанию ОТКЛЮЧЕНО! Таким образом, чтобы получить РАБОТАЮЩУЮ страницу авторизации, ее (т.е. файл hotspotlogin.cgi) нужно открыть в любом нравящемся Вам текстовом редакторе, найти (практически в самом начале) строки:

#$uamsecret = "ht2eb8ej6s4et3rg1ulp";
#$userpassword=1;

и раскомментировать их! Первая из строк задает тот самый пароль (который нужно указать, желательно все-таки свой собственный а не «умолчательный», и, естественно, одинаковый, для обоих конфигурационных файлов — chill.conf и hotspotlogin.cgi). Вторая строка включает использование этого пароля скриптом hotspotlogin.cgi. Если Вы забудете это сделать, то окно авторизации будет все время выдавать ошибку…

#uamallowed www.chillispot.org,10.11.12.0/24 — адреса (страницы, имена, подсети), доступ к которым разрешен пользователю без авторизации. Если адресов много (как в примере), то они разделяются запятыми. Как видите, параметр по умолчанию закоментирован. В данном случае он не используется. Если же Вам необходимо предоставить пользователям доступ к каким-либо внешним страницам без/до/для (!!!) авторизации, то их нужно указать тут и раскомментировать строку. Это может потребоваться, например, в случаях использования внешних («чужих») страниц авторизации и/или приветствия,  описанных выше.

#dns1 172.16.0.5

и

#dns2 172.16.0.6 — адреса первого и второго серверов DNS. Эт о адреса серверов DNS, которые Chillispot по dhcp выдает клиентским компьютерам. По умолчанию эти строки закоментированы. Это не значит, что клиентские компьютеры не получат адресов DNS. Это значит, что не используются принудительное их указание в файле настроек  Chillispot-а. В таком случае (когда эти параметры закомментированы) адреса DNS-серверов используются из настроек сетевой платы WAN-интерфейса (eth0) самого компьютера с Linux на котором установлен и запущен Chillispot. При желании Вы можете использовать собственные значения — их нужно указать, а строки раскомментировать.

Последние два параметра я добавил в файл chill.conf сам. На этой странице для того, чтобы иметь возможность оключать пользователя согласно сецификации RADIUS, рекомендуется запускать Chillispot с параметрами –coaport 3799 и –coanoipcheck. Но, как сказано в man к chilli эти параметры можно указать и в файле конфигурации chill.conf. Что я и сделал:

coaport 3799
coanoipcheck

4. Еще чуть-чуть и запускаем…

До полной работоспособности Chillispot осталось сделать самую малость. Но важную «малость». Во первых, нужно включить опцию ip forvarding в настройках системы. Для этого в текстовом редакторе  открываем файл /etc/sysctl.conf и добавляем в него следующую строку:

net.ipv4.ip_forward = 1

Чтобы форвардинг заработал сразу (без перезагрузки всей системы), перезапускаем поддержку сети командой:

/etc/init.d/network restart

Во-вторых, с Chillispot поставляется скрипт правил файервола, который необходимо запускать при загрузке системы. Сразу после установки файл этот находится в папке /usr/share/doc/chillispot/ и называется firewall.iptables. Открываем его в редакторе и смотрим на значения, присвоенные двум переменным (в самом начале файла) — EXTIF=»eth0« и INTIF=»eth1«. В качестве значения переменной «EXTIF» (внешний интерфейс) должна быть указана сетевая плата, «смотрящая» в интернет. А в качестве «INTIF» (внутренний интерфейс) — плата, к которой подключаются пользователи (точка доступа). В самом начале данной заметки, в исходных условиях мы приняли, что к интернету у нас подключен интерфейс eth0, а к точке доступа — eth1. Таким образом, значения указанных параметров нас устраивают целиком и полностью. Если же подключение выполнено наоборот, то нужно соответствующим образом изменить и значения этих двух параметров, указанные в файле firewall.iptables. Разобравшись с настройками и сохранив изменения (если таковые были), выходим из текстового редактора и копируем файл правил в папку, где расположены все скрипты, выполняющиеся при запуске системы:

cp /usr/share/doc/chillispot/firewall.iptables /etc/init.d/firewall.iptables

Затем файл /etc/init.d/firewall.iptables делаем исполняемым:

chmod +x /etc/init.d/firewall.iptables

И после этого просто запускаем его:

/etc/init.d/firewall.iptables

Что еще по поводу файервола? В правилах, поставляемых с Chillispot не учтена необходимость открытия порта, используемого для того, чтобы иметь возможность оключать пользователя согласно сецификации RADIUS. На уже упоминавшейся странице можно посмотреть или даже прямо скопировать содержимое файла firewall.iptables с уже открытым для этой цели 3799-м портом. Это может оказаться актуальным, в том случае, если Ваша билинговая программа может отключать пользователей посредством команд RADIUS-сервера.

Дальше. Серверу RADIUS для «правильного восприятия» Chillispot нужно добавить поддежку некоторых атрибутов, специфичных для chilli. Сам файл атрибутов поставляется вместе с FreeRADIUS (в моем случае — версия 2.0). Файл атрибутов называется dictionary.chillispot и находится в папке /usr/share/freeradius/. Нужно лишь включить его поддержку в основном файле настроек «словарей». Для этого открываем в текстовом редакторе файл /etc/raddb/dictionary и добавляем в него следующую строку:

$INCLUDE /usr/share/freeradius/dictionary.chillispot 

(Кстати, может перед тем, как слепо следовать моим советам, стоит проверить, а есть ли там такой файл?)… Сохраняем мзменения, выходим из редактора, и чтобы RADIUS-сервер «подхватил» новые настройки, перезапускаем его:

/etc/init.d/radiusd restart 

5. И вот теперь запускаем!

Не знаю почему, но Mandriva при установке Chillispot не запускает его «в работу» сразу же после установки, как делает это со многими другими сервисами (например, с тем-же веб-сервером apache).  Более того, хотя скрипт запуска и присутствует в папке /etc/init.d/, по умолчанию он не запускается во время загрузки. То же самое и с нашим скриптом правил файервола. По этому, их нужно указать как сервисы (службы), стартующие «автоматом». Сделать это можно, например, в Mandriva Control Center (Центр управления Mandriva) — закладка «Система», пункт «Включение и отключение системных сервисов», поставить птичку в поле «При запуске». Лично я предпочел для этого воспользоваться своим любимым Webmin-ом…

Ну чтож, время пришло, запускаем Chillispot:

/etc/init.d/chillispot start 

Ну вот и все. Надеюсь, ничего не забыл …

Также, про настройку Chillispot можно прочитать по следующим ссылкам:

  1. https://help.ubuntu.com/community/WifiDocs/ChillispotHotspot/7.10
  2. http://www.opennet.ru/base/net/wireless_hotspot_howto.txt.html
  3. http://www.chillispot.info/chilliforum/viewtopic.php?id=18

ВНИМАНИЕ! Предлагается вариант приобретения биллинговой программы Easyhotspot (русифицированный и модернизированный вариант) и подробного руководства по установке хотспота. Подробности здесь.

Предлагаем WiFi-хотспот под ключ!

Логотип wifi С каждым днем растет число  мобильных устройств, оборудованных адаптерами беспроводной связи Wi-Fi. Однако радиус действия Wi-Fi адаптеров относительно невелик. Как следствие, владельцы подобных мобильных устройств, находясь вне дома или офиса, нуждаются в услугах особых зон интернет инфраструктуры, предлагающих клиентам доступ в Интернет по беспроводным каналам связи. Такие зоны, называемые WiFi-хот-спотами, стали как грибы после дождя появляться в общественных местах.

Вводя у себя новую услугу (WiFi-хот-спот), с одной стороны, Вы однозначно повышаете популярность Вашего заведения среди клиентов, И не только мобильных. Не исключено, что именно наличие хотспота в Вашем кафе или ресторане сделает его самым популярным в округе! С другой стороны, в работе системы используется полноценный вэб-сайт. На нём Вы сможете разместить все, что только душа пожелает — от рекламы собственного заведения до предлагаемого меню. В итоге посетитель сможет ознакомиться с Вашим меню (или иными предлагаемыми услугами), просто подключившись к Вашему WiFi-хот-споту. Ну и напоследок, а почему бы просто не зарабатывать деньги? Тем более, что, как утверждают опытные люди, при удачном месторасположении хотспот может давать вполне достойный доход.

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

Управление системой двухуровневое и определяется биллинговой программой Easyhotspot. Администратор задает номиналы ваучеров и назначает их цену. Кассир на основании номиналов генерирует ваучеры и продает их. После чего администратор просто «снимает кассу» (которую для него подсчитал компьютер). Более подробно работа в программе как в роли администратора, так и в роли кассира, описана в данном Руководстве.

Более того, как гласит народная пословица: «Лучше один раз увидеть, чем сто раз успышать!» Именно для этого на нашем сайте размещена демонстрационная копия программы управления хотспотом. Чтобы попробовать поработать в ней, просто щелкните по данной ссылке. Если Вы хотите поработать в программе в качестве администратора, Вам потребуется ввести логин admin и пароль admin123. Если же есть желание побыть в шкуре кассира, то логин нужно ввести vcool, а пароль при этом используется vcool123.

Осталось лишь сказать о цене. Так как речь идет о целом програмно-аппаратном комплексе, то конечная цена будет зависить от его комплектации. Минимальная цена составляет 1000 грн. и возможна в том случае, когда у заказчика все оборудование и коммуникации уже есть, а от исполнителя требуется только установить и настроить программное обеспечение. Если же требуемое оборудование у заказчика отсутствует, то возможна его поставка исполнителем по ценам, приведенным в этом документе. Кроме того, в случае поставки оборудования исполнителем, на цену работ по установке и настройке программ предоставляется дополнительная скидка в 20%. Стоимость возможно потребующейся при установке кабельной продукции, а также работ по ее прокладке и монтажу определяется персонально для каждой инсталяции.

Вас заинтересовало данное предложение? Возникли вопросы? Нужно больше информации? Напишите нам!

Если же вы хотите установить и настроить свой хотспот самостоятельно, возможно вас заинтересует биллинговая программа Easyhotspot (русифицированный и модернизированный вариант) и подробное руководство по установке хотспота. Подробности здесь.

RADIUS, MySQL и парочка “веб-морд” ко всему этому …

Приспичило на днях мне RADIUS установить. На вопрос о том, «Зачем?», отвечу — именно с этого я начал, когда захотел создать себе хотспот. Но пока что рассмотрим вопрос «Как я это делал, и с какими трудностями при установке боролся»…

1. Ставим FreeRADIUS.

Итак, начнем с «вводных». На «сервере» моем установлена Mandriva (на данном этапе — версии 2008.1), репозитории её давным-давно настроены, а RADIUS мне приспичило настроить именно с использованием базы данных MySQL. Кстати, Apache, PHP5 и MySQL у меня тоже уже давным-давно были и установлены и настроены. Чтож, начинаем ставить RADIUS. Ставить будем не из исходников, которые при желании можно скачать с сайта FreeRADIUS, а из репозитория. Запускаем консоль от имени администратора (root) и вводим следующую команду:

urpmi freeradius freeradius-mysql libfreeradius1

Дожидаемся окончания успешной установки. Этим самым мы устанавливаем три пакета: сам сервер FreeRADIUS, модуль поддержки MySQL для FreeRADIUS, а также «базовый» набор библиотек. Просматривая список пакетов, которые можно установить из официальных репозиториев Mandriva, в имени которых присутствует слово «RADIUS», я выбрал еще парочку кандидатов для установки. Все в той же консоли от имени root вводим следующую команду:

urpmi freeradius-web libfreeradius-devel

Что это было такое? Пакет «libfreeradius-devel» — это набор дополнительных библиотек для разработчиков. Не уверен, что мне он так уж сильно будет нужен, но как говорится возьмем «на всякий случай». А вот «freeradius-web» — это уже один из тех двух веб-интерфейсов для управления RADIUS-сервером, установку которых я и планирую описать тут. На самом деле программа называется Dialup Admin, при желании, почитать о ней можно тут, а скачать (если кому-то не нравится ставить из репозитория) — тут.

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

2. Ставим daloRADIUS.

Вопросов собственно, возникает два:

  1. Почему, не доделав одно, мы перескакиваем на другое?
  2. И что это вообще такое и зачем оно нам нужно?

Отвечу сначала на второй вопрос. daloRADIUS — это второй веб-интерфейс для управления все тем же RADIUS-сервером. Зачем второй, если один уже есть? Честно говоря, поначалу у меня Dialup Admin попросту не запустился, и я быстренько «нагуглил» другой. А потом, когда запустил их оба, то решил тут описать все это сразу. А уж кому что больше нравится — решайте сами. Кстати, daloRADIUS по сравнению с Dialup Admin — более новый и более функционально насыщенный. Ну и справедливости ради должен отметить — в конечном итоге, установив и попробовав оба эти веб-интерфейса, я не нашел их достаточно удобными инструментами для управления хотспотом. Но об этом ниже в «Выводах»…

А теперь о том, зачем нам понадобилось устанавливать daloRADIUS до того, как завершено конфигурирование «связки» FreeRADIUS и MySQL. Дело в том, что установка FreeRADIUS с модулем поддержки MySQL еще не означает автоматического создания требуемой базы данных. Как я и говорил, это только «глыба», над которой нам еще предстоит поработать ручками! Но возвращаясь к базе — после установки 5 пакетов, описанных в первой части, у нас на компьютере только того и появляется, что всего-лишь … скрипт для создания в MySQL той самой требующейся для работы FreeRADIUS базы данных. В принципе, ничто не мешает сразу же взять этот скрипт и создать необходимую базу. И так и стоит поступить, только если Вы не планируете … установить daloRADIUS. Дело в том, что с ним также поставляется скрипт создания базы данных MySQL для FreeRADIUS. Но, в отличие от скрипта, поставляемого с самим FreeRADIUS-сервером, скрипт, идущий в комплекте с daloRADIUS, создает более объемную базу, добавляя в нее кроме базовых еще дополнительные таблицы и поля, требующиеся для его собственной работы. А с другой стороны, если изначально создать базу при помощи скрипта «от FreeRADIUS», то впоследствии, при выполнении скрипта «от daloRADIUS», первую базу придется снести. Так зачем дважды делать одно и то же? Уговорил?

Так как в репозиториях Mandriva данной программы нет, идем на сайт daloRADIUS или же на страницу проекта на SourceForge.net. В любом случае — качаем архив с программой. Собственно, сама установка сводится к нескольким простым действиям:

  • Распаковать содержимое архива.

Переходим в ту папку, куда сохранили скачанный архив с программой и выполняем команду:

tar -zxvf имя_архива.tar.gz

  • Полученный результат нужно скопировать в папку веб-сервера Apache.

Примечания по копированию. Во первых, результатом распаковки реального архива будет папка с именем наподобие такого — daloradius-0.9-8. Лично я для удобства папку эту сразу же переименовал в просто daloradius. А во вторых, папка, в которой находятся документы веб-сервера Apache в моем случае (так настроено), называется /var/www/html, и именно это и показано в приведенной ниже команде. А теперь вернемся к тому факту, что мы только что (командой приведенной выше) распаковали архив с программой. Находясь там же, выполняем следующую команду:

cp daloradius/ /var/www/html -R

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

В моем случае, это пользователь apache из группы apache. Чтобы сменить владельца, выполняем команду:

chown apache:apache /var/www/html/daloradius -R

  • Ну и напоследок, нужно изменить права доступа на файл конфигурации daloRADIUS.

Для этого выполняем команду:

chmod 644 /var/www/html/daloradius/library/daloradius.conf.php

На этом предварительную установку daloRADIUS можно считать законченой.

3. Подготавливаем MySQL (создаем базы).

Ну вот и добрались мы до «высечения» нашей «статуи»!.. Собственно, до настройки взаимодействия FreeRADIUS с базой данных MySQL нужно эту самую базу создать. Как я писал уже выше, на данном этапе у нас есть только скрипты для ее создания. И из двух возможных «претендентов» лично я выбрал скрипт, поставлявшийся в комплекте с daloRADIUS. Вот его и будем сейчас «юзать». В приведенном ниже примере я использую имя базы «radius_db«, имя пользователя для данной базы — «radius_user» и пароль «radius_passwd» для доступа данного пользователя к данной базе. Вам же я рекомендую выбрать свои значения и подставлять их в соответствующие команды. Предполагается, что мы по-прежнему находимся в консоли от имени root-а. Запускаем команду:

mysql -uroot -p

Если попросит, вводим пароль root-а для MySQL. (Если же не попросит, то совет на будущее — установить этот самый пароль в целях повышения безопасности). После успешного ввода пароля мы попадаем в консоль MySQL. На всякий случай напомню, что все команды в ней должны заканчиваться точкой с запятой (;). Создаем базу даных:

CREATE DATABASE radius_db;

Переходим в только что созданную базу данных:

use radius_db;

Запускаем тот самый скрипт, который и создаст в этой базе данных всё необходимое:

source /var/www/html/daloradius/contrib/db/fr2-mysql-daloradius-and-freeradius.sql;

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

После того, как база создана (мы получили ответ наподобие «Query OK, ХХХ rows affected…»), создаем пользователя и назначаем ему права на данную базу данных:

GRANT ALL PRIVILEGES ON radius_db.* TO 'radius_user'@'localhost' IDENTIFIED BY 'radius_passwd';

В данном случае следует обратить внимание на слово «localhost», означающее, что и база данных MySQL и сервер FreeRADIUS установлены на одном компьютере. В противном случае имя компьютера в приведенной команде нужно будет изменить.

Теперь наша база готова, но … только для случая использования веб-интерфейса daloRADIUS. Если же планируется использовать Dialup Admin, то нам необходимо добавить в базу еще несколько таблиц. Необходимое примечание — после установки пакета freeradius-web файлы программы Dialup Admin на моем «сервере» расположились в папке /var/www/freeradius-web, а документация к ней — в папке /usr/share/doc/freeradius-web/sql. В папке с документацией, в подпапке /sql/mysql находятся четыре скрипта для создания недостающих для работы Dialup Admin дополнительных таблиц. Если Вы еще не вышли из консоли MySQL, то просто вводим приведенные ниже четыре команды. Если же вышли, то сначала возвращаемся в консоль MySQL командой «mysql -uroot -p» и выбираем базу командой «use radius_db;«. А уже потом создаем 4 новые таблицы — «badusers»

source /usr/share/doc/freeradius-web/sql/mysql/badusers.sql;

«userinfo»:

source /usr/share/doc/freeradius-web/sql/mysql/userinfo.sql;

«mtotacct:»

source /usr/share/doc/freeradius-web/sql/mysql/mtotacct.sql;

«totacct»:

source /usr/share/doc/freeradius-web/sql/mysql/totacct.sql;

После того, как успешно созданы и эти 4 таблицы, можно выйти из консоли MySQL командой «exit«. Но, в моем случае попытка создания данных 4 таблиц привела лишь к сообщениям об ошибках. «Удачным» примером может служить скрипт для создания таблицы badusers (badusers.sql). При попытке его запуска MySQL выдал два сообщения об ошибках — «ERROR 1067 (42000): Invalid default value for ‘id’» и «ERROR 1072 (42000): Key column ‘Date’ doesn’t exist in table«. Пришлось редактировать вручную.

Вот так скрипт выглядел изначально:

#
# Table structure for table 'badusers'
#
CREATE TABLE badusers (
  id int(10) DEFAULT '0' NOT NULL auto_increment,
  UserName varchar(30),
  IncidentDate	datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
  Reason varchar(200),
  Admin varchar(30) DEFAULT '-',
  PRIMARY KEY (id),
  KEY UserName (UserName),
  KEY Date (Date)
);

А вот так — после правки:

#
# Table structure for table 'badusers'
#
CREATE TABLE badusers (
  id int(10) DEFAULT NULL NOT NULL auto_increment,
  UserName varchar(30),
  IncidentDate	datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
  Reason varchar(200),
  Admin varchar(30) DEFAULT '-',
  PRIMARY KEY (id),
  KEY UserName (UserName),
  KEY IncidentDate (IncidentDate)
);

Для наглядности различия выделены красным. Как мы видим, для исправления первой ошибки (1067) я просто заменил числовой ноль (0) на значение «NULL». После этого сообщение о неверном «умолчательном» значении дл колонки «id» ушло. Второе сообщение об ошибке (1072) говорит нам, что мы пытаемся сделать ключевым невуществующий в таблице (!!!) столбец «Date». И это действительно так! Взглянувши на структуру таблицы, мы видим, что там из дат есть только столбец «IncidentDate». Вот именно его я и сделал ключевым…  Подобная правка может потребоваться и для трех остальных скриптов. После правки повторно запускаем создание 4 дополнительных таблиц. Получив ответ вида «Query OK, ХХХ rows affected…» на все четыре команды по созданию доп. таблиц, выходим из консоли MySQL командой «exit«.

4. Настраиваем FreeRADIUS на использование базы MySQL.

В самом начале мы установили FreeRADIUS. Помните? И все это время он тихонько работал! Не верите? Введите команду:

ps -e|grep radiusd

Нюанс в том, что пока что наш FreeRADIUS не использует базу MySQL. Чтож, будем «принуждать». Для этого необходимо выполнить несколько действий. Во первых, нужно отредактировать файл /etc/raddb/sql.conf. В нем нужно найти указанные строки (они не будут идти подряд, как в примере ниже) и присвоить им следующие значения:

	database = "mysql"
	server = "localhost"
	login = "radius_user"
	password = "radius_passwd"
	radius_db = "radius_db"
	usergroup_table = "radusergroup"
	readclients = yes

Это были параметры, используемые FreeRADIUS при подключении к базе MySQL. Важно, чтобы имя базы, пользователя и пароль, вписанные нами в файл /etc/raddb/sql.conf, совпадали с теми, которые мы ранее использовали при создании базы в MySQL. Следующим шагом мы редактируем файл /etc/raddb/radiusd.conf. В нем нам нужно найти и раскомментировать (убрать символ #) строку:

	$INCLUDE sql.conf

Этим самым мы «глобально» разрешаем FreeRADIUS использовать в своей работе sql-базу данных (параметры которой мы только что описали в файле /etc/raddb/sql.conf). И напоследок нужно отредактировать файл /etc/raddb/sites-available/default. Файл сам по себе не маленький, но придется постараться. В нем нужно найти секцию authorize{} и в ней раскомментировать строку, содержащую директиву «sql». Это позволяет FreeRADIUS искать записи о пользователях в sql-базе данных при их авторизации. Также, нужно найти секцию accounting{} и в ней также раскомментировать строку «sql». Это вынуждвет FreeRADIUS свои записи о подсчете трафика также хранить в sql-базе данных.

Все. Настройка взаимодействия FreeRADIUS с базой данных MySQL завершена. Чтобы внесенные нами изменения вступили в силу, сервер FreeRADIUS нужно перезапустить. Мы же все еще в консоли с правами root-а? Тогда просто вводим команду:

/etc/init.d/radiusd restart

Если все хорошо, то сначала мы прочтем «ОК» по поводу остановки сервера freeradius, а потом — «ОК» по поводу его запуска. С этого момента «связка» FreeRADIUS с базой данных MySQL работает, и нам пора это проверить…

5. Проверка «связки» FreeRADIUS + MySQL

Чтобы убедиться, что наш сервер работает и «общается» с базой данных, выполним следующее. Сначала войдем в консоль MySQL:

mysql -uroot -p

Выберем базу данных :

use radius_db;

Вставим в нее новую запись (в таблицу «radcheck» про пользователя «sqltest» и его пароль «testpwd»):

INSERT INTO radcheck (UserName, Attribute, Value) VALUES ('sqltest', 'Password', 'testpwd');

(По сути, мы только что «по быстрому» завели в нашем RADIUS-сервере тестового пользователя). На всякий случай проверим, что запись таки была добавлена:

select * from radcheck where UserName='sqltest';

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

+----+----------+-----------+----+---------+
| id | username | attribute | op | value   |
+----+----------+-----------+----+---------+
|  1 | sqltest  | Password  | == | testpwd |
+----+----------+-----------+----+---------+
1 row in set (0.00 sec)

Если все хорошо, выходим из консоли MySQL:

exit

А теперь пошлем запрос нашему RADIUS-серверу:

radtest sqltest testpwd localhost 1812 testing123

В данном случае служебная программа radtest (предназначенная для проверки сервера RADIUS) посылает запрос на порт 1812 локального (localhost) RADIUS-сервера с просьбой подтвердить авторизацию пользователя с именем “sqltest” и паролем “testpwd“. Ответ сервера выглядит примерно так:

Sending Access-Request of id 136 to 127.0.0.1 port 1812
        User-Name = "sqltest"
        User-Password = "testpwd"
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=136, length=20

И нам в нем важна выделенная красным цветом строка “Access-Accept”, которая подтверждает, что клиент “sqltest” принят сервером RADIUS, а значит наша “связка” FreeRADIUS + MySQL работает нормально! Следовательно, пора прикручивать веб-интерфейсы…

6. Настраиваем Dialup Admin

Настройка программы проста и сводится к редактированию всего лишь одного файла конфигурации — /etc/freeradius-web/admin.conf. В нем нужно найти указанные строки (они не обязательно будут идти подряд, как в примере ниже) и присвоить им следующие значения:

sql_type: mysql
sql_server: localhost
sql_port: 3306
sql_username: radius_user
sql_password: radius_passwd
sql_database: radius_db
sql_usergroup_table: radusergroup
sql_debug: false

Важно, чтобы имя базы, имя пользователя и пароль, вписанные нами в файл /etc/freeradius-web/admin.conf, совпадали с теми, которые мы ранее использовали при создании базы в MySQL. Все. Даже перезапускать ничего не нужно. Просто запускаем браузер (любой) и набираем в поле адреса:

http://localhost/freeradius-web/

  • Подразумевается, что браузер запущен на том самом компьютере, где установлен Dialup Admin. Если Вы пытаетесь войти в программу с другого — укажите в браузере имя или ip-адрес компьютера, на котором установлен Dialup Admin.
  • Программа сразу же открывает интерфейс для управления сервером RADIUS, не спрашивая никакого имени и пароля. То есть, никакой собственной защиты она не использует. Поэтому доступ к странице программы настоятельно рекомендуется защитить, например с помощью файла .htaccess, настроив его по собственному разумению.

7. Настраиваем daloRADIUS.

Подразумевается, что Вы уже установили программу и настроили ее владельца и права доступа, как описано выше в пункте 2 «Ставим daloRADIUS». Для настройки программы необходимо отредактировать всего лишь один файл конфигурации — /var/www/html/daloradius/library/daloradius.conf.php. В нем нужно найти указанные строки (они не обязательно будут идти подряд, как в примере ниже) и присвоить им следующие значения:

$configValues['CONFIG_DB_ENGINE'] = 'mysql';
$configValues['CONFIG_DB_HOST'] = 'localhost';
$configValues['CONFIG_DB_USER'] = 'radius_user';
$configValues['CONFIG_DB_PASS'] = 'radius_passwd';
$configValues['CONFIG_DB_NAME'] = 'radius_db';
$configValues['CONFIG_DB_TBL_RADUSERGROUP'] = 'radusergroup';
$configValues['CONFIG_PATH_DALO_VARIABLE_DATA'] = '/var/www/html/daloradius/var';
$configValues['CONFIG_LANG'] = 'ru';

Важно, чтобы имя базы, имя пользователя и пароль, вписанные нами в файл /var/www/html/daloradius/library/daloradius.conf.php, совпадали с теми, которые мы ранее использовали при создании базы в MySQL. Программа готова к запуску. Просто запускаем браузер (любой) и набираем в поле адреса:

http://localhost/daloradius/

  • Подразумевается, что браузер запущен на том самом компьютере, где установлен daloRADIUS. Если Вы пытаетесь войти в программу с другого — укажите в браузере имя или ip-адрес компьютера, на котором установлен daloRADIUS.
  • Программа при запуске открывает окно входа (login) в котором нужно ввести имя пользователя и пароль. При первом запуске (то есть, Вы ничего не меняли еще) вводим пользователя «administrator» и пароль «radius«. В дальнейшем настоятельно рекомендуется сменить хотя-бы пароль, а то будет как с левым Windows — пользователей миллионы, а пароль один. Более того, я бы порекомендовал дополнительно защитить доступ к странице программы с помощью файла .htaccess, настроив его по собственному разумению.

Ну вот и все… Ах, ну да —

Выводы

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

В итоге — предлагаю всем желающим приобрести русифицированный и модернизированный вариант программы Easyhotspot плюс подробнейшее руководство по установке хотспота. Подробности здесь.

Почитать еще:

  1. http://daloradius.wiki.sourceforge.net/
  2. http://wiki.freeradius.org/ и в том числе http://wiki.freeradius.org/SQL_HOWTO
  3. http://www.howtoforge.com/authentication-authorization-and-accounting-with-freeradius-and-mysql-backend-and-webbased-management-with-daloradius

Почитать все мои заметки о хотспотах:

  1. https://wifi-hotspot.zp.ua/wp/category/xotspot/