RADIUS | Все про протокол RADIUS Accounting ExpertBilling

1.1. Общие сведения о AAA и RADIUS

AAA – сокращение от Authentication, Authorization and Accounting (Аутентификация, Авторизация, учёт) и используется при предоставлении доступа в сеть, к управлению оборудованием и управления этим доступом. RADIUS – это один из сетевых клиент-серверных протоколов, используемый для централизованного управления авторизацией, аутентификацией и учетов при запросе доступа пользователей к различным сетевым службам.

Клиент RADIUS обычно используется на сетевом устройстве для реализации AAA совместно с протоколом 802.1x. Сервер RADIUS хранит базу данных для AAA и связывается с клиентом RADIUS через протокол RADIUS, который является наиболее распространенным протоколом в рамках AAA.

1.2. Общие сведения о AAA и RADIUS

Протокол RADIUS использует UDP для транспорта. Формат заголовка пакета показан ниже.

Рисунок 57.1 – Формат пакета RADIUS

Code – тип пакета RADIUS, возможные значения для данного поля:

1 – Access-Request2 – Access-Accept3 – Access-Reject4 – Accounting-Request5 – Accounting-Response11 – Access-Challenge

Identifier – идентификатор для пакетов запроса и ответа.Length – длина всего пакета RADIUS.Authenticator – поле используется для проверки пакетов, полученных от RADIUS-сервера, или для передачи зашифрованных паролей.

Поле разделено на две части: аутентификатор запроса и аутентификатор ответа.Attribute – поле используется для передачи детальной информации о ААА. Значение поля формируется из значений полей Type, Length, и Value:

2. Конфигурация RADIUS

  1. Включить функцию аутентификации и учета;
  2. Настроить ключ сервера RADIUS;
  3. Настроить параметры RADIUS сервера;
  4. Настроить параметры сервиса RADIUS;
  5. Настроить адреса RADIUS NAS.
  1. Включить функцию аутентификации и учета:

2. Настроить ключ сервера RADIUS:

3. Настроить параметры RADIUS сервера:

4. Настроить параметры сервиса RADIUS:

5. Настроить адреса RADIUS NAS:

3. Пример конфигурации RADIUS

Рисунок 57.2 – Конфигурация RADIUS

ПК подключен к коммутатору, который имеет IP-адрес 10.0.0.2 и подключен к серверу аутентификации RADIUS. IP-адрес сервера 10.0.0.3, используемый порт для аутентификации по-умолчанию – 1812, для учета – 1812 . Доступ на коммутатор по telnet контролируется сервером аутентификации.

Конфигурация выглядит следующим образом:

4. Устранение проблем при конфигурации RADIUS

Убедитесь, что:

  • IP-связность коммутатора с сервером RADIUS присутствует;
  • ключ аутентификации на коммутаторе совпадает с ключом на RADIUS сервере;
  • подключение осуществляется к правильному RADIUS серверу.
  • Подробная отладочная информация может быть отображена после применения команды debug aaa.

Accounting

После ответа абонента Б, система отправляет Acct-Start Request с информацией о начале вызова и времени ответа на RADIUS сервер. Детально параметры запроса описаны в пункте Настройка динамических абонентов и системы Radius.В ответ RADIUS сервер может прислать максимальную продолжительность вызова (в секундах), запрет вызова (в этом случае система тут же отобьет вызов если он не разрешен в свойстве if_radius_unavaliable), таймаут посылки промежуточных Accounting сообщений Acct-Interim-Update.

Если абоненты А, Б воспользовались услугами ДВО, на RADIUS сервер посылаются Acct-Update Request с информацией об этом, в случае если параметр send_ss_notification = true

domain/<DOMAIN>/aaa/accounting/info send_ss_notification

По завершению вызова посылается сообщение Acct-Stop Request с информацией о абонентах А, Б, а так же о времени начала, ответа и завершения вызова.В случае, если ответа на вызов не было Acct-Stop Request посылается только в том случае, если параметр unsuccessful_call_info = true.

