No Image

Что такое radius сервер

СОДЕРЖАНИЕ
0 просмотров
22 января 2020

Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service и представляет собой сетевой протокол, обеспечивающий централизованную Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций (Authentication, Authorization, Accounting)используется аббревиатура ААА.

Под Аутентификацией понимается процесс, позволяющий идентифицировать пользователя по его данным, например, по логину (имя пользователя, номер телефона и т.д.) и паролю.

Авторизация – процесс, в течение которого определяются полномочия идентифицированного пользователя на доступ к определённым сетевым ресурсам.

Термин Учет использованных сетевых ресурсов уже сам по себе достаточно информативен. Первичными данными, которые передаются по протоколу RADIUS, являются объемы входящего и исходящего трафиков при передаче данных, и длительность разговора и набранный номер при использовании IP телефонии. Кроме определенных в протоколе стандартных атрибутов (параметров), протокол предусматривает возможность использования производителем оборудования (вендором) собственных атрибутов. В англоязычной литературе они называются Vendor Specific Attributes или VSA.

Протокол RADIUS был разработан компанией Livingston Enterprises (конкретно Карлом Ригней/Carl Rigney) для удаленного коммутируемого доступа через сетевые сервера доступа (Network Access Server – NAS) этой компании серии PortMaster к сети internet. Позже, в 1997, протокол RADIUS был опубликован как RFC 2058 и RFC 2059. Текущие версии RFC 2865 (Remote Authentication Dial In User Service (RADIUS)) и RFC 2866 (RADIUS Accounting). Иногда вместо понятия "сетевой сервер доступа" используется другой: "удаленный сервер доступа" (Remote Access Server – RAS).

В настоящее время протокол RADIUS используется для доступа к виртуальным частным сетям (VPN), точкам беспроводного (Wi-Fi) доступа, Ethernet коммутаторам, DSL и другим типам сетевого доступа. Благодаря открытости, простоте внедрения, постоянному усовершенствованию, протокол RADIUS сейчас является фактически стандартом для удаленной аутентификации.

Аутентификация и авторизация

Для выяснения работы RADIUS протокола рассмотрим рисунок 5.

Ноутбуки и IP телефон, представляют устройства пользователя, с которых необходимо выполнить аутентификации и авторизации на сетевых серверах доступа (NAS):

точке Wi-Fi доступа,

На рисунке показаны не все возможные варианты NAS. Существуют и другие сетевые устройства доступа.

RADIUS протокол реализовывается в виде интерфейса между NAS, который выступает как RADIUS клиент, и RADIUS сервером – программным обеспечением, которое может быть установлено на компьютере (сервере) или каком-то специализированном устройстве. Таким образом, RADIUS сервер, как правило, не взаимодействует напрямую с устройством пользователя, а только через сетевой сервер доступа.

Пользователь посылает запрос на сетевой сервер доступа для получения доступа к определенному сетевому ресурсу, используя сертификат доступа. Сертификат посылается на сетевой сервер доступа через сетевой протокол канального уровня (Link Layer), например, Point-to-Point Protocol (PPP) в случае выполнения коммутируемого доступа, Digital Subscriber Line (DLS) – в случае использования соответствующих модемов и т.п. NAS после этого, в свою очередь, посылает сообщение запроса доступа на RADIUS сервер, так называемый RADIUS Access Request. Этот запрос включает сертификаты доступа, которые обычно представлены в виде имени пользователя и пароля или сертификата безопасности, полученных от пользователя. Кроме этого запрос может содержать дополнительные параметры, такие как сетевой адрес устройства пользователя, его телефонный номер, информацию о физическом адресе, с которого пользователь взаимодействует с NAS.

RADIUS сервер проверяет эту информацию на корректность, используя такие схемы аутентификации, как PAP, CHAP, EAP и т.п.

Кратко опишем эти протоколы.

PAP (Password Authentication Protocol) (RFC1334)- простой аутентификационный протокол, который используется для аутентификации пользователя по отношению к сетевому серверу доступа (NAS). РАР используется РРР протоколом. Практически все сервера доступа поддерживают РАР. РАР передает незашифрованный пароль через сеть и, следовательно, является незащищенным протоколом. Поэтому РАР, обычно, используется в том случае, когда сервер не поддерживает защищенные протоколы, такие как СНАР, ЕАР и т.п.

