Перейти к содержимому

Отчет который выводит все активные radius сессии

  • автор:

Сервер RADIUS: как это работает для аутентификации клиентов

Серверы RADIUS широко используются многими учреждениями, которые предоставляют Wi-Fi возможность подключения с аутентификацией WPA2 / WPA3-Enterprise, то есть аутентификация, при которой у нас будет имя пользователя / пароль или цифровой сертификат для аутентификации в беспроводной сети. Он также широко используется операторами для доступа в Интернет. VPN сервисы для простой и быстрой аутентификации различных VPN-клиентов с использованием имени пользователя и пароля и даже для аутентификации через Ethernet с использованием стандарта 802.1X. Вы хотите подробно узнать, что такое RADIUS-сервер и для чего он нужен?

Что такое RADIUS-сервер и для чего он нужен?

РАДИУС ( Служба удаленного доступа для пользователей с телефонным подключением ) — это протокол, который выделяется тем, что предлагает механизм безопасности, гибкость, расширяемость и упрощенное управление учетными данными для доступа к сетевому ресурсу. Это аутентификация и авторизация протокол Для доступа к сети этот протокол использует схему клиент-сервер, то есть пользователь с учетными данными для доступа к ресурсу подключается к серверу, который будет отвечать за проверку подлинности информации и будет отвечать за определение того, получает ли пользователь доступ к совместно используемому ресурсу. Благодаря использованию серверов RADIUS сетевой администратор может в любое время контролировать начало и конец периода аутентификации и авторизации клиентов, например, мы можем легко исключить пользователя, который ранее вошел в систему по любой причине.

Серверы RADIUS широко используются интернет-операторами (PPPoE), но они также широко используются в сетях Wi-Fi отелей, университетов или в любом другом месте, где мы хотим обеспечить дополнительную безопасность беспроводной сети, его также можно использовать для аутентификации клиентов, которые делают использование протокола 802.1X для Ethernet, и его можно было бы даже использовать для аутентификации клиентов VPN, которые мы хотим, таким образом, у нас будет вся централизованная аутентификация в одной точке простым и простым способом, без необходимости иметь несколько баз данных с разными данными.

Серверы RADIUS используют протокол в UDP транспортный уровень на порт 1812 для установления соединения между командами для проверки подлинности. Когда мы настраиваем сервер RADIUS, мы можем определить, хотим ли мы, чтобы он использовал TCP или UDP, и мы также можем определить используемый порт, хотя по умолчанию это всегда UDP 1812. Что касается используемых устройств, есть отличные Многие маршрутизаторы могут предложить эту услугу для аутентификации клиентов WiFi на локальном или удаленном сервере RADIUS. Кроме того, можно использовать серверы, OLT и даже NAS-серверы, возможности действительно широки, что позволяет не только устанавливать сервер RADIUS, но и не является чем-то непосильным для пользователя, и это не сложно, потому что производители NAS-серверов уже легко включают внутренний сервер RADIUS. настраиваемый. Серверы RADIUS обычно используют протоколы аутентификации, такие как PAP, CHAP или EAP,

Роли RADIUS-сервера и приложений

Прежде всего, сервер RADIUS предлагает механизм аутентификации пользователя для доступа к системе либо к проводной сети с использованием протокола 802.1X, либо к сети WIFi, если у нас есть аутентификация WPA2 / WPA3-Enterprise, и даже к серверу OpenVPN, если мы правильно ли он настроен для получения базы данных клиентов, которые могут подключаться через этот сервер RADIUS.

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

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

Что такое FreeRADIUS и почему он связан с серверами RADIUS?

FreeRADIUS всегда связан с сервером RADIUS, потому что это программное обеспечение по преимуществу для установки сервера RADIUS. Если нам необходимо установить сервер RADIUS на любом компьютере (серверах, маршрутизаторах, NAS и т. Д.), Мы всегда будем прибегать к программному обеспечению FreeRADIUS, поскольку оно многоплатформенное, и все операционные системы совместимы с этим программным обеспечением. Это программное обеспечение поддерживает все распространенные протоколы аутентификации, такие как PAP, CHAP, EAP, EAP-TTLS, EAP-TLS и другие. Это программное обеспечение полностью модульное, бесплатное и обеспечивает отличную производительность для аутентификации клиентов.

Некоторые модули, которые мы можем включить в FreeRADIUS, должны обеспечить его совместимость с LDAP, MySQL, PostgreSQL и даже Oracle и другими базами данных, таким образом, мы можем иметь базу данных из тысяч клиентов без каких-либо проблем. Это программное обеспечение настраивается с помощью текстовых файлов конфигурации, однако, есть графические пользовательские интерфейсы для быстрой и простой настройки, как и в случае с pfSense, таким образом, это значительно облегчит настройку сервера RADIUS с помощью FreeRADIUS.

Программное обеспечение FreeRADIUS может быть дополнительно установлено в операционной системе pfSense, популярном межсетевом экране и маршрутизаторе, которые мы можем установить практически на любое оборудование. В этой операционной системе мы можем установить его в разделе пакетов, после установки мы можем ввести его конфигурацию в « Услуги / FreeRADIUS » раздел. В этом меню мы можем настроить этот сервер RADIUS расширенным способом, у нас будут разные вкладки для настройки различных разделов, а в меню «Просмотр конфигурации» мы можем увидеть необработанный файл конфигурации, который создается в результате конфигураций, которые мы сделали в остальных вкладках. Здесь мы также видим интеграцию с SQL и даже с LDAP.

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

Как вы видели, сервер RADIUS позволит нам выполнять большое количество аутентификаций и авторизации в другом программном обеспечении, например, у оператора, если используется PPPoE, в бизнес-сетях Wi-Fi с шифрованием WPA2 / WPA3-Enterprise и даже аутентификацией через 802.1 ИКС. FreeRADIUS — это программное обеспечение по преимуществу для настройки и запуска сервера RADIUS практически в любой операционной системе, по этой причине мы всегда говорим о сервере RADIUS или FreeRADIUS как синонимах.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Введение

Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin).

Модель клиент/сервер

Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные.

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

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

Сетевая безопасность

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

Гибкие аутентификационные механизмы

Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами.

Масштабируемый протокол

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

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

В этом документе используются следующие термины:

Услуга NAS обеспечивает пользователю, подключенному через модем, определенные услуги, такие как PPP или Telnet.
Сессия Каждый вид услуг, предоставляемый NAS через модемную связь, представляет собой сессию. Начало сессии сопряжено с моментом начала предоставления данной услуги, а конец — со временем завершения этого процесса. Пользователь может иметь несколько сессий одновременно, если сервер поддерживает такой режим.