domain/<DOMAIN>/aaa/accounting/info unsuccessful_call_info

Radius | все про протокол radius accounting expertbilling

Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.

Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC».

Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами и серверами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй).

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

Операционные системы семейства Windows Server 2003 поддерживают протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности, создание более надежных начальных ключей шифрования данных для MPPE (Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена паролями, из протокола исключена поддержка старых методов обмена паролями MS-CHAP.

Поскольку версия MS-CHAP v2 обеспечивает более надежную защиту, чем MS-CHAP, при подключении сначала предлагается использовать именно ее (если она доступна), а затем уже MS-CHAP.

Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95, поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений удаленного доступа.

Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.

Похожее:  What is Bearer token and How it works? -

Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.


НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ

Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.

Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.

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

RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).

Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».


ПРИМЕНЕНИЕ RADIUS

Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.

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

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода – ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты сообщений запроса доступа.

Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь – сертификата сервера RADIUS.

Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.


РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ

Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.

При использовании EAP в процессе установления соединения в рамках РРРспециальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP». ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.

К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.

Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.

Radius маршрутизация

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

В этом случае на RADIUS сервер посылаются следующие параметры:

  • текущие номера А, Б и их признаки;
  • имя текущего контекста маршрутизации;
  • текущее значение параметра tag контекста маршрутизации;
  • имя домена;
  • имя входящего интерфейса;
  • номер попытки маршрутизации (начинается с 1, и в в случае перемаршрутизации увеличивается);
  • причина release-а предыдущего вызова по SIP, ISUP, ACP (в случае перемаршрутизации).
Похожее:  Как зарегистрироваться в личном кабинете налогоплательщика

В ответ RADIUS сервер может прислать команды на изменения номеров А, Б, их признаков, параметра tag

После маршрутизации, прежде чем отправить вызов на абонента Б, делается запрос в подсистему Authentication. На этом этапе проверяется, можно совершать вызов с номера А на номер Б, или нет.Если Authentication подсистема вернула accept — вызов отправляется на абонента Б.

domain/<DOMAIN>/aaa/general/info if_radius_unavaliable

В параметре if_radius_unavaliable перечислены направления, на которые необходимо отправлять вызов даже если RADIUS сервер недоступен, не пропускает вызов (Например вызовы на номера спецслужб).Access-Request сторону RADIUS содержит параметры, детально описанные в пункте Настройка динамических абонентов и системы Radius.

Добавление radius-серверов

Начиная с версии 3.5.0 RAIDUS-сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме авторизации.

Команды по настройки RADIUS серверов детально описаны в разделе Команды настройки параметров соединения c RADIUS-сервером.

Конфигурирование подсистемы aaa

Конфигурирование подсистемы AAA состоит из трех этапов:

  1. Задание параметров подключения в RADIUS серверу(ам)
    Детально команды по управлению RADIUS серверами описаны в пункте Команды настройки параметров соединения с RADIUS-сервером.
  2. Конфигурирование подсистемы Authorization (access запросы)
    Детально команды по управлению службой Authorization описаны в пункте Команды управления службой RADIUS AAA (Authorization).
  3. Конфигурирование подсистемы Accounting (accounting запросы)
    Детально команды по управлению службой Accounting описаны Команды управления службой RADIUS AAA (Accounting).

Настройка группы динамических абонентов

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

Настройка динамических абонентов (уровень sip-адаптера)

В системе поддерживается возможность дайджест-аутентификации и авторизации абонентов с использованием RADIUS-сервера. Для этого необходимо создать динамических абонентов. Система не хранит данные о динамических абонентах. Номер абонента и его пароль для аутентификации хранятся на RADIUS-сервере. В системе ECSS-10 необходимо только указать количество динамических абонентов и параметры доступа к RADIUS-серверу.

