Поиск сервиса/логина

При авторизации поиск сервиса Inet может осуществляться как по логину, так и по интерфейсу или VLAN'у. Для указания режима поиска необходимо прописать в конфигурации устройства-NAS'а или в конфиге любого его устройства-предка параметр:

radius.servSearchMode может принимать значения:

• 0 - поиск по логину из атрибута User-Name;

• 1 - поиск по интерфейсу на (найденном) устройстве;

• 2 - поиск по VLAN'у на устройстве (в предобработке должны быть проставлены опции AGENT_REMOTE_ID и AGENT_CIRCUIT_ID или VLAN_ID);

• 4 - поиск по VLAN'у на устройстве и его дочерних устройствах (в предобработке должны быть проставлены опции AGENT_REMOTE_ID и AGENT_CIRCUIT_ID или VLAN_ID);

• 5 - поиск по MAC-адресу на устройстве (в предобработке должна быть проставлена опция MAC_ADDRESS);

• 6 - поиск по MAC-адресу на устройстве и дочерних устройствах (в предобработке должна быть проставлена опция MAC_ADDRESS);

• 7 - поиск по адресу, указанному в User-Name, из диапазона адресов сервиса (в типе сервиса должно быть указано serv.search.address=1);

• 9 - поиск по адресу, указанному в User-Name, из диапазона адресов сервиса (в типе сервиса должно быть указано serv.search.address=1) на агентских (дочерних) устройствах;

• 10 - поиск по MAC-адресу на всех устройствах.

Также возможен дополнительный поиск дочернего сервиса:

<subServSearchMode> может принимать значения:

• 0 или отсутсвует - нет поиска дочернего сервиса

• 1 - поиск дочернего сервиса по MAC-адресу, если такого дочернего сервиса нет - ошибка авторизации;

• 2 - поиск дочернего сервиса по MAC-адресу, если такого дочернего сервиса нет - сессия будет привязана к родительскому сервису;

• 5 - поиск дочернего сервиса по IP-адресу из поля User-Name, если такого дочернего сервиса нет - ошибка авторизации;

• 6 - поиск дочернего сервиса по IP-адресу из поля User-Name, если такого дочернего сервиса нет - сессия будет привязана к родительскому сервису;

• 7 - проверка IP-адреса из поля User-Name на совпадение с IP-адресом сервиса или поиск дочернего сервиса по IP-адресу, если не совпадает и такого дочернего сервиса нет - ошибка авторизации;

• 8 - проверка IP-адреса из поля User-Name на совпадение с IP-адресом сервиса или поиск дочернего сервиса по IP-адресу, если не совпадает и такого дочернего сервиса нет - сессия будет привязана к родительскому сервису.

Например, radius.servSearchMode=1 - поиск по порту, radius.servSearchMode=2-1 - поиск по VLAN с проверкой MAC-адреса, radius.servSearchMode=2-7 - поиск по VLAN с проверкой IP-адреса.

Возможен последовательный поиск c разными режимами (если по первому режиму сервис не был найден - применяется следующий), для этого режимы нужно указать через запятую:

При поиске по логину поиск сервиса происходит по значению атрибута User-Name, по его совпадению с логином сервиса. После логина в атрибуте User-Name может быть указан реалм c разделителем @, например "vasya@local". Если реалм не указан, то предполагается, что пользователь использует реалм default. При этом принудительное указание реалма default (например, "vasya@default") не допускается.

Список допустимых реалмов указывается в параметре устройства/типа сервиса radius.realm через запятую, например:

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

При поиске по интерфейсу или VLAN'у, сервис может быть привязан к дочернему для NAS'а устройству - например, в случае Cisco ISG или Redback CLIPS - сервис привязан к коммутатору, NAS'ом выступает маршрутизатор. В этом случае необходимо в предобработке RADIUS-запроса установить опцию AGENT_REMOTE_ID со значением идентификатора дочернего коммутатора. Если опция будет присутствовать и такое дочернее устройство существует, то поиск сервиса будет идти относительно этого агентского устройства, иначе, по умолчанию, поиск идет относительно устройства-NAS'а.

Данную опцию необходимо устанавливать как в preprocessAccessRequest, так и в preprocessAccountingRequest. Значение обычно извлекается из RADIUS-атрибутов запроса, содержащих, например, значение субопций DHCP option 82. Значение можно установить как строкой, так и массивом байт (byte[]). В случае, если опция установлена в предобработке запроса, будет произведен поиск агентского устройства на совпадение с полем Идентификатор.