CHAP (англ. Challenge Handshake Authentication Protocol) (RFC 1994) — широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP сервер удаленного доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя клиент вычисляет хеш-код MD5 (Message Digest-5) и передает его серверу. Хеш-функция является алгоритмом одностороннего (необратимого) шифрования, поскольку значение хеш-функции для блока данных вычислить легко, а определить исходный блок по хеш-коду с математической точки зрения невозможно за приемлемое время. (По хешированию существует много литературы, например, можно прочесть: Хеширование). Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае совпадения учётные данные клиента удалённого доступа считаются подлинными.

MD5 (Message-Digest algorithm 5) (RFC 1321) — широко используемая криптографическая функция с 128 битовым хешем. Найден ряд уязвимостей в алгоритме MD5, в силу чего в США департамент U. S. Department of Homeland Security не рекомендует использование MD5 в будущем, и для большинства правительственных приложений c 2010 года США требуется перейти на семейство алгоритма SHA-2.

Протокол EAP (Extensible Authentication Protocol) (RFC 3748) позволяет проверять подлинность при подключениях удаленного доступа с помощью различных механизмов проверки подлинности. Точная схема проверки подлинности согласовывается клиентом удаленного доступа и сервером, выполняющим проверку подлинности (им может быть сервер удаленного доступа или RADIUS сервер). По умолчанию в маршрутизацию и удаленный доступ включена поддержка протоколов EAP-TLS и MD5-Challenge (MD5-задача). Подключение других модулей ЕАР к серверу, использующему маршрутизацию и удаленный доступ, обеспечивает поддержку других методов ЕАР.

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

Схемы проверки подлинности, использующие протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент удаленного доступа и сервер, выполняющий проверку подлинности, должны поддерживать один и тот же тип EAP.

Читайте также:  Средний игровой ноутбук 2018

Теперь вернемся к RADIUS серверу, который проверяет информацию, полученную от NAS. Сервер проверяет идентичность пользователя, а также корректность дополнительной информации, которая может содержаться в запросе: сетевой адрес устройства пользователя, телефонный номер, состояние счета, его привилегии при доступе к запрашиваемому сетевому ресурсу.

По результатам проверки RADIUS сервер посылает NAS один из трех типов откликов:

Access-Reject показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject.

Access-Challenge. Запрос дополнительной информации от пользователя, например, второй пароль, пин-код, номер карты и т.п. Этот отклик также используется для более полного аутентификационного диалога, где защитный туннель выполняется между устройством пользователя и RADIUS сервером, так что сертификаты доступа скрываются от NAS.

Access Accept. Пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть доступ через беспроводную сеть, но запрещен доступ к VPN сети.

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

Access-Request: NAS-Identifier, NAS-Port, User-Name, User-Password (пароль может быть проигнорирован)

Материал из Xgu.ru

Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

RADIUS (Remote Authentication Dial In User Service, служба удалённой аутентификации дозванивающихся пользователей) — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта (Authentication, Authorization, and Accounting, AAA) пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.

Содержание

[править] Протокол RADIUS

[править] Свойства RADIUS

В соответствии со стандартом RADIUS, это:

  • Базирующийся на UDP протокол, который не использует прямых соединений
  • Использует модель безопасности hop-by-hop
  • Без состояний (stateless)
  • Поддерживает аутентификацию PAP и CHAP по PPP
  • Использует MD5 для скрытия паролей
  • Предоставляет более 50 пар атрибут/значение с возможностью создавать специфичные для производителя пары
  • Поддерживает модель AAA
  • Поддерживается большинством коммерческих устройств удалённого доступа

[править] Ограничения RADIUS

Во-первых, недостаточный уровень безопасности в некоторых реализациях. В случае использования нескольких промежуточных серверов RADIUS все они имеют возможность просматривать передающиеся через них аутентификационные данные – сертификаты и пароли.

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

В-третьих, RADIUS это протокол без поддержки состояний. Он не сохраняет транзакционную информацию и не использует её в следующих сеансах.