Авторизация осуществляется при регистрации абонента (запрос REGISTER) и определяет, существует ли абонент в системе. Дополнительно авторизация осуществляется при совершении вызова абонентом (запрос INVITE) и определяет, разрешено ли абоненту пользоваться ресурсом. Все запросы (регистрация, установление соединений) обязательно проходят процедуру аутентификации.

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

Комплекс ECSS-10 поддерживает три варианта дайджест-аутентификации на RADIUS-сервере:

  • RFC — согласно полной рекомендации RFC5090 (обновленная версия стандарта, RFC4590 — устаревшая версия). Формирование базы запроса аутентификации (nonce и другие) выполняется сервером RADIUS (challenge запрос);
  • RFC-no-challenge — согласно RFC5090, но без “challenge” запроса на сервере. База запроса аутентификации (nonce и другие) формируется адаптером и затем передается на сервер RADIUS вместе с ответом клиента;
  • Draft-sterman — работа по черновику RFC “draft-sterman”. Аналогично предыдущему варианту не выполняется “challenge” запроса на сервер, при отправке запроса на сервер RADIUS используется другая кодировка команд. В частности, такой вариант аутентификации поддерживают сервера FreeRadius, NetUp).

Порядок настройки динамических абонентов:

  1. Добавить в систему информацию о RADIUS-серверах.
  2. Создать группы с определенным количеством динамических абонентов.
  3. Назначить группе абонентов список RADIUS-серверов, с которыми они будут взаимодействовать, и настроить параметры группы.

Настройка индикаторов сети на интерфейсах системы на уровне администратора ватс

Для настройки индикаторов сети на интерфейс системы используется следующая команда:

/domain/<DOMAIN>/alias/set-for-iface <GROUP_NAME> <INTERFACE> ni <VALUE>

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

/domain/<DOMAIN>/alias/set-for-domain ni <VALUE>

где

Настройка локального адреса

Для настройки локального адреса RADIUS-клиента используется команда: 

/domain/<DOMAIN>/voip/aaa/accounting/set my_address <ADDRESS>

где

Настройка работы с radius c помощью web-конфигуратора

Работа с RADIUS настраивается также через расширенный web-конфигуратор в приложении Домены (Domains) → Свойства → RADIUS

Настройка серверов авторизации

RAIDUS сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме аккаунтинга.

Команды по настройки RADIUS серверов детально описаны в секции Команды настройки параметров соединения c RADIUS-сервером

Далее нужно назначить RADIUS сервера для авторизации командой:

/domain/<DOMAIN>/aaa/access/set servers add <ID>

где

Затем назначить имя пользователя и пароль, с которыми будут авторизоваться все вызовы данной виртуальной АТС:

/domain/<DOMAIN>/aaa/access/set login <login>/domain/<DOMAIN>/aaa/access/set password <password>

Для запуска RADIUS-клиента (включения взаимодействия с RADIUS-сервером авторизации) используется команда:

/domain/<DOMAIN>/aaa/access/set enable true

Если необходимо отключить RADIUS-клиента нужно установить значение “false” в команде.

Для просмотра данных о настройках подсистемы аккаунтинга используется команда:

/domain/<DOMAIN>/aaa/access/info

где

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

RAIDUS сервера создаются для каждой виртуальной АТС отдельно, и затем могут быть использованы в подсистеме аккаунтинга.

Команды по настройки RADIUS серверов детально описаны в секции Команды настройки параметров соединения c RADIUS-сервером

Далее нужно назначить RADIUS-сервер для версии аккаунтинга командой:

/domain/<DOMAIN>/aaa/accounting/set servers add <ID>

где

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

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

/domain/<DOMAIN>/aaa/general/set if_radius_unavaliable [NI1] … [NI6]

где

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

/domain/<DOMAIN>/aaa/accounting/set unsuccessful_call_info true

При этом в атрибутах cisco_vsa будет передаваться причина “неуспешного” вызова. Если необходимо отключить передачу на сервер аккаунтинга информации о “неуспешных” вызовах, то нужно установить значение “false”.