Также возможна схема с несколькими NAS'ами, работающими параллельно, в этом случае ветку с устройствами коммутаторами нужно завести отдельно (не делать ее дочерней по отношению к одному из устройств-NAS'ов), а в конфигурации устройств-NAS'ов указать параметр device.agentDeviceRootId =<x>, где <x> - ID устройства-папки, в котором находится подветка с коммутаторами:

Для определения интерфейса или VLAN возможны два способа: установка опции AGENT_CIRCUIT_ID или установка напрямую опции INTERFACE_ID/VLAN_ID. В первом случае значение номера интерфейся или VLAN из опции будет извлечено по параметрам конфигурации агентского устройства dhcp.option82.interfaceId.position, dhcp.82.interfaceId.length, dhcp.option82.vlanId.position, dhcp.option82.vlanId.length. Во втором - значение должно быть равно интерфейсу или порту.

Пример (установка опций из атрибутов-значений субоций DHCP option 82, данный код есть в обработчиках, которые входят в дистрибутив модуля):

Пример (vlan per user - поиск по vlan):

Таким образом для поиск сервиса возможен:

• - по атрибуту User-Name (по умолчанию);

• - по опциям AGENT_REMOTE_ID (идентификатор агентского устройства - устройства, на котором, собственно, интерфейс) и INTERFACE_ID (или AGENT_CIRCUIT_ID, содержащий номер интерфейса);

• - по опциям AGENT_REMOTE_ID (не обязательна, если в пределах NAS'а VLAN уникальны) и VLAN_ID (или AGENT_CIRCUIT_ID, содержащий номер VLAN'а).

При аутентификации во всех случаях происходит проверка пароля, поэтому в некоторых случаях пароль нужно устанавливать на NAS'е, в коде preprocessAccessRequest или, при необходимости, отключить проверку пароля для NAS'а:

RADIUS-атрибуты

Когда сервис определён, определяется набор атрибутов сессии, последовательным добавлением:

• атрибутов, определённых для реалма;

• атрибутов, определенных для сервиса(логина);

• атрибутов, определённых для опций.

Атрибуты задаются перечислением <имя атрибута>=<значение> через точку с запятой, если в значении атрибута должна присутствовать точка с запятой (т.е. это не разделение двух разных атрибутов), то её нужно указать два раза: ";;".

Выдача IP-адреса

Выдача IP-адреса производится через атрибут Framed-IP-Address из диапазона (адреса), указанного в самом сервисе на договоре (т.е. выдача статического IP-адреса), либо, если адрес в сервисе не указан или занят другой сессий этого же сервиса - из пула, определённого в конфигурации устройства параметром radius.realm.<realm>.ipCategories=<cat_codes>, где:

• <realm> - реалм;

• <cat_codes> - id коды категорий ресурсов IP-адресов через запятую.

Например, выдача динамических адресов из категории IP-ресурсов с кодом 4:

Вы также можете выдавать адреса из разных пулов в зависимости от активной опции Inet, указав опцию в тарифе или статически в сервисе на договоре. Таким образом, можно в зависимости от различных условий выдавать адреса из разных подсетей (для ситуации, когда баланс меньше лимита смотрите ниже Reject-To-Accept). Благодаря гибкости тарифа можно выдавать адреса из разных пулов в зависимости от баланса, активных тарифных опций, групп договоров, времени, периода и других условий.

Для этого в конфигурации устройства-NAS'а или корневого устройства укажите именованный пул адресов. Пул состоит из имени и перечисления id категорий ресурсов IP-адресов через запятую: resource.ip.pool.<name>.ipCategories=<cat_codes>

Далее создайте опции Inet, например, создав опцию-ветку "Пулы IP-адресов" и внутри нее опцию "Белый пул IP-адресов". В конфигурации устройства или типа устройства-NAS'а или же корневого устройства укажите привязку данной опции к пулу IP-адресов, например, если у созданной опции "Белый пул IP-адресов" ID=72:

Теперь, если в сервисе договора будет активна (с помощью тарифа или указана статически в сервисе) опция "Белый пул IP-адресов", то адрес будет выдаваться из пула whitePool, который состоит из IP-адресов категорий, указанных в параметре resource.ip.pool.whitePool=, т.е. в данном примере - из категории IP-ресурсов с ID=5. Если же опция будет не активна - то адрес будет выдан из параметра radius.realm.<realm>.ipCategories=<cat_codes>, если он указан.

Также вместо указания списка IP-категорий для реалма можно воспользоваться указанием имени пула, т.е. вместо radius.realm.default.ipCategories=4 указать, например:

