FreeRadius многоликий.
Всем хорош FreeRadius , но все какие-то плосковатые happy story мне попадались.
А если нужно котролировать Dialup, VPN, WiFi, 802.1x и во всех случаях разные пользователи, пароли, атрибуты, параметры....
Придется ставить множество radius серверов, резервировать, бекапировать....
Может трудности в общении с гуглем, но увы, не нашел рецептика. При этом каждый из пунктов в отдельности разжеван многократно.
Задача: независимо контролировать любой из возможных сервисов при значительном количестве пользователей. Затраты минимальны.
Берем стандартный freeradius плагин для хранения аккаунтов пользователей в MySQL.
Видим, что есть таблица хранения NAS ов, таблицы для персональных пользовательских параметров проверки/установки и точно такие-же данные в таблицах для групп. Конечно же, есть таблица-связка пользователя и группы. Гвоздь программы: возможность самостоятельного задания SQL запросов в конфигурационном файле и мапирование атрибутов Radius запросов на SQL.
На всякий случай смотрим на Radius запрос, причем самый клинический, c WiFi (тоесть с меткой про SSID: "VIP"):
User-Name = "dima"
Calling-Station-Id = "00-1B-21-C1-D2-62"
Called-Station-Id = "00-16-C7-21-3F-C3:VIP"
NAS-Port = 29
NAS-IP-Address = 10.0.7.104
NAS-Identifier = "Cisco_fa:33:1b"
Airespace-Wlan-Id = 4
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "975"
EAP-Message = 0x02020009016c656e51
Message-Authenticator = 0x5d1c50b996593ec2dec21dc5d481214e
Нас интересуют NAS-IP-Address (содержит адрес NAS, в данном случае Cisco контроллера WiFi) и Called-Station-Id ( содержащую MAC адрес access point-а и отметку о SSID : "00-16-C7-21-3F-C3:VIP" ).
Теперь внедряем понятие ServiceID в таблицы и запросы. В таблице NAS вносим поля CalledStation и ServiceID. В таблицах radcheck, radgroupcheck,radreply,radgroupreply добавляем поле ServiceID. В SQL запросах вносим связку по serviceID (на примере таблице radcheck):
SELECT...WHERE...
and nas.serviceid=radcheck.serviceid
and nas.nasname='%{NAS-IP-Address}'
and nas.calledstation=RIGHT('%{Called-Station-Id}',LENGTH(nas.calledstation))
Внимание на последнюю строку выше. Правая часть параметра "Called-Station-Id" из radius запроса сравнивается с полем СaledStation в таблице NAS. Размер правой части береться из того же поля таблицы. В случае с WiFi и SSID=VIP, если в таблице NAS внести в поле CalledStation значение ":VIP", то мы будем сравнивать его с 4-мя правыми символами параметра "Called-Station-Id" из radius запроса. При работе с WiFi для каждого SSID получим уникальный сервис со своими пользователями и группами. Если же CalledStation пустой, то "Called-Station-Id" из запроса вообще не учитывается и идентификатор сервиса будет зависеть только от "NAS-IP-Address" radius запроса.
А если указать в CalledStation в таблице NAS будет содержать и MAC адрес, то получаем сервис только для конкретного access point-а - пока не знаю как относится к этому, то ли побочный эффект, то ли фича.
Что мы имеем:
1) Имеем понятие идентификатора сервиса.
2) Для каждого идентификатора сервиса имеются пользователи и группы, независимые от других сервисов.
3) Идентификатор сервиса зависит от IP адреса NAS и опционально от параметра Called-Station-Id.
На одном Radius сервере получили полное и независимое управление аккаунтами для практически неограниченного количества сетевых сервисов. Правил только sql.conf и таблицы в MySQL. Все!
Забыл подводную граблю. При работе с WiFi и использовании PEAP необходимо для PEAP в файле eap.conf указать опцию:
copy_request_to_tunnel = yes
Дело в том, что при работе с PEAP внутри radius сервера проходит создание нового radius запроса на основе EAP сообщения в изначальном Radius запросе.
Если не указать copy_request_to_tunnel то внутренний radius запрос получится куцым, без полей "Called-Station-Id" и "NAS-IP-Address", а они критичны в нашей многоликости.
А если нужно котролировать Dialup, VPN, WiFi, 802.1x и во всех случаях разные пользователи, пароли, атрибуты, параметры....
Придется ставить множество radius серверов, резервировать, бекапировать....
Может трудности в общении с гуглем, но увы, не нашел рецептика. При этом каждый из пунктов в отдельности разжеван многократно.
Задача: независимо контролировать любой из возможных сервисов при значительном количестве пользователей. Затраты минимальны.
Берем стандартный freeradius плагин для хранения аккаунтов пользователей в MySQL.
Видим, что есть таблица хранения NAS ов, таблицы для персональных пользовательских параметров проверки/установки и точно такие-же данные в таблицах для групп. Конечно же, есть таблица-связка пользователя и группы. Гвоздь программы: возможность самостоятельного задания SQL запросов в конфигурационном файле и мапирование атрибутов Radius запросов на SQL.
На всякий случай смотрим на Radius запрос, причем самый клинический, c WiFi (тоесть с меткой про SSID: "VIP"):
User-Name = "dima"
Calling-Station-Id = "00-1B-21-C1-D2-62"
Called-Station-Id = "00-16-C7-21-3F-C3:VIP"
NAS-Port = 29
NAS-IP-Address = 10.0.7.104
NAS-Identifier = "Cisco_fa:33:1b"
Airespace-Wlan-Id = 4
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "975"
EAP-Message = 0x02020009016c656e51
Message-Authenticator = 0x5d1c50b996593ec2dec21dc5d481214e
Нас интересуют NAS-IP-Address (содержит адрес NAS, в данном случае Cisco контроллера WiFi) и Called-Station-Id ( содержащую MAC адрес access point-а и отметку о SSID : "00-16-C7-21-3F-C3:VIP" ).
Теперь внедряем понятие ServiceID в таблицы и запросы. В таблице NAS вносим поля CalledStation и ServiceID. В таблицах radcheck, radgroupcheck,radreply,radgroupreply добавляем поле ServiceID. В SQL запросах вносим связку по serviceID (на примере таблице radcheck):
SELECT...WHERE...
and nas.serviceid=radcheck.serviceid
and nas.nasname='%{NAS-IP-Address}'
and nas.calledstation=RIGHT('%{Called-Station-Id}',LENGTH(nas.calledstation))
Внимание на последнюю строку выше. Правая часть параметра "Called-Station-Id" из radius запроса сравнивается с полем СaledStation в таблице NAS. Размер правой части береться из того же поля таблицы. В случае с WiFi и SSID=VIP, если в таблице NAS внести в поле CalledStation значение ":VIP", то мы будем сравнивать его с 4-мя правыми символами параметра "Called-Station-Id" из radius запроса. При работе с WiFi для каждого SSID получим уникальный сервис со своими пользователями и группами. Если же CalledStation пустой, то "Called-Station-Id" из запроса вообще не учитывается и идентификатор сервиса будет зависеть только от "NAS-IP-Address" radius запроса.
А если указать в CalledStation в таблице NAS будет содержать и MAC адрес, то получаем сервис только для конкретного access point-а - пока не знаю как относится к этому, то ли побочный эффект, то ли фича.
Что мы имеем:
1) Имеем понятие идентификатора сервиса.
2) Для каждого идентификатора сервиса имеются пользователи и группы, независимые от других сервисов.
3) Идентификатор сервиса зависит от IP адреса NAS и опционально от параметра Called-Station-Id.
На одном Radius сервере получили полное и независимое управление аккаунтами для практически неограниченного количества сетевых сервисов. Правил только sql.conf и таблицы в MySQL. Все!
Забыл подводную граблю. При работе с WiFi и использовании PEAP необходимо для PEAP в файле eap.conf указать опцию:
copy_request_to_tunnel = yes
Дело в том, что при работе с PEAP внутри radius сервера проходит создание нового radius запроса на основе EAP сообщения в изначальном Radius запросе.
Если не указать copy_request_to_tunnel то внутренний radius запрос получится куцым, без полей "Called-Station-Id" и "NAS-IP-Address", а они критичны в нашей многоликости.