Следующая команда позволяет настроить профиль взаимодействия с системой учета, но в текущей версии программного обеспечения его устанавливать не требуется, поскольку в системе поддержан всего один профиль — CISCO_VSA. Профиль “default” соответствует CISCO_VSA.

/domain/<DOMAIN>/aaa/general/set profile <cisco_vsa|default>

Для возможности передачи промежуточных сообщений аккаунтинга необходимо настроить “интервал передачи промежуточных сообщений аккаунтинга”. Для этого воспользуйтесь командой:

/domain/<DOMAIN>/aaa/accounting/set interim_interval <value|disable|server_configured>

где

  • value — значение интервала в диапазоне от 60 до 86400 секунд;
  • disable — не передавать промежуточные сообщения аккаунтинга;
  • server_configured — использовать в качестве значения интервала значение, принятое от сервера авторизации в ответе access-accept.

Для запуска RADIUS-клиента (включения взаимодействия с RADIUS-сервером аккаунтинга) используется команда:

/domain/<DOMAIN>/aaa/accounting/set enable true

Если необходимо отключить RADIUS-клиента нужно установить значение “false” в команде.

Для просмотра данных о настройках подсистемы аккаунтинга используется команда:

/domain/<DOMAIN>/aaa/accounting/info

где

Параметры передающиеся на radius сервер

В таблице ниже представлены все параметры передающиеся на Radius сервер при запросах на номер динамического абонента. Если данные верны, Radius сервер возвращает access на запроса и обработка интерфейса продолжается как с локальным абонентом SSW.

Таблица 1 — параметры запроса на Radius сервер

Более подробно команды для работы с динамическими абонентами описаны в справочнике CLI, раздел Команды управления динамически конфигурируемыми интерфейсами

Понятия, определения

В системе поддерживаются три независимых режима работы с сервером RADIUS:

  1. Работа с сервером авторизации. Данный режим реализован для аутентификации и авторизации динамических абонентов, все аутентификационные данные в этом случае хранятся на RADIUS-сервере.
  2. Работа с сервером учета стоимости. В этом случае для всех вызовов, совершенных через виртуальную АТС, будут отправляться запросы аккаунтинга (accounting-request) на RADIUS-сервер;
  3. Внешняя маршрутизация посредством RADIUS-сервера.

Подсистема AAA позволяет проверять права на совершение вызовов абонентом, слежение за потреблением ресурсов абонентом.

Похожее:  Как пройти полную регистрацию на сайте Госуслуги

Пример команд cocon-а по конфигурированию подсистемы aaa

После этого при вызовах будут идти запросы на система AAA.

Работа с сервером авторизации

Если нужно авторизовать все совершаемые через виртуальную АТС вызовы, то настраивается взаимодействие с RADIUS-сервером авторизации.

Работа с сервером аккаунтинга

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

Система ESCC-10 в рамках виртуальной АТС поддерживает взаимодействие с несколькими серверами аккаунтинга. Если в течение определенного времени система не получает ответа от сервера, то выполняется повторная попытка отправки запроса на сервер. По истечении заданного числа попыток сервер считается неактивным. Запрос перенаправляется на другой сервер, если он указан, иначе детектируется сбой сервера.

При сбое сервера возможно установление ограничений на исходящую связь:

  • разрешать все вызовы;
  • разрешать вызовы только на локальные сети, междугородные сети, международные сети, спецслужбы, местные или зоновые сети (одновременно можно настроить любую комбинацию);
  • запрещать все вызовы.

Данное ограничение определяет возможность маршрутизации вызова на определенные интерфейсы системы, в настройках которых устанавливается соответствующее значение параметра признака номера. NumberIndicator — признак номера, принимает значения:

  • private — частная сеть;
  • local — местная сеть;
  • zone — зоновая сеть;
  • intercity — междугородная сеть;
  • international — международная сеть;
  • emergency — спецслужбы.

Порядок настройки:

  1. Настроить локальный адрес, на котором будет работать RADIUS-клиент.
  2. Настроить сервера аккаунтинга.
  3. При необходимости настроить индикаторы сети на интерфейсах системы.