При использовании схем IPoE возможна ситуация, когда с Cisco/SE приходит подряд несколько Access-Request'ов. Например, абонентский DHCP-клиент шлет сразу несколько DHCP-Discover-пакетов, или в Cisco инициация сессии срабатывает не только на DHCP-Discover, но и на DHCP-Request. По умолчанию для динамической выдачи IP-адресов InetAccess на каждый Access-Request выдает Access-Accept с новым IP-адресом, что может быть проблемой для связки DHCP-клиент+Cisco/SE. В этом случае можно использовать параметр radius.address.authReserveTimeout. При выдаче адреса он будет запоминаться по ключу сервис+устройство-NAS+(агентское_устройство)+User-Name+(MAC-address)+(CallingStationId)+(identifier) и в течении указанного времени (в миллисекундах) на очередной Access-Request с таким же ключом будет предлагать тот же адрес.

Reject-To-Accept

В случае ошибки авторизации высылается пакет AUTHENTICATION_REJECT с отображением ошибки и её кода в мониторе модуля. Допустимые коды ошибок данного процессора.

Вместо AUTHENTICATION_REJECT может быть выслан AUTHENTICATION_ACCEPT-пакет с дополнительными атрибутами. Перечень кодов ошибок, для которых производится подмена Reject-To-Accept определяется переменной конфигурации NAS'а radius.disable.accessCodes=<codes>, где <codes> - перечень кодов ошибок авторизации через запятую. Например:

Соответственно, для Reject-To-Accept могут быть собственные диапазоны IP-адресов, например:

Если же нужно выдавать статический IP-адрес такой же, как при обычном доступе (также, как когда не возникает ошибок авторизации), нужно указать режим:

Если нужно выдавать динамический IP-адрес такой же, как при обычном доступе - то нужно прописать в radius.disable.ipCategories те же самые пулы.

При ошибке авторизации, атрибуты выдаются из параметра radius.disable.attributes:

Атрибуты из опций Inet в данном режиме не выдаются.

Для поддержки Reject-To-Accept при ошибке с кодом 1 (Логин не найден), т.е. для предоставления гостевого доступа, необходимо создать договор с балансом меньше лимита и сервисом модуля Inet со статусом закрыт, а id сервиса прописать в конфигурации устройства:

Таким образом, сессии с ненайденным сервисом будут привязываться к указанному сервису.

При превышении числа сессий над ограничением, установленным для сервиса, генерируется ошибка авторизации. Данная ошибка также может быть обработана механизмом Reject-To-Accept с выдачей адреса из пула фиктивных адресов.

MAC-адрес и идентификатор

При RADIUS Access-Request можно также использовать MAC-адрес, чтобы авторизовывать запросы только с определенным MAC-адресом. MAC-адрес из Access-Request пакета устанавливается в Обработчике процессора протокола, в методе preprocessAccessRequest: request.setOption( InetRadiusProcessor.MAC_ADDRESS, macAddress ). Стандартные обработчики процессора протокола, поставляемые с модулем уже реализуют этот функционал, нужно только прописать в конфигурации устройства или типа устройства:

Или:

Таким образом, при извлечении MAC-адреса из RADIUS-пакета, он будет сравнен с MAC-адресом из аутентифицированного сервиса при условии, что в этом сервисе заведен MAC-адрес.

Для автоматического привязывания MAC-адреса к сервису в конфигурации модуля/типа сервиса/устройства/типа устройства можно прописать:

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

Аналогично MAC-адресу можно использовать поле Идентификатор сервиса. Например, в качестве идентификатора использовать значение атрибута Calling-Station-Id, устанавливая в Обработчике процессора протокола, в методе preprocessAccessRequest: request.setOption( InetRadiusProcessor.IDENTIFIER, callingStationId ).

Для автоматического привязывания идентификатора к сервису в конфигурации модуля/типа сервиса/устройства/типа устройства можно прописать:

Calling-Station-Id

Атрибут Calling-Station-Id используется для подстановки в поле сессии "С номера". При отсутствии данного атрибута можно настроить, чтобы обработчик процессора протокола (CoAProtocolHandler, SmartEdgeProtocolHandler, ISGProtocolHandler и другие) при предобработке RADIUS-запроса устанавливал значение в данный атрибут из другого, например, из атрибутра Mac-Address Redback (ID вендора 2352, ID типа атрибута 145):

Привязка сервиса к NAS'у или ветке NAS'ов