В-четвертых, RADIUS имеет не всегда достаточный уровень масштабируемости. На первой странице RFC замечание от IESG:

Experience has shown that [RADIUS] can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control. Readers of this document may find it beneficial to track the progress of the IETF’s AAA Working Group, which may develop a successor protocol that better addresses the scaling and congestion control issues.

[править] Доступные RADIUS-серверы

Существует огромнейшее количество RADIUS-серверов, отличающихся своими возможностями и лицензией, по которой они распространяются.

Свободно распространяемые RADIUS-серверы:

  • IAS – Internet Authentication Service – RADIUS-сервер от MS (Пример настройки RADIUS-сервера в Windows 2003)

Кроме того существует множество RADIUS-серверов, встроенных в биллинговые системы. Например, такие как:

Далее рассматривается FreeRADIUS. Это один из самых популярных и самых мощных RADIUS-серверов, существующих сегодня. Это хорошо масштабируемый, гибкий, настраиваемый и надёжный RADIUS-сервер.

[править] Инсталляция и настройка FreeRADIUS

[править] Инсталляция и настройка FreeRADIUS

Запуск RADIUS-сервера в режиме отладки:

В версии, поставляющейся в debian, файл называется freeradius (/usr/sbin/freeradius), а запуск в отладочном режиме, согласно официальной документации [1] осуществляется опцией -X, т.е.

Проверка конфигурационного файла FreeRadius-сервера:

[править] Конфигурационные файлы FreeRADIUS

FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.

Главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.

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

В файле содержится описание клиента. Синтаксис записей следующий:

Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)

Пример задания клиента:

Определяет префикс/суффикс для пользовательских имен – атрибут user-name. Используется для отсечения префикса/суффикса в ситуациях когда:

  1. Атрибут user-name перед авторизацией/тарификацией нужно избавить от имени домена и т.п., переданного клиентом, таким образом препроцессор трансформирует ‘user@domain.com’ в ‘user’
  2. Необходимо одному и тому же пользователю предоставлять разные сервисы и/или использовать разные схемы авторизации/аутентификации. Тогда для пользователя ‘user’ при входе как ‘user.ppp’ или ‘user.telnet’ можем определить разные схемы авторизации и при входе как ‘user.telnet’ можем добавить проверку вхождения в группу telnet-пользователей.

Позволяет определить разные группы NAS, к сожалению критерий для включения в группу один – IP-адрес NAS (дополнительно можно указывать порт или диапазон портов). При разборе users файла конфигурации позволяет использовать различные схемы авторизации/аутентификации/учета исходя из значения атрибута Huntgroup-Name

[править] Настройка атрибутов FreeRADIUS для динамического размещения порта коммутатора в VLAN’е по результатам аутентификации

Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):

  • [64] Tunnel-Type=VLAN (type 13)
  • [65] Tunnel-Medium-Type=802 (type 6)
  • [81] Tunnel-Private-Group- >RADIUS-сервер включает туннельные атрибуты в Access-Accept сообщение.

Это основные атрибуты, которые нужны для динамического размещения порта в VLAN’е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.

Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):

[править] Инсталляция и настройка dialupadmin

Программа dialupadmin предназначена для администрирования RADIUS-сервера через Web.

Читайте также:  Чем смазать ось кулера

В данный момент dialupadmin работает только с PHP4 для PHP5 заработчик его еще не адаптировал

[править] Совместное использование ActiveDirectory и FreeRADIUS

В отличие от других LDAP-серверов, active directory не возвращает ничего в атрибуте userPassword. Из-за этого нельзя использовать Active Directory для выполнения аутентификации CHAP, MS-CHAP или EAP-MD5. Можно использовать только аутентификацию PAP. Для этого в секции “authenticate” нужно указать “ldap”.

Для выполнения аутентификации MS-CHAP с помощью домена Active Directory, необходимо использовать NTLM-аутентификацию. Для этого потребуется проинсталлировать Samba.

Подробнее об этом в конфигурационном файле radiusd.conf и здесь RLM_LDAP.