Формат пакетов radius и значение атрибутов cisco vsa

В системе поддержаны два независимых режима работы с сервером RADIUS:

  1. Работа с сервером авторизации. Данный режим реализован для аутентификации и авторизации динамических абонентов, все аутентификационные данные в этом случае хранятся на RADIUS-сервере. Используется пакет Аccess-Request.
  2. Работа с сервером учета (аккаунтинга). В этом случае для всех вызовов, совершенных через виртуальную АТС, будут отправляться запросы аккаунтинга (Accounting-Request) на RADIUS-сервер.

Описание каждого из режимов и процедуру настройки смотрите в Настройка динамических абонентов и системы Radius.

Описание каждого RADIUS-пакета состоит из описания всех пар Атрибут-Значение (Attribute-Value Pair) для этого типа пакета. Атрибуты могут быть как стандартными, так и специфичными атрибутами вендоров (Vendor-Specific Attribute). Если значение атрибута неизвестно (например, при отсутствии исходящего транка невозможно определить значение переменной CdPN_OUT, которое используется в качестве значения некоторых атрибутов), то этот атрибут не добавляется в сообщение.

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

Имя атрибута(Номер атрибута): Значение атрибута

Для специфичных атрибутов вендоров описание имеет вид:

Имя атрибута(Номер атрибута): Имя вендора(Номер вендора): Имя VSA: Значение VSA

где:

В качестве значения атрибута может использоваться конструкция вида <$NAME>, где NAME – это имя переменной. Описание значения переменных приведено ниже.

Пакет Аccess-Request:

В ответ на данное сообщение ожидается одно из следующих сообщений: Access-Reject — в случае, если не было дано разрешение на выполнение вызова; Access-Accept — в случае, если разрешение на выполнение вызова было получено. В сообщение Access-Accept могут присутствовать следующие атрибуты:

Стартовый пакет Accounting-Request (Start):

В ответ на данное сообщение ожидается сообщение Accounting-Response, в котором может присутствовать следующий атрибут:

Промежуточный пакет Interim Accounting Request (Update):

В ответ на данное сообщение ожидается сообщение Accounting-Response, в котором может присутствовать следующий атрибут:

Завершающий пакет Accounting-Request (Stop):

Таблица 2 — Описание переменных

ПеременнаяОписание и возможные значения
$CdPN_INномер вызываемого абонента до преобразования (принятого из интерфейса)
$CdPN_OUTномер вызывающего абонента после преобразования (переданного в интерфейс)
$CgPN_INномер вызывающего абонента до преобразования (принятого из интерфейса)
$CgPN_OUTномер вызывающего абонента после преобразования (переданного в интерфейс)
$LOCAL_DISCONNECT_CAUSEпричина завершения вызова в формате системы ECSS-10, описание значений приведено в следующей таблице
$DISCONNECT_CAUSEпричина завершения вызова согласно рекомендации Q.850
$CALL_TYPEтип вызова, всегда “Telephony”
$CALL_IDидентификатор вызова
$SSW_IPIP-адрес интерфейса системы ECSS-10, аутентифицирующего пользователя
$SSW_PORTтранспортный порт интерфейса системы ECSS-10, аутентифицирующего пользователя
$ROUTE_RETRIESтекущий номер попытки, отсчёт начинается с 1 (для первой попытки, соответственно)
$SESSION_IDидентификатор сессии
$INTERIM_SESSION_TIMEвремя разговора к моменту отправки промежуточного сообщения
$SESSION_TIMEвремя продолжительности разговора
$TIME_SETUPвремя поступления инициирующего запроса во входящий интерфейс в формате hh:mm:ss.uuu t www MMM dd yyyy
$TIME_CONNECTвремя ответа вызываемой стороны в формате hh:mm:ss.uuu t www MMM dd yyyy
$TIME_DISCONNECTвремя отбоя вызова одной из сторон в формате hh:mm:ss.uuu t www MMM dd yyyy
$DOMAINимя виртуальной АТС
$Authуникальный идентификатор запроса
$InTrunkGroupимя входящей транковой группы
$OutTrunkGroupимя исходящей транковой группы
$InIfaceимя входящего интерфейса
$OutIfaceимя исходящего интерфейса
$INTERIM_INTERVALинтервал времени (в секундах), через который будут посылаться промежуточные Acct-Interim-Update сообщения. Значение должно быть не меньше 60. В случае, если на уровне домена задано свойство interim_interval (domain/DOMAIN_NAME/aaa/accounting/info), то значение $INTERIM_INTERVAL будет вычислено на основе его значения
$SESSION_TIMEOUTвыделенное время на разговор (в секундах). В случае, если время равно 0 — то вызов запрещен. -1 — вызов не ограничен
$H323_CREDIT_TIMEвыделенное время на разговор (в секундах). В случае, если время равно 0 — то вызов запрещен. -1 — вызов не ограничен. В случае, если данный параметр пришел на Acct-Interim-Update запрос, то это время на оставшуюся часть разговора