Молчаливое удаление (silently discard)

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

2. Работа

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

Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]).

Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен.

Когда сервер RADIUS получил запрос, он проверяет корректность клиента-отправителя. Запрос, для которого сервер RADIUS не имеет общего секретного ключа (пароля), молча отбрасывается. Если клиент корректен, сервер RADIUS обращается к базе данных пользователей, чтобы найти пользователя, чье имя соответствует запросу. Пользовательская запись в базе данных содержит список требований, которые должны быть удовлетворены, прежде чем будет позволен доступ. Сюда всегда входит сверка пароля, но можно специфицировать клиента или порт, к которому разрешен доступ пользователя. Сервер RADIUS может посылать запросы к другим серверам, для того чтобы выполнить запрос, в этом случае он выступает в качестве клиента.

Если хотя бы какое-то условие не выполнено, сервер посылает отклик «Access-Reject» (отклонение Access-Reject текст комментария.

Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge). Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. Отклик-приглашение может содержать атрибут состояния (State). Если клиент получает Access-Challenge, он может отобразить текст сообщения и затем предложить пользователю ввести текст отклика. Клиент при этом повторно направляет свой Access-Request с новым идентификатором, с атрибутом пароля пользователя, замененным зашифрованным откликом. Этот запрос включает в себя атрибут состояния, содержащийся в приглашении Access-Challenge (если он там был). Сервер может реагировать на этот новый запрос откликами Access-Accept, Access-Reject, или новым Access-Challenge.

Если все условия выполнены, список конфигурационных значений для пользователя укладываются в отклик Access-Accept. Эти значения включают в себя тип услуги (например: SLIP, PPP, Login User) и все параметры, необходимые для обеспечения запрошенного сервиса. Для SLIP и PPP, сюда могут входить такие значения как IP-адрес, маска субсети, MTU, желательный тип компрессии, а также желательные идентификаторы пакетных фильтров. В случае символьного режима это список может включать в себя тип протокола и имя ЭВМ.

2.1. Запрос/Отклик

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

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

Пользователь вводит приглашение в свое устройство или программу и вычисляет отклик, который через клиента транспортируется серверу RADIUS посредством второго сообщения Access-Request. Если отклик соответствует ожидаемому значению, сервер присылает сообщение Access-Accept, в противном случае — Access-Reject.

Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение «challenge», но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой «Challenge 12345678, enter your response at the prompt», которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge.

2.2. Работа с PAP и CHAP

Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя .. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP.

Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP.

Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае — Access-Reject.

Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он должен прислать сообщение Access-Reject. Например, CHAP требует, чтобы пароль пользователя должен быть доступен серверу в открытом текстовом виде, чтобы он мог зашифровать CHAP-вызов и сравнить его с CHAP-откликом. Если пароль не доступен серверу RADIUS в таком виде, он должен послать клиенту сообщение Access-Reject.

2.3. Почему UDP?

Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:

1. Если запрос к первичному аутентификационному серверу не прошел, он должен быть переадресован вторичному серверу. Чтобы удовлетворить этому, копия запроса должна храниться на уровне выше транспортного, с тем, чтобы позволить альтернативную попытку. Отсюда следует, что необходим таймер ретрансмиссии.
2. Временные требования данного конкретного протокола значительно отличаются от тех, которые обеспечивает TCP.
3. Природа данного протокола не требует контроля состояния, что упрощает применение протокола UDP.

Клиенты и серверы приходят и уходят. Системы перезагружаются, а сетевое питание выключается и включается. UDP полностью исключает влияние всех этих событий на работу системы. Любой клиент и сервер может открыть UDP обмен однажды и оставлять его в таком состоянии, игнорируя какие-либо сбои в сетевой среде.

2.4. UDP упрощает реализацию сервера.

В ранних реализациях RADIUS сервер поддерживал один процесс (single threaded). Это означает, что только один запрос принимался, обрабатывался и отправлялся. Это оказалось неприемлемым для сред, где механизм обеспечения безопасности требует определенного времени (1 или более секунд). Очередь запросов в сервере будет значительной и в средах, где сотни людей требуют аутентификации каждую минуту, время обслуживания запроса становится настолько большой, что начинает нервировать пользователей. Очевидным решением проблемы является многопроцессный сервер. Достичь этого проще всего с помощью UDP. Порождаются отдельные процессы для обслуживания каждого запроса, а эти процессы могут напрямую взаимодействовать с клиентом NAS путем отправки UDP-пакета.

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

3. Формат пакета

Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на рис. .1. Разряды пронумерованы в порядке их передачи.

Рис. 1. Формат пакета RADIUS

Поле код содержит один октет и идентифицирует тип пакета RADIUS. Если получен пакет с неверным значением поля код, он молча отбрасывается.

Стандартизованы следующие значения поля код:

Код Назначение
1 Запрос доступа (Access-Request)
2 Доступ разрешен (Access-Accept)
3 Доступ не разрешен (Access-Reject)
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Сервер состояния (экспериментальный)
13 Клиент состояния (экспериментальный)
255 Зарезервировано

Коды 4 и 5 будут описаны в документе [RFC-2139]. Коды 12 и 13 зарезервированы для возможного использования.

Поле идентификатор имеет один октет, и служит для установления соответствия между запросом и откликом.

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

Поле аутентификатор имеет 16 октетов. Старший октет пересылается первым. Этот параметр служит для аутентификации отклика от сервера RADIUS, и используется в алгоритме сокрытия пароля.

В пакетах Access-Request, значение поля аутентификатор равно 16-октетному случайному числу, называемому аутентификатор запроса . Его значение должно быть непредсказуемым и уникальным на протяжении жизни секретного пароля, совместно используемого клиентом и RADIUS-сервером.

Значение аутентификатора запроса в пакете Access-Request должно быть также непредсказуемым, чтобы исключить возможные атаки.

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

NAS и сервер RADIUS используют секретный пароль совместно. Этот секретный пароль и аутентификатор запроса пропускаются через хэширование MD5, чтобы получить 16-октетный дайджест, который объединяется посредством операции XOR с паролем, введенным пользователем, результат помещается в атрибут пароля пользователя пакета Access-Request.

Значение поля аутентификатор в пакетах Access-Accept, Access-Reject, и Access-Challenge называется аутентификатором отклика (Response Authenticator). Оно представляет собой однопроходную хэш-функцию MD5, вычисленную для потока октетов, включающих в себя: пакет RADIUS, начинающийся с поля код , и включающий поля идентификатор , длина , аутентификатор запроса из пакета Access-Request, и атрибуты отклика, за которыми следует общий секретный пароль. То есть ResponseAuth = MD5(Код+ID+длина+RequestAuth+атрибуты+секретный_пароль) где знак + означает присоединение.