Шаги по инсталляции и настройке:

  1. Проинсталлировать FreeRADIUS
  2. Проинсталлировать Samba-сервер
  3. Включить Samba-сервер в домен Active Directory
    • Убедиться, что wbinfo -u и wbinfo -g работает
    • Изменить настройки FreeRADIUS для использования модуля NTLM-аутентификации

    Note: By default, Windows XP can take up to two minutes to prompt for 802.1x authentication credentials. This process can be expedited by modifying the registry using the following procedure:

    1. Click on Start, Select Run, and run regedit.exe
    2. Navigate to the key
    3. Right-click on Global and select New and DWORD Value
    4. Name the new value SupplicantMode
    5. Once created, Right click this new option and select Modify
    6. Change the Value data to 3
    7. Reboot the system for the new registry changes to take effect.

    [3] I am assuming your domain is uing Internet Authentication Server (IAS) and 802.1x to authenticate the access by wireless user. In this case where 802.1x authentication is enabled, there is a registry key that controls how your wireless client authenticates to the backend IAS server. If you set the registry key HKEY_LOCAL_MACHINESoftwareMicrosoftEAPOLParametersGeneralGlobalAuthMo de to 1, what will happen is that the machine will authenticate to the domain before any user log on using machine credential (Machine Authentication) so that it will pull down any security setting the domain enforces, assuming the authentication succeeds. When the user logs on later, the user will need to do User Authentication as you normally do. By the way, if this reg key is not present, by default it is already to set to 1 and you already get the above behavior.

    [править] cisco VPN-сервер и RADIUS

    Данный пример описывает настройку маршрутизаторов cisco для организации pptp-доступа (да и других тунелирующих протоколов – pppoe, l2tp) из внешней сети (злых интернетов) в локальный сегмент сети. Основное назначение – доступ сотрудников к рабочему месту, доступ администратора к локальной сети предприятия из неожиданных мест. В качестве базы паролей используется файл users с паролями в plain-text (авторизация пользователей при этом происходит по ms-chap/ms-chap-v2). Пользователи получают при подключении ip-адрес, однозначно привязанный к их логину

    Предполагаемая конфигурация полностью совместима с обычным windows-режимом создания VPN-соединения (т.е. может быть организована без дополнительного ПО). Доступ с linux-машин осуществляется с помощью пакета ppptp-linux (и команды pon).

    192.168.1.1 – radius-сервер 192.168.2.2 – cisco 192.168.3.0/24 – сегмент для vpn-соедиенний

    Конфигурация циски (только часть, относящаяся к конфигурированию VPN):

    ppp-соединение с пользователем, эта опция указывает, исходя из какого шаблона создаётся этот виртуальный интерфейс)

    (обоих версий) и использовать OUR-VPN-NAME (см секцию aaa выше))

    Отладка процесса может быть включена командами debug ppp (см варианты подсказки по ?) и debug radius (аналогично). Выключение дебага no debug all. Просмотр лога – sh log, сброс лога – clear log.

    После установки freeradius (положение и имена файлов конфигурации для версии в составе debian lenny).

    /etc/freeradius/sites-enabled/default: закомментировать все строчки со словом ‘unix’ (отключает unix-авторизацию)

    /etc/freeradius/users, добавить пользователей:

    Перезапуск радиуса /etc/init.d/freeradius restart, запуск в отладочном режиме (после выполнения /etc/init.d/freeradius stop): freeradius -X

    (не забудте прописать на маршрутизаторах сети (не циско!) маршрут для сегмента, в котором выдаются адреса (в нашем случае, 192.168.3.0/24).

    С практической точки зрения было бы удобно управлять Wi-Fi сетями, выдавая пароль каждому пользователю. Это облегчает задачу с доступом к вашей беспроводной сети. Используя так называемую WPA2 PSK авторизацию, чтобы предотвратить доступ случайному пользователю, нужно менять ключ, а также заново проходить процесс авторизации на каждом отдельном Wi-Fi устройстве. Кроме того, если вы имеете несколько точек доступа, ключ нужно менять на всех из них. А если Вам надо скрыть пароль от кого-нибудь, придется раздать всем сотрудникам новый.

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

    Мы сделаем удобную схему, применяемую в корпоративных сетях, но полностью из подручных средств с минимальными финансовыми и аппаратными вложениями. Ее одобрит служба безопасности и руководство.

    Когда-то давно инженерами IEEE был придуман стандарт 802.1x. Этот стандарт отвечает за возможность авторизации пользователя сразу при подключении к среде передачи данных. Иными словами, если для соединения, например, PPPoE, вы подключаетесь к среде(коммутатору), и уже можете осуществлять передачу данных, авторизация нужна для выхода в интернет. В случае же 802.1x вы не сможете делать ничего, пока не авторизуетесь. Само конечное устройство вас не допустит. Аналогичная ситуация с Wi-Fi точками доступа. Решение же о допуске вас принимается на внешнем сервере авторизации. Это может быть RADIUS, TACACS, TACACS+ и т.д.

    Терминология

    Вообще авторизация пользователя на точке может быть следующих видов:

    • Open — доступна всем
    • WEP — старое шифрование. Уже у всех плешь проедена о том, что его ненадо использовать вообще
    • WPA — Используется TKIP в качестве протокола шифрования
    • WPA2 — Используется шифрование AES

    А теперь рассмотрим варианты того, как точка доступа узнает сама, можно ли предоставлять пользователю доступ к сети или нет:

    • WPA-PSK, WPA2-PSK — ключ к доступу находится в самой точке.
    • WPA-EAP, WPA2-EAP — ключ к доступу сверяется с некоторой удаленной базой данных на стороннем сервере

    Также существует довольно большое количество способов соедининея конечного устройства к серверу авторизации (PEAP, TLS, TTLS. ). Я не буду их здесь описывать.

    Читайте также:  Электромобиль nissan leaf цена

    Общая схема сети

    Для наглядного понимания приведем общую схему работы нашей будущей схемы:

    Если словами, то клиенту, при подключении к Wi-Fi — точке предлагается ввести логин и пароль. Получив логин и пароль Wi-Fi точка передает эти данные RADIUS-серверу, на что сервер отвечает, что можно делать с этим клиентом. В зависимости от ответа, точка решает, дать ему доступ, урезать скорость или что-то еще.
    За авторизацию пользователей будет отвечать наш сервер с установленным freeradius. Freeradius является реализацией протокола RADIUS, который в свою очередь является реализацией общего протокола AAA. AAA — это набор средств для осуществления следующих действий:
    Authentication — проверяет допустимость логина и пароля.
    Authorization — проверяет наличие прав на выполнение некоторых действий.
    Accounting — учитывает ваши дейсвия в системе.
    Сам протокол передает имя пользователя, список атрибутов и их значений для него. То есть, например, атрибут Auth-Type := Reject — отклонить этого клиента, а Client-Password == «password» — сравнить атрибут в запросе со значением password.
    Вообще говоря, база аккаунтов и прав для них не обязательно должна храниться на RADIUS-сервере, да и базой может быть что угодно — никсовые пользователи, пользователи домена Windows… да хоть текстовый файлик. Но в нашем случае все будет в одном месте.

    В этой статье нас будут интересовать в первую очередь WPA2-EAP/TLS способ авторизации.
    Практически все современные точки доступа Wi-Fi стоимостью больше 3 тыс. рублей поддерживают нужную нам технологию. Клиентские устройства поддерживают и подавно.
    В статье я буду использовать следующее оборудование и програмное обеспечение:

    • Точка доступа Ubiquiti NanoStation M2
    • Сервер Gentoo и Freeradius
    • Клиентское оборудование с установленным програмным обеспечением Windows 7, Android, iOS

    Настройка точки доступа

    Главное, чтоб точка поддерживала нужный способ аутентификации. Оно может называться по разному в разных устройствах: WPA-EAP, WPA2 Enterprise и т.д. Во всяком случае выбираем аутентификацию, устанавливаем IP-адрес и порт RADIUS-сервера и ключ, который мы вводили в clients.conf при настройке Freeradius.
    Приведу картинку с настроенной точки Ubiquiti. Помечено галкой то, что нужно менять.

    RADIUS-сервер

    Зайдем на наш компьютер с Linux и установим RADIUS-сервер. Я брал freeradius, и ставил я его на gentoo. К моему удивлению, в рунете нет материалов, относящихся к настройке Freeradius 2 для наших целей. Все статьи довольно стары, относятся к старым версиям этого програмного обеспечения.

    Все:) RADIUS-сервер уже может работать:) Вы можете проверить это так:

    Это debug-mode. Вся информация вываливается на консоль. Приступем к его настройке.
    Как это водится в Linux, настройка выполняется через конфигурационные файлы. Конфигурационные файлы хранятся в /etc/raddb. Сделаем подготовительные действия — скопируем исходные конфиги, почистим конфигурация от всякого мусора.

    Далее добавим клиента — точку доступа. Добавляем в файлик /etc/raddb/clients следующие строки:

    Далее добавляем домен для пользователей. Сделаем дефолтовый.

    И, наконец, добавляем пользователей в файл /etc/raddb/users:

    Ух, можно стартовать!

    Наш сервер запущен и ждет подключений!

    Настройка клиентов

    Пробежимся по настройке основных пользовательских устройств. У наших сотрудников есть клиенты, работающие на Android, iOS и Windows 7. Оговоримся сразу: так как мы используем самосозданные сертификаты, то нам нужно несколько раз вносить всевозможные исключения и подтверждать действия. Если бы мы пользовали купленные сертификаты, возможно, все было бы проще.

    Всех проще дело обстоит на iOS-устройствах. Вводим логин и пароль, нажимаем «Принять сертификат», и вперед.

    Чуть сложнее выглядит, но на практике все тоже просто на Android. Там немного больше полей для ввода.

    Ну и на Windows 7 приедтся немного понастраивать. Осуществим следующие шаги:
    Идем в центр беспроводных подключений.

    1. Устанавливаем необходимые параметры в свойствах Вашего беспроводного подключения
    2. Устанавливаем необходимые параметры в расширенных настройках EAP
    3. Устанавливаем необходимые параметры в расширенных настройках Дополнительных параметрах
    4. Подключаемся в панели задач к Wi-Fi сети и вводим логин-пароль, наслаждаемся доступом к Wi-Fi

    Далее представлю скриншоты диалоговых окон специально для похожих на меня людей, у которых глаза разбегаются от диалоговых окон Windows.

    Теперь осталась одна проблема — если вы захотите добавить-удалить нового пользователя, то вам придется изменить users и перезапустить radius. Чтобы этого избежать подключим базу данных и сделать свой собственный мини-биллинг для пользователей. Используя БД, вы всегда сможете набросать простенький скрипт для добавления, блокировки, изменения пароля пользователя. И все это произойдет без останова всей системы.

    Для себя я использовал Postgres, вы же можете выбрать по своему усмотрению. Я привожу базовую настройку Postgres, не углубляясь в различные права доступа, пароли и прочие хитрости и удобства.

    Для начала создаем саму базу данных:

    Далее надо создать нужные таблицы. Вообще с Freeradius идет документация по схемам таблиц для различных баз данных, правда в различных дистрибутивах находятся они в разных местах. У меня лично это лежит в /etc/raddb/sql/postgresql/schema.sql. Просто вставьте эти строки в psql, либо просто запустите

    На всякий случай добавлю сюда схему для Postgres:

    Отлично, база подготовлена. Теперь законфигурим Freeradius.
    Добавьте, если ее там нет, в /etc/raddb/radiusd.conf строку

    Теперь отредактируйте /etc/raddb/sql.conf под вашу реальность. У меня он выглядит так:

    Добавим несколько новых пользователей test1, test2, test3, и… заблокируем test3

    Ну, перезапускаем freeradius и пробуем подключиться. Должно все работать!

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

    В последнем разделе мы собрали собственный небольшой биллинг! Остается для полноты картины привернуть какой-нибудь WEB-интерфейс управления Базой Данных, добавить обязательное изменение пароля раз в месяц по крону. А если еще разориться сертификат и контроллер Wi-Fi точек доступа, то у вас в руках есть полноценная корпоративная беспроводная сеть. Но даже без этих затрат и при малых усилиях с Вашей стороны сделав своим пользователям такой доступ, они вам скажут огромное спасибо.

    “>

    Комментировать
    0 просмотров
    Комментариев нет, будьте первым кто его оставит

    Это интересно
    Adblock detector