Таблица 3 – Описание внутренних системных причин разъединения, которые могут передаваться в LOCAL_DISCONNECT_CAUSE

Внутренняя причинаЗначение причины согласно рекомендации Q.850Описание
normal16нормальное разъединение
originationDenied16абоненту запрещено совершать вызов, возможно административная блокировка
authorisationFailure50ошибка авторизации
aPtyAbandon16вызывающий абонент положил трубку до ответа
invalidCollectedInformation1номер набран неверно, не найден маршрут
collectInformationFailure1ошибка сбора цифр номера, может возникнуть, когда система ожидает дополнительных цифр номера, но они не поступают до истечения таймера
aPtyDisc16разъединение по инициативе вызывающего абонента
bPtyDisc16разъединение по инициативе вызываемого абонента
routeSelectFailure1ошибка установления соединения, обычно возникает, когда все каналы в исходящем интерфейсе заняты либо от интерфейса принята ошибка
oNoAnswer34внутренняя ошибка, возникает, когда таймер ожидания ответа в плече вызывающего абонента истек, а со стороны плеча вызываемого абонента не было ни ответа, ни сообщения отбоя
terminationDenied27вызов на вызываемого абонента запрещен, например абонент заблокирован
notReachable3вызываемый абонент недоступен, например не зарегистрирован или номер не существует
bPtyNoAnswer18вызываемый абонент не отвечает
bPtyBusyUDUB17отбой по инициативе вызываемого абонента до ответа
bPtyBusyNDUB17вызываемый абонент занят
ss7Failure38ошибка на сети ОКС7
calledPartyRejected21вызов к вызываемому абоненту запрещен, например анонимный вызов на абонента с активным сервисом ACB
tException41ошибка обслуживания вызова, возникает обычно в случае системных проблем
routeFailure12ошибка маршрутизации к вызываемому абоненту по причине занятости всех каналов в исходящем транке
routeFailure22ошибка маршрутизации к вызываемому абоненту по причине занятости всех каналов направления на каком-то транзитном участке сети
conversationTimeout31возникает, когда истек таймер, ограничивающий общую продолжительность разговора
systemFailure127внутренняя неустранимая ошибка, детальное описание ошибки доступно в системном журнале

Были добавлены RADIUS атрибуты вендора:

  • xpgk-original-called-number-in — Оригинальный номер вызываемого абонента до преобразования
  • xpgk-redirected-number-in — Номер абонента который совершил переадресацию до преобразования
  • xpgk-original-called-number-out — Оригинальный номер вызываемого абонента после преобразования
  • xpgk-redirected-number-out — Номер абонента который совершил переадресацию после преобразования

Этапы работы подсистемы ааа

Подсистема AAA подключается при обработки вызова на нижеперечисленных этапах (каждым из этапом может отсутствовать)

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

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

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

Adblock
detector