Секретный пароль, совместно используемый клиентом и сервером RADIUS, должен быть достаточно большим и непредсказуемым, как хороший пароль. Желательно, чтобы секретный пароль имел, по крайней мере, 16 октетов. Сервер RADIUS должен использовать IP-адрес отправителя UDP-пакета, чтобы решить, какой секретный пароль использовать.

Когда используется переадресующий прокси-сервер, он должен быть способен изменять пакет при проходе в том или ином направлении. Когда прокси переадресует запрос, он может добавить атрибут Proxy-State, а при переадресации отклика, он удаляет атрибут Proxy-State. Так как ответы Access-Accept и Access-Reject аутентифицированы по всему своему содержимому, удаление атрибута Proxy-State сделает сигнатуру пакета некорректной. По этой причине прокси должен вычислить ее заново.

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

В данном документе регламентированы атрибуты для пакетов с полем код, равным 1, 2, 3 и 11. Чтобы определить, какие атрибуты допускаются для пакетов с полем код=4 и 5, смотри [9].

4. Типы пакетов

Тип пакета RADIUS определяется полем тип, размещенным в первом октете.

4.1. Запрос доступа

Пакеты Access-Request посылаются серверу RADIUS, и передают информацию, которая используется для определения того, позволен ли данному пользователю доступ к специфицированному NAS, и допустимы ли запрошенные услуги. Программная реализация, желающая аутентифицировать пользователя, должна послать пакет RADIUS с кодом поля тип=1 (Access-Request).

При получении запроса (Access-Request) доступа от корректного клиента, должен быть передан соответствующий ответ. Запрос доступа (Access-Request) должен содержать атрибут имени пользователя. Он должен включать в себя атрибут NAS-IP-адреса или атрибут NAS-идентификатора (или оба эти атрибута, хотя это и не рекомендуется). Он должен содержать атрибут пароля пользователя (User-Password) или атрибут CHAP-пароля. Желательно, чтобы он содержал атрибут NAS-порта или NAS-Port-Type или оба эти атрибута, если только тип запрошенного доступа не содержал номер порта.

Запрос доступа (Access-Request) может содержать дополнительные атрибуты — подсказки серверу, но последний не обязан следовать этим подсказкам. Когда присутствует пароль пользователя (User-Password), он защищается с использованием метода, базирующегося на RSA алгоритме MD5 [1]. Формат пакета Access-Request аналогичен показанному на рис. .1. Только на месте поля аутентификатор размещается поле аутентификатор запроса (Request Authenticator), а в поле код записывается 1.

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

Значение поля аутентификатор запроса (Request Authenticator) должно изменяться, когда используется новый идентификатор.

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

4.2. Пакеты Access-Accept

Пакеты Access-Accept посылаются сервером RADIUS, и предоставляют специфическую конфигурационную информацию, необходимую для предоставления пользователю соответствующего сервиса. Если все значения атрибутов, полученных с запросом Access-Request, приемлемы, тогда реализация RADIUS должна послать пакет с полем код=2 (Access-Accept). При получении сообщения Access-Accept, поле идентификатор соответствует обрабатываему запросу (Access-Request). Кроме того, поле аутентификатор отклика должно содержать корректный отклик на полученный запрос Access-Request. Пакеты неверного формата молча отбрасываются. Формат пакета Access-Accept идентичен показанному на рис. .1. Но здесь вместо поля аутентификатор используется поле аутентификатор отклика , имеющее тот же размер. В поле код при этом записывается число 2.

Поле идентификатор является копией одноименного поля в запросе Access-Request, который инициировал сообщение Access-Accept.

Значение поля аутентификатор отклика (Response Authenticator) вычисляется на основе значения Access-Request, как это описано выше. Поле атрибуты имеет переменную длину и содержит список из нуля или более атрибутов.

4.3. Сообщение Access-Reject

Если какое-либо значение полученного атрибута неприемлемо, тогда сервер RADIUS должен послать пакет с полем код= 3 (Access-Reject). Пакет может содержать один или более атрибутов Reply-Message с текстом, который может быть отображен NAS для пользователя. Поле идентификатор для данного пакета копируется из одноименного поля пакета Access-Request, вызвавшего данный отклик.

Значение поля аутентификатор отклика вычисляется на основе содержимого сообщения Access-Request, как это описано выше.

4.4. Сообщение Access-Challenge

Если сервер RADIUS хочет послать пользователю вызов, требующий отклика, то сервер должен реагировать на запрос Access-Request посылкой пакета с полем код =11 (Access-Challenge). Поле атрибуты может содержать один или более атрибутов Reply-Message, и может опционно включать атрибут состояния. Никакие другие атрибуты здесь не применимы.

При получении Access-Challenge, поле идентификатор соответствует содержимому пакета Access-Request. Кроме того, поле аутентификатор отклика должно содержать корректный отклик на обрабатываемый запрос Access-Request. Некорректные пакеты молча отбрасываются. Если NAS не поддерживает обмен вызов/отклик (challenge/response), он должен обрабатывать сообщение Access-Challenge, как если бы это был запрос Access-Reject.

Если сервер NAS поддерживает обмен вызов/отклик, получение корректного сообщения Access-Challenge указывает, что следует послать новый запрос Access-Request. Сервер NAS может отобразить текстовое сообщение для пользователя, если таковое имеется, а затем предложить ему ввести отклик. Затем сервер посылает исходное сообщение Access-Request с новым идентификатором запроса и аутентификатором отклика, с атрибутом пароля пользователя, содержащим зашифрованный отклик пользователя. Кроме того, это сообщение содержит атрибут состояния (State) сообщения Access-Challenge, если таковой имелся.

NAS, который поддерживает PAP может переадресовать сообщение Reply-Message клиенту, подключенному по модемному каналу, и принять PAP-отклик, который он может использовать как отклик, введенный пользователем. Если NAS этого сделать не может, он должен воспринимать Access-Challenge, как если бы он получил сообщение Access-Reject. Формат пакета Access-Challenge совпадает с форматом Access-Accept и Access-Request.

Поле идентификатор является копией одноименного поля пакета Access-Request, который вызвал посылку Access-Challenge.

Значение аутентификатора отклика вычисляется так, как это было описано выше. Поле атрибуты имеет переменную длину, и содержит список из нуля или более атрибутов.

5. Атрибуты

Атрибуты RADIUS несут в себе специфическую аутентификационную и конфигурационную информацию для запросов и откликов. Некоторые атрибуты могут быть включены в список более одного раза. Воздействие такого использования зависит от типа атрибута.

Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина . Формат записи атрибута показан на рис. .2.