Для привязки сервиса к устройству - т.е. для того, чтобы клиент мог авторизоваться только на устройстве (NAS'е), привязанному к сервису, или являющимся дочерним по отношению к нему (устройству), необходимо указать в конфигурации устройства/типа устройства/типа сервиса:

Действие при получении Access-Request при наличии активной сессии

При подключении абонента может быть ситуация, когда в биллинге сессия еще активна, а клиент на самом деле уже отключился и пытается подключиться заново. Это может произойти при потере связи с NAS'ом (т.е. STOP-пакет не пришел, но connection.close.timeout еще не произошел), или, например, при использовании IPoE с Cisco/Redback (когда абонент подключил другое устройство, а Cisco/Redback по таймауту DHCP-lease еще не поняли, что старое соединение можно закрывать). Для обработки такой ситуации можно использовать параметр конфигурации radius.connection.checkDuplicate. Он работает в связке с Calling-Station-Id - если происходит попытка авторизации, а количество активных соединений превышено и среди активных соединений есть соединение с таким же Calling-Station-Id, то при указании radius.connection.checkDuplicate:

• 1 - происходит попытка сброса старого соединения (например, отправка PoD-пакета), абонента на этой авторизации не пускаем;

• 2 - происходит попытка сброса старого соединения, его завершение в биллинге, абонента на этой авторизации не пускаем, должно пустить при следующей попытке, т.к. старой сессии уже не будет;

• 3 - происходит завершение старого соединения в биллинге, абонента на этой авторизации не пускаем, должно пустить при следующей попытке, т.к. старой сессии уже не будет;

• 4 - происходит попытка сброса старого соединения, затем через 5 секунд завершение в биллинге, абонента на этой авторизации не пускаем;

• 5 - попытка сброса старого соединения в биллинге, завершение и пускаем немедленно (т.е. игнорируется ошибка );

• 6 - завершение старого соединения в биллинге, пускаем абонента немедленно;

• 7 - попытка в течении 5 секунд сбросить соединение, затем закрытие сессии в биллинге с ожиданием полного выполнения закрытия (т.е. IP-адрес станет свободным), пускаем абонента

• 8 - попытка сброса и сразу закрытие в биллинге с ожиданием полного выполнения закрытия (т.е. IP-адрес станет свободным), пускаем абонента;

• 9 - закрытие старого соединения в биллинге с ожиданием полного выполнения закрытия (т.е. IP-адрес станет свободным), пускаем абонента.

Для более быстрого подключения абонента при использовании и динамическим адресом рекомендуем использовать 4, 5, 6. Для статических адресов (чтобы абонент мог получить свой адрес) - 8,9.

Для обработки ситуации, когда количество активных соединений превышено, но соединения с таким Calling-Station-Id не найдено, и нужно отключить просто самое старое соединение, нужно указать цифру во втором разряде, например: 88.

Для сброса соединения с таким же Calling-Station-Id, даже если количество соединений не превышено, нужно указать цифру в третьем разряде, например, 808, 909, 888 или 818.

Этот параметр можно указать для типа сервиса, в конфигурации типа сервиса: serv.radius.connection.checkDuplicate.

В некоторых IPoE-схемах для обработки этого событие требуется использовать не Calling-Station-Id, а User-Name. Для этого нужно указать параметр radius.connection.checkDuplicate.type=1. В этом режиме будет проверяться User-Name из Access-Request с полем username сессии. Этот параметр можно указать для типа сервиса, в конфигурации типа сервиса: serv.radius.connection.checkDuplicate.type.

Блокировка частых Access-Request -> Access-Reject

Спам-запросы на авторизацию порождаются, обычно, забытым оборудованием, самостоятельно предпринимающем попытки авторизации на RADIUS. Постоянные обращения при таких запросах могут существенно повышать загрузку. Признаком спам-запроса являются несколько Reject-ответов на одинаковые запросы авторизации в течение определённого интервала времени. В этом случае подобные запросы попадают в спам-кэш на определённое время и по ним автоматически выдаётся Reject-ответ без полных проверок, производимых при авторизации. Для включения антиспам-системы в конфигурации модуля добавьте (требуется перезапуск InetAccess):

Где:

• <key_attributes> - RADIUS-атрибуты, идентифицирующие запрос, через запятую;

• <reject_count> - количество Reject, возвращённых на запрос с одинаковыми идентифицирующими атрибутами;

• <per_time> - за какое количество секунд выдано указанное в <reject_count> количество Reject-ответов;

• <ban_time> - время в секундах, на которое данный запрос попадает в спам-базу.

Например, запрос идентифицируется атрибутами User-Name и Calling-Station-Id. При десяти Reject-ответах в течении минуты запрос попадает в спам-базу на полчаса.