Рис. 2. Формат записи атрибута

Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 «Assigned Numbers» [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа.

Таблица .1. Cпецификация стандартизованных значений атрибутов

Поле длина является однооктетным, оно определяет длину данного атрибута, включая субполя тип, длина и величина . Если атрибут получен в запросе Access-Request, но с неверной длиной, следует послать сообщение Access-Reject. Если атрибут прислан в пакете Access-Accept, Access-Reject или Access-Challenge и имеет некорректную длину, пакет должен рассматриваться как Access-Reject или молча отбрасываться.

Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина . Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.

5.1. Имя пользователя

Этот атрибут указывает имя пользователя, который должен быть аутентифицирован. Он используется в пакетах Access-Request. Формат атрибута показан на рис. .3.

Рис. 3. Формат атрибута

Поле тип =1, длина ³ 3. Поле строка имеет один или более октетов. NAS может ограничить максимальную длину имени пользователя, но рекомендуется, чтобы программа была способна обрабатывать как минимум 63 октета. Применяется несколько форматов имени пользователя:

5.2. Пароль пользователя

Этот атрибут указывает на пароль аутентифицируемого пользователя или на вводимые пользователем данные в ответ на Access-Challenge. Этот атрибут используется только в пакетах Access-Request.

При передаче пароль шифруется. Пароль сначала дополняется нулями до границы кратной 16 октетам. Затем согласно алгоритму MD5 вычисляется хэш-функция. Это вычисление производится для потока октетов, состоящего из о бщего секретного пароля, за которым следует аутентификатор запроса (Request Authenticator). Для полученного кода и первых 16 октетов пароля производится операция XOR. Результат кладется в первых 16 октетов поля строка атрибута пароля пользователя.

Если пароль длиннее 16 символов, вычисляется вторая хэш-функция для потока данных, включающего в себя общий секретный пароль и результат предыдущей операции XOR. Полученный результат и вторые 16 октетов пароля объединяются с помощью операции XOR, а полученный код кладется во вторые 16 октетов поля строка атрибута User-Password. Если необходимо, эта операция повторяется. Следует только иметь в виду, что поле строка не может превышать 128 символов.

Данный метод заимствован из книги «Network Security» Кауфмана, Пелмана и Спесинера [4; стр. 109-110]. Более формализовано алгоритм можно описать следующим образом:

Берется общий секретный ключ S и псевдослучайный 128-битный аутентификатор запроса RA. Пароль разбивается на 16-октетные блоки p1, p2, …, pi. последний из них дополняется нулями до размера кратного 16 октетам. Далее реализуется алгоритм MD5. Берутся блоки шифрованного текста c(1), c(2), …, c(i), получаются промежуточные значения b1, b2, … bi:

Поле строка будет содержать c(1)+c(2)+. +c(i), где знак + означает присоединение.

При получении осуществляется обратный процесс и получается исходная форма пароля. В результате формируется атрибут, где в поле тип записан код 2, в поле длина число в интервале 18-130, а в поле строка — 16-128 октетов зашифрованного пароля.

5.3. Атрибут CHAP-пароль

Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае — в поле аутентификатор запроса . Формат атрибута CHAP-Password показан на рис. .4.

Рис. 4. Формат атрибута CHAP-Password

Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя.

5.4. Атрибут NAS-IP-Address

Этот атрибут указывает IP-адрес сервера NAS, который запрашивает аутентификацию пользователя. Атрибут применяется только в пакетах Access-Request. В пакете Access-Request должен присутствовать NAS-IP-адрес или NAS-идентификатор. Формат атрибута NAS-IP-Address представлен на рис. 5.

Рис. 5. Формат атрибута NAS-IP-Address

Поле адрес имеет протяженность 4 октета (IPv4).

5.5. Атрибут NAS-порт

Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на рис. .6.

Рис. 6. Формат атрибута NAS-порт

Диапазон кодов в поле значение составляет 0 — 65535.

5.6. Атрибут тип услуги (Service-Type)

Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт . Только поле тип =6. Коды поля значение перечислены в таблице .2..

Таблица .2. Коды поля значение

Таково назначение кодов атрибута типа услуг при использовании в сообщениях Access-Accept. Когда они применяются в пакетах Access-Request, они должны рассматриваться как подсказки серверу RADIUS и говорят, что NAS имеет причины полагать, что пользователь предпочтет указанные услуги, но сервер не обязан следовать этим подсказкам.

5.7. Атрибут Framed-Protocol

Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (рис. .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3.

Таблица .3. Коды поля значение

5.8. Атрибут Framed-IP-Address

Этот атрибут указывает на адрес, который следует сконфигурировать для пользователя. Атрибут может использоваться пакетами Access-Accept. Он может использоваться в пакетах Access-Request в качестве подсказки NAS, указывающей на то, что сервер предпочитает данный адрес. Сервер не обязан следовать этой подсказке. Формат атрибута идентичен представлению атрибута NAS-IP-адрес (рис. .5).

Поле тип = 8, поле длина = 6.

Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя.

5.9. Атрибут Framed-IP-Netmask

Этот атрибут указывает на сетевую IP-маску, которая должна быть сконфигурирована для пользователя, когда он является маршрутизатором сети. Атрибут может использоваться в пакетах Access-Accept. Он может использоваться в пакете Access-Request в качестве подсказки NAS серверу относительно того, какую сетевую маску он предпочитает. Но сервер не обязан следовать этой подсказке. Формат записи атрибута аналогичен формату атрибута NAS-IP-адрес. Поле тип = 9, поле длина = 6. Поле адрес имеет 4 октета и определяет сетевую IP-маску.

5.10. Атрибут Framed-Routing

Этот атрибут указывает метод маршрутизация для пользователя, когда пользователем является маршрутизатор сети. Атрибут может использоваться в пакетах Access-Accept. Формат записи атрибута аналогичен показанному на рис. .6 (NAS-порт). Поле тип = 10, поле длина = 10. Допустимые коды и их назначения собраны в таблице .4

Таблица .4. Допустимые коды поля значение и их назначения

5.11. Атрибут Filter-Id

Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует рис. .3. поле тип = 11, поле длина ³ 3.

Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов.

5.12. Атрибут Framed-MTU

Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535.

5.13. Атрибут Framed-Compression

Этот атрибут указывает на протокол сжатия, который следует использовать при передаче данных. Атрибут используется в пакетах Access-Accept. Атрибут используется в пакетах Access-Request в качестве подсказки серверу о том, какой вид компрессии предпочитает использовать NAS, но сервер не обязан следовать этой рекомендации.

Можно использоваться несколько атрибутов данного типа. Окончательное решение о применении того или иного метода компрессии принимает сервер NAS.

Формат атрибута аналогичен показанному на рис. 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5.

Таблица .5. Возможные коды поля значение

5.14. Атрибут Login-IP-Host

Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на рис. .5. Поле тип = 14, а поле длина = 6.

Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя.

5.15. Атрибут Login-Service

Этот атрибут указывает на услугу, которая будет использоваться для соединения пользователя с ЭВМ. Атрибут применяются только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 15, а поле длина = 6. Возможные коды поля значение собраны в таблице .6.

Таблица .6. Возможные коды поля значение

5.16. Атрибут Login-TCP-Port

Этот атрибут указывает порт TCP, с которым следует соединить пользователя при наличии атрибута Login-Service. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 16, а поле длина = 6. Поле значение имеет четыре октета и может содержать величины в диапазоне 0 — 65535.

5.17. Атрибут типа 17 в настоящее время не определен.
5.18. Атрибут Reply-Message

Этот атрибут содержит текст, который может быть отображен для пользователя. Если используется в пакете Access-Accept, это сообщение об успешном выполнении. При использовании с Access-Reject, это уведомление о неудаче. Это может быть элемент диалога с пользователем перед очередной попыткой послать запрос доступа (Access-Request).

Когда атрибут используется в Access-Challenge, он может содержать приглашение пользователю ввести отклик. Допускается применение нескольких атрибутов Reply-Message, в этом случае они должны отображаться в порядке из записи в пакете. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 18, а поле длина ³ 3.

Поле строка содержит один или более октетов. Его содержимое может зависеть от конкретной программной реализации. Содержимое должно быть читабельным и не должно влиять на работу протокола. Рекомендуется, чтобы текст состоял из печатных ASCII символов с кодами 10, 13 и 32 — 126.

5.19. Атрибут Callback-Number

Этот атрибут представляет собой телефонный номер, используемый для обратного дозвона. Атрибут может использоваться в пакетах Access-Accept, а также в Access-Request в качестве подсказки серверу о том, что желателен обратный дозвон, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 19, а поле длина ³ 3.

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

5.20. Атрибут Callback-Id

Этот атрибут содержит имя места вызова, которое должно быть интерпретировано сервером NAS. Атрибут может использоваться пакетами Access-Accept. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 20, а поле длина ³ 3.

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

5.21. Атрибут типа 21 в настоящее время не определен
5.22. Атрибут Framed-Route

Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 22, а поле длина ³ 3.

Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 — 126.

Для IP-маршрутов, атрибут должен содержать префикс места назначения в десятично-точечном представлении (как IP-адрес). Далее опционно может следовать косая черта и число старших бинарных единиц, указывающее на количество разрядов префикса, которые следует использовать. Далее следует пробел, адрес шлюза, еще один пробел и один или более кодов метрики, разделенных пробелами. Например, «192.168.1.0/24 192.168.1.1 1 2 -1 3 400». Длина спецификатора может быть опущена, тогда для префикса класса А подразумевается длина в 8 бит, для класса В — 16 и для класса С — 24 бита. Например, «192.168.1.0 192.168.1.1 1». Если адрес шлюза равен «0.0.0.0», тогда в качестве IP-адреса шлюза следует использовать адрес пользователя.

5.23. Атрибут Framed-IPX-Network

Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя. Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 23, а поле длина = 6.

Поле значение имеет 4 октета. Значение 0xFFFFFFFE указывает, что сервер NAS должен выбрать для пользователя сеть IPX (т.е. выбрать одну или более IPX-сетей из имеющегося списка). Остальные значения должны рассматриваться как IPX-сети, предназначенные для подключения.

5.24. Атрибут State

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

Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 24, а поле длина ³ 3.

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

5.25. Атрибут Class

Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 25, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.26. Атрибут Vendor-Specific

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

Серверы, не приспособленные для интерпретации информации, специфической для производителя оборудования или программ, должны игнорировать эти атрибуты (хотя могут и оповещать об этом). Клиенты, которые не получили желательной информации, специфической для изготовителя, должны предпринять попытку работать без этих данных. При этом функциональность может быть сужена (о чем клиент может сообщить пользователю). Формат записи атрибута показан на рис. .7. Поле тип = 26, а поле длина ³ 7.

Рис. 7. Формат записи атрибута Vendor-Specific

Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой.

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

Рис. 8. Пример формата строки

Поле строка предназначено для записи параметров, специфических для данного производителя.

5.27. Атрибут Session-Timeout

Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 27, а поле длина = 6.

Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS).

5.28. Атрибут Idle-Timeout

Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 28, а поле длина = 6.

Поле значение содержит 4 октета и несет в себе 32-битовое целое число без знака, соответствующее максимальному времени пассивности клиента в секундах. По истечении этого времени соединение с сервером разрывается.

5.29. Атрибут Termination-Action

Этот атрибут указывает, какие действия должен выполнить сервер NAS, когда процедура будет завершена. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 29, а поле длина = 6. Поле значение имеет 4 октета. Ниже приведены разрешенные коды поля значения.

Если поле значение соответствует RADIUS-Request, по завершении соответствующего сервиса NAS может послать новый запрос Access-Request серверу RADIUS, включив атрибут State, если он имеется.

5.30. Атрибут Called-Station-Id

Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь. При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 30, поле длина ³ 3.

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

Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI — Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 31, поле длина ³ 3.

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

5.32. Атрибут NAS-идентификатор

Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 32, а поле длина ³ 3.

Поле строка содержит один или более октетов, и должна быть уникальной для NAS в области действия сервера RADIUS. Например, полное имя домена вполне подходит в качестве NAS-идентификатора. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.33. Атрибут Proxy-State

Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge. Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 33, а поле длина ³ 3.

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

5.34. Атрибут Login-LAT-Service

Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации.

Администраторы используют атрибут сервиса, когда имеют дело с кластерными системами, такими как VAX или Alpha-кластер. В такой среде несколько процессоров совместно используют общие ресурсы (диски, принтеры и т.д.), и администраторы конфигурируют каждый из них для обеспечения к каждому из ресурсов. В этом случае каждая ЭВМ в кластере оповещает о предоставляемых услугах через широковещательные сообщения LAT.

Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 34, а поле длина ³ 3.

Поле строка имеет один или более октетов и содержит идентификатор LAT-сервиса. Архитектура LAT позволяет этой строке содержать $ (доллар), — (дефис), . (точка), _ (подчеркивание), числа, буквы верхнего и нижнего регистров, а также расширенный символьный набор ISO Latin-1 [6]. Все сравнения в LAT не зависят от регистра символов.

5.35. Атрибут Login-LAT-Node

Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 35, а поле длина ³ 3.

Поле строка имеет один или более октетов и содержит идентификатор узла LAT, с которым следует соединиться пользователю. Архитектура LAT позволяет этой строке содержать $ (доллар), — (дефис), . (точку), _ (подчеркивание), числа, буквы нижнего и верхнего регистров, а также расширяющий символьный набор ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

5.36. Атрибут Login-LAT-Group

Этот атрибут содержит строку, идентифицирующую групповой код LAT, который данный пользователь авторизован использовать. Атрибут может использоваться в пакетах Access-Accept, но только когда специфицирован LAT в качестве Login-Service. Он может быть использован в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. LAT поддерживает 256 различных групповых кодов, которые LAT использует как некую форму прав доступа. LAT преобразует эти групповые коды в 256 битовую карту соответствия (bitmap).

Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту. Старший октет передается первым.

5.37. Атрибут Framed-AppleTalk-Link

Этот атрибут содержит сетевой номер AppleTalk, который должен быть использован для последовательного канала пользователя, являющимся маршрутизатором сети AppleTalk. Атрибут применяется только в пакетах Access-Accept. Он никогда не используется, когда пользователь не является маршрутизатором. Формат записи атрибута показан на рис. .6. Поле тип = 37, а поле длина =6.

Поле значение имеет 4 октета. Допустимый диапазон значений 0 — 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk.

5.38. Атрибут Framed-AppleTalk-Network

Этот атрибут представляет собой сетевой номер AppleTalk, который сервер NAS должен попытаться присвоить узлу AppleTalk. Атрибут используется только в пакетах Access-Accept. Атрибут никогда не используется, если пользователем является маршрутизатор. Многократное использование атрибута в пакете указывает на то, что NAS может попытаться использовать один из сетевых номеров, приведенных в атрибутах. Формат записи атрибута показан на рис. .6. Поле тип = 38, а поле длина =6.

Поле значение содержит 4 октета. Допустимый диапазон значений 0 — 65535. Специальное значение 0 указывает, что NAS должен назначить сеть для пользователя. Значения в интервале 1 — 65535 (включительно) указывает на сеть AppleTalk, адрес которой должен найти сервер NAS для пользователя.

5.39. Атрибут Framed-AppleTalk-Zone

Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на рис. .3. Поле тип = 39, а поле длина ³ 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя.

5.40. Атрибут CHAP-Challenge

Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на рис. .3. Поле тип = 60, а поле длина ³ 7. Поле строка содержит сообщение CHAP Challenge.

5.41. Атрибут NAS-Port-Type

Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на рис. .6. Поле тип = 61, а поле длина =6.

Поле значение имеет 4 октета. «Виртуальный» (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом.

Таблица .7. Код поля значение атрибута NAS-Port-Type

5.42. Атрибут Port-Limit

Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на рис. .6. Поле тип = 62, а поле длина = 6.

Поле значение имеет 4 октета и содержит 32-битовое целое число без знака, которое определяет максимальное число портов, к которым пользователь может быть подключен сервером NAS.

5.43. Атрибут Login-LAT-Port

Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на рис. .3. Поле тип = 63, а поле длина ³ 3.

Поле строка имеет один или более октетов и содержит идентификатор порта LAT, который следует использовать. Архитектура LAT позволяет этой строке содержать $ (доллар), — (дефис), . (точку), _ (подчеркивание), цифры, буквы верхнего и нижнего регистра, а также расширенный набор символов ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

5.44. Таблица атрибутов

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

Таблица .8. Основные характеристики атрибутов

[*] Запрос Access-Request должен содержать пароль пользователя или CHAP-пароль, но не должен содержать и то и другое.

Ниже в таблице представлены обозначения, использованные в таблице 8.

6. Примеры

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

6.1. Удаленный доступ пользователя на указанную ЭВМ (Telnet)

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3.

Code = 1 (Access-Request)
ID = 0
Request Authenticator = <16-октетное случайное число>
Атрибуты:
User-Name = «NEMO»

NAS-IP-Address = 192.168.1.16
NAS-Port = 3

Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом.

Code = 2 (Access-Accept)
ID = 0 (то же самое, что и в Access-Request)
Response Authenticator = <16-октетная контрольная сумма MD-5 кода (2),

id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля >

Атрибуты:
Service-Type = Login-User
Login-Service = Telnet
Login-Host = 192.168.1.3

6.2. Кадровая аутентификация пользователя посредством CHAP

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP-пакете серверу RADIUS для пользователя с именем VANYA для подключения к порту 20 в рамках протокола PPP. Аутентификация осуществляется посредством CHAP. NAS посылает атрибуты Service-Type и Framed-Protocol в качестве рекомендаций серверу RADIUS воспользоваться PPP, хотя NAS необязательно этому последует.

Code = 1 (Access-Request)
ID = 1

Атрибуты:
User-Name = » VANYA»

NAS-IP-Address = 192.168.1.16
NAS-Port = 20
Service-Type = Framed-User
Framed-Protocol = PPP

Сервер RADIUS аутентифицирует VANYA и посылает запрос Access-Accept в UDP-пакете серверу NAS, сообщая, что он отрывает PPP-сессию и приписывает адрес пользователю из имеющегося у него списка.

Code = 2 (Access-Accept)
ID = 1 (тот же, что и в Access-Request)
Response Authenticator =

Атрибуты:
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = 255.255.255.254
Framed-Routing = None
Framed-Compression = 1 (Компрессия заголовка VJ TCP/IP)
Framed-MTU = 1500

6.3. Пользователь с картой вызова-отклика (Challenge-Response)

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request серверу RADIUS для пользователя с именем MANYA, подключаемого к порту 7.

ID = 2
Request Authenticator =

Атрибуты:
User-Name = » MANYA»
User-Password = <16 октетов пароля дополненные в конце нулями,
объединенный функцией XOR с MD5 (общий секретный ключ |Request Authenticator)>
NAS-IP-Address = 192.168.1.16
NAS-Port = 7

Сервер RADIUS решает вызвать MANYA, отсылая назад строку вызова и ожидая отклика. Сервер RADIUS посылает запрос Access-Challenge серверу NAS.

Атрибуты:
Reply-Message = «Challenge 32769430. Enter response at prompt.»
State =

Пользователь вводит свой отклик, а NAS посылает новый запрос Access-Request с этим откликом и атрибутом State.

Отклик был некорректен, поэтому сервер RADIUS предлагает NAS отклонить попытку входа в систему.

(отсутствуют, хотя сообщение Reply-Message может быть послано)

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

Пароли должны храниться в местах с ограниченным доступом. Эти данные должны быть доступны только процессам, которые с ними работают.

5.4.1 Функции авторизации (первая часть)

Функции авторизации используются для формирования значения атрибута ответа и задания правил обработки атрибутов в пакете Access Request.

Уникальность определяет правило, по которому формируется окончательное значение атрибута ответа в пакете Access Request, полученное с помощью функций авторизации.

Добавление. Добавление значений атрибута (свойств подключения, помеченных соответствующей AV-парой) при условии совпадения домена ТПС и домена NAS;

Добавление (всегда). Добавление значений атрибута (свойств подключения, помеченных соответствующей AV-парой) независимо от доменов NAS и ТПС;

Замена атрибута. Замена значения одного атрибута значением другого при условии совпадения домена ТПС и домена NAS;

Замена атрибута (всегда). Замена значения одного атрибута значением другого независимо от доменов NAS и ТПС;

Замещение. Замена значения атрибута, выданного функцией, на значение, определенное при подключении, при условии совпадения домена ТПС и домена NAS;

Замещение (всегда). Замена значения атрибута, выданного функцией, на значение, определенное при подключении, независимо от домена ТПС;

Не вызывать функцию. Временное отключение функции;

Только вызов функции. Запрет передачи значения атрибута, выданного функцией, в ответе на авторизацию.

Правила обработки RADIUS-атрибутов с помощью функций авторизации задаются в разделе Администратор | Система авторизации | Сервисы сети при описании сервиса сети в подразделе AV-пары путем задания значения полей:

Функция;

Значение;

Уникальность.

Есть следующие функции авторизации.

Check-Stop-Lis

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

Значение свойства подключения

Значение свойства атрибута D-Stop-List с подключения тех. договора

CoA-Добавление информации в ответ

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

CoA-Обработчик добавления/удаления атрибута

Функция вызывается при CoA-проверке параметров при обнаружении нового атрибута, для которого определена данная функция, или при удалении существовавшего ранее. В качестве параметра функции задаются правила обработки добавленного/удаленного атрибута в виде: [RADIUS-атрибут]=[Значение RADIUS-атрибута]. Значение RADIUS-атрибута содержит текстовую строку, в которой могут использоваться следующие подстановки:

%VAL[X:Y]%. Обрабатываемое значение атрибута, для которого определена функция. X и Y определяют начало и конец подстроки, если не нужно использовать все значение;

(%NEW%|%OLD%)<Название RADIUS-атрибута>. Значение атрибута с именем <Название RADIUS-атрибута>. Если таких атрибутов несколько, то будет подставлено агрегированное значение (конкатенация всех значений в порядке их появления в ответе). Перед названием атрибута может быть указан квалификатор %NEW% или %OLD%, определяющий, из какого пакета будет взято значение: из пакета, сформированного предыдущей авторизацией (%OLD%), или из пакета, сформированного текущей авторизацией (%NEW%). Если квалификатор не указан, по умолчанию будет использоваться пакет %NEW%;

//HEX_STR//. Преобразование части строки, расположенной после указанной строки, в HEX-представление. Рекомендации по работе с функциями приведены в разделе 5.19. Расширенный функционал CoA;

PoD при «висячих» Interim

Используется совместно с функцией Отслеживание изменений параметров сессии. Функция выполняет попытку закрыть сессию отправкой PoD-пакета при отсутствии информации об авторизации (если не была выполнена авторизации по Auth-Request и не проводилась проверка CoA). Сессия закрывается по Accounting-Stop или таймауту. Используется с любым атрибутом.

Radius eval

Функция позволяет вставить в string-атрибут произвольный набор атрибутов и констант.

Значение свойства подключения

Route:<D-Tans-LP>@192.168.0.1;credit=<Session-Timeout> Функция Timeout включена раньше Radius eval

Radius eval (Input)

Функция позволяет сымитировать новый входной атрибут на основе имеющихся. Работает аналогично функции Radius eval, только результат добавляется ко входному набору атрибутов, а не к выходному.

Service Access

Функция выдает значение ошибки 106 в Кодах возврата, если не найдена цена. Обычно включают до функции Timeout. Используется с любым атрибутом.

Session-Upd-Time

Функция задает время ожидания alive-пакета. Рекомендуемое время ожидания alive-пакета должно быть больше времени, заданного на оборудовании предоставления доступа. Если нет stop-пакета и превышено время ожидания следующего alive-пакета, тарификация происходит по последнему alive-пакету. Если stop-пакет все же придет, сессия будет перетарифицирована. Используется с любым свободным атрибутом.

Значение свойства подключения

Только вызов функции

Set NAS by NAS-IP-Address

Функция позволяет использовать в качестве NAS в уникальном ключе сессии не IP-адрес, с которого поступил запрос, а значение атрибута NAS-IP-Address. Аргумент: дата в формате DD.MM.YYYY HH:MM, начиная с которой функция будет действовать.

Значение свойства подключения

Только вызов функции

Set Start by Auth

Функция используется для того, чтобы в момент авторизации автоматически создавалась запись Start-Accounting. Используется с любым атрибутом.

SSG Idle Timeout

Функция используется для вычисления атрибута Idle-Timeout при использовании SSG. Аргумент в формате timeout;count. Если функция Квота возвращает значение 0, атрибут Idle-Timeout=timeout выставляется count раз, после чего происходит посылка сигнала Access-Reject.

Значение свойства подключения

Добавление, Добавление (всегда), Замещение, Замещение (всегда)

Timeout

Функция определения продолжительности сессии. Используется с атрибутом Session-Timeout.

Значение свойства подключения

TimeOut + Traffic

Функция определяет максимально возможное время продолжительности сессии аналогично функции Timeout, но с учетом того, что потребленный трафик тоже будет тарифицирован. При этом предполагается, что трафик будет потребляться в среднем с указанной скоростью. Скорость потребления задается в атомарных для АСР Онима единицах: число байтов в секунду (байт/с). Аргументы функции задаются в виде: [Максимальное время сессии (c)];[Маска статистики для трафика];[Скорость потребления трафика (байт/с)].

Значение свойства подключения

Unis eval

Функция предназначена для обработки сложных случаев преобразования AV-пар. Функция авторизации выполняется на стороне unis, сразу после определения сервиса сети по префиксу. Функции Unis-Eval по формату выражений обратно совместимы с функциями Radius eval. Можно использовать такой формат записи для свойств сервиса сети. Более подробно работа с функциями описана в разделе 5.5.3. Использование функций авторизации Unis eval;

Upper

Функция переводит значение атрибута User-Name в верхний регистр. Используется с любым свободным атрибутом;

Белый список

Используется для организации белых списков при авторизации. Функция выполняет проверку наличия атрибута в списке. В качестве параметра передается:

ID списка. Точное совпадение;

*ID списка. Совпадение суффикса;

ID списка*. Совпадение префикса. Список просматривается иерархически, начиная с указанного ID. Например, делается такое дерево списка:

В этом случае, если будут разрешены звонки только с номеров 8612123456, 8612567890, 8613134567 (или, например, 2123456 и т. п. — проверяется совпадение суффикса), остальные будут отклонены.

Блокировать лицевой счет на время обработки

Функция блокирует лицевой счет без ожидания, т. е. если лицевой счет уже заблокирован (возможно репликатором), то возвращается ошибка 105Session Limit.

Блокировать переход сессии через интервал тарификации

Функция позволяет выполнить разрыв сессии при переходе через интервал тарификации при помощи корректировки результата функции Timeout. Добавляется с любой AV-парой и условием уникальности Только вызов функции. Работает только в сочетании с функцией Timeout. Если в тарифном плане определены разные интервалы тарификации по времени, то Timeout выставляется до конца ближайшего интервала. Например, если есть цены с 0 до 8 и с 8 до 24, то при авторизации в 7:00 Timeout будет выставлен максимум в 3600 секунд. Параметром функции может быть либо ALL — функция применяется для всех тарифных планов, либо строка тегов вида [+/-TMID], что означает, что тот или иной тарифный план надо или включить или выключить из рассмотрения при работе функции. Например, [+1][+3] означает, что функция применяется только для тарифных планов 1 и 3, а [-1][-3] означает, что функция применяется для всех тарифных планов, кроме 1 и 3.

Блокировать переход сессии через месяц/день

Функция задает максимальное время длительности сессии (в секундах) после перехода через порог месяца. Если в аргументе указать суффикс /DAY, блокировка будет срабатывать каждые сутки, а не только при переходе через месяц. Например, аргумент 3600/DAY будет вызывать разрыв сессии каждые сутки в интервале от 00:00 до 01:00.

Значение свойства подключения

Только вызов функции

Блокировка суммы

Функция блокирует на лицевом счете клиента в центре авторизации сумму (без налогов) в валюте лицевого счета клиента. Сумма изымается из значения атрибута, для которого определена функция. Если баланс лицевого счета недостаточен для блокировки суммы, то происходит посылка сигнала Access-Reject.

Блокировать сумму по потреблению

При поступлении запроса из значения атрибута извлекается требуемое потребление (число) и блокируется сумма потребления согласно цене, определенной по маске статистики. В качестве параметров используется строка вида: <Маска статистики>;<Потребление по умолчанию>. Используется с любым атрибутом. Если атрибута в запросе нет, то в качестве потребления принимается значение по умолчанию. Если средств недостаточно, возникает ошибка 103.

Включение отладочной печати

Функция позволяет включить вывод отладочной информации выборочно для RADIUS-авторизаций.

Пример условия в поле Условие выполнения:

Результаты трассировки можно увидеть в журнале системных сообщений.

Для отладки авторизаций, вызванных через интерфейс (раздел Администратор | Система авторизации | RADIUS-авторизация) н а целевом AP (раздел Администратор | Система авторизации | Центры авторизации | Управление dest, вкладка Системные параметры) потребуется назначить системному параметру DEBUG.TRACE_AUTHINFO_BY_STR значение 5. Чтобы выключить — значение 0.

Обратите внимание! Старайтесь не использовать пустые условия или условия вроде 1=1, т. к. в таком случае отладка будет работать для всех RADIUS-запросов, проходящих через сервис сети, что может привезти к лишним нагрузкам и переполнению debug_log, а в месте с ним и дискового пространства.

Включение отладочной печати не зависит от значения параметра уровня отладки.

Выдать атрибуты по условию/маске

Функция содержит три параметра: condition:mask1:mask2. Если условие condition выполняется, функция выбирает из подключения атрибуты, соответствующие mask1, и выдает их в ответ; если условие не выполняется — выбирает из подключения атрибуты, соответствующие mask2, и выдает их в ответ. Примечание. Если условие пустое, считается, что оно выполняется всегда.

В масках в качестве замены любой подстроки может использоваться символ *. Если строка параметров пустая, считается, что условие выполнено и mask1=* (т. е. будут выданы все доступные атрибуты). Если маска имеет вид ?#[string], то под эту маску попадают все атрибуты, содержащие подстроку ?#[string], и при выдаче таких атрибутов эта подстрока удаляется.

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

Функция выдачи IP-адреса. Используется с атрибутом Framed-IP-Address. Система первоначально выдает IP-адрес из блока, определенного для центра авторизации. Если на клиентском подключении есть заполненное свойство с RADIUS-атрибутом Framed-IP-Address и в уникальности AV-пары задано Замещение или Замещение (всегда), то IP-адрес выдается из клиентского подключения. Используется для выдачи статического или динамического IP-адреса.

Значение свойства подключения

Вызывающий номер

Функция используется для проверки правильности разрешенных А-номеров. На клиентском подключении должно быть свойство (можно использовать множественность) со списком разрешенных номеров и RADIUS-атрибутом Calling-Station-Id. Аналогичным образом можно проверять на корректность и значение других атрибутов, например, NAS-Port-Type.

Значение свойства подключения

1234567 80951234567 70951234567

Только вызов функции

Дисциплина блокировки

Параметр ALL блокирует учетное имя после авторизации. Функция используется для мультисервисных карт: при использовании одного сервиса, запрос на авторизацию другого сервиса не проходит. Разблокирование сервиса происходит после завершения сессии.

Значение свойства подключения

Только вызов функции

Замена значения при исчерпании квоты

Функции возвращает значение в атрибуте, для которого она определена. Если квота тарифного плана еще не исчерпана, то возвращается значение свойства из подключения, соответствующее атрибуту, а если ни одного значения свойства в подключении не определено, то возвращается значение DefaultBefore. Если квота тарифного плана исчерпана, то возвращаются значения ValueAfter1. ValueAfterN. Аргумент может принимать значение вида DefaultBefore;ValueAfter1;ValueAfter2;. ;ValueAfterN.

Замена идентификатора сессии

Функция предназначена для смены идентификатора сессии без остановки оборудования. Если просто заменить значение идентификатора сессии в определении сервиса сети, то при наличии RADIUS-пакетов Accounting-Update возможна двойная тарификация. У функции есть параметр — дата, начиная с которой у сессий будет новый ID, т. е. новый ID будет только у тех сессий, которые начались после указанной даты. Аргумент имеет формат: дата/ID, например, 06.06.2007 12:00/NAS-IP-Address:User-Name:Acct-Session-Id. Новый ID будет только у тех сессий, которые начались после указанной даты. После того, как все сессии со старым ID закончатся, новый можно указать в настройках сервиса сети, а эту AV-пару убрать.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *