Краткое описание

• Как RADACCT работает с серверами доступа
• Как RADACCT работает с базой пользователей
• Как RADACCT работает со временем
• Что и как RADACCT записывает в log-файлы
• Как настроить сервер доступа для работы с RADACCT

Как RADACCT работает с серверами доступа

Взаимодействие сервера системы RADACCT с сетевыми серверами доступа (NAS) происходит по протоколу RADIUS Accounting (RFC 2139). Вместе с тем RADACCT не имеет никакого отношения к аутентификации и авторизации пользователей, которые в свою очередь исполняют RADIUS или TACACS сервера.

RADIUS-сервера бывают двух основных видов: первый - от Livingston (родоначальник вида), второй - от Merit (существенно более продвинутый). Тем не менее, то, что нас интересует, у них реализуется одинаково, в соответствии с RFC.

Любой RADIUS-сервер состоит из двух основных частей; одна отвечает за аутентификацию и авторизацию, вторая за аккаунтинг, причем эти части как бы независимы друг от друга, т.к. работают в разных UDP-портах. Отсюда и два RFC - первый - собственно сам RADIUS протокол (RFC 2138) и второй - Accounting (RFC 2139). Пользуясь этим, RADACCT замещает собой вторую часть RADIUS, при этом они могут работать как на одном компьютере, так и на разных. В качестве первой части может использоваться TACACS. Кроме того, Merit RADIUS способен форвардить весь поступающий от NAS аккаунтинг другому RADIUS-серверу, в качестве которого может выступать RADACCT-сервер. Таким образом, в сети может быть несколько серверов аутендификации и авторизации и один общий для всех сервер аккаунтинга.

Система RADACCT использует два файла конфигурации от RADIUS: файл clients со списком RADIUS-клиентов, которым обеспечивается аутентификация и аккаунтинг, и файл dictionary, являющийся словарем трансляции запросов и генерации ответов для атрибут/значение пар. Каталог, в котором находятся эти файлы конфигурации, задается в определении RADIUS_DIR при компиляции.

Файл clients требует некоторой дополнительной информации для сервера RADACCT, например, он может выгладеть следующим образом (для RADIUS v3.5.6):

...
# SNMP-Community-Name = AAAA
192.168.1.1 BBBB type=Cisco:NAS v1
# snmp-community-name: CCCC
192.168.1.2 DDDD type=Cisco:NAS v1
...

где ключевое слово SNMP-Community-Name (задаваемое в комментариях, чтобы не мешать RADIUS) определяет имя обьединения для взаимодействия с NAS по SNMP протоколу версии 1 (на запись!). Если у всех NAS из списка clients одинаковое имя обьединения, то это ключевое слово может быть задано один раз в самом начале списка.

Сервер RADACCT всегда пассивен, т. е. не инициирует никаких посылок и запросов (кроме SNMP TsClrLine - очистить линию NAS), он ожидает в порту radacct/udp поступления от серверов доступа RADIUS-пакетов с типом Accounting-Request, проверяет их допустимость, формирует либо высвобождает сессию в соответствии с атрибутами Acct-Status-Type и Acct-Session-Id и возвращает отправителю Accounting-Response, если в процессе обработки не возникло ошибок.

Следующие атрибуты пакета Accounting-Request считаются обязательными:

Acct-Status-Type - подтип пакета: Start, Stop или Alive;
NAS-IP-Address - IP-адрес NAS;
Acct-Session-Id - идентификатор сессии NAS;
User-Name - идентификатор пользователя (с возможным реалмом);
NAS-Port - номер порта NAS.

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

NAS-Port-Type - тип порта NAS, по умолчанию Async;
Service-Type - тип сервиса, по умолчанию Login;
Framed-Protocol - протокол, по умолчанию PPP (Service-Type=Framed);
Framed-IP-Address - IP-адрес клиента (Service-Type=Framed);
Login-IP-Host - IP-адрес сервера (Service-Type=Login);
Acct-Delay-Time - задержка в предоставлении сервиса;
Called-Station-Id - идентификатор вызываемой стороны (номер телефона?);
Calling-Station-Id - идентификатор вызывающей стороны (номер телефона?).

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

Acct-Session-Time - время занятия в текущей сессии;
Acct-Input-Octets - количество принятых байт;
Acct-Output-Octets - количество отосланных байт;
Acct-Input-Packets - количество принятых пакетов;
Acct-Output-Packets - количество отосланных пакетов.

Новую сессию создает Accounting-Request-пакет со статусом Start или Alive в случае, если он содержит Acct-Session-Id, отличный от уже зарегистрированных идентификаторов сессий (не закрытых сессий) на данном NAS или, если идентификатор совпадает, но не совпадает номер порта или идентификатор пользователя.

Сессия создается в любом случае, но непосредственно перед ее созданием сервер запрашивает NAS по SNMP очистить линию в случаях, если у входящего пользователя:

• недопустимый интервал времени;
• превышено максимальное количество одновременных входов;
• исчерпан остаток апдейтов времени;
• текущий остаток времени меньше нескольких десятков секунд.

В процессе сессии сервер также может запросить NAS по SNMP очистить линию в случаях, если у текущего пользователя:

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

Если в течение сессии NAS высылает периодические Accounting-Request-апдейты со статусом Alive, то сервер начинает отслеживать таймауты как самого NAS, так и каждой сессии в пределах данного NAS. В случае, если за три неполных периода апдейта в пределах сессии не поступило очередного, то сессия искусственно закрывается сервером, т. е. считается, что пользователь неучтенно освободил линию. В случае, если от NAS не поступает каких-либо пакетов в течение трех неполных периодов апдейта, то все сессии данного NAS искусственно закрываются сервером, т. е. считается, что связь с NAS прервалась по неизвестной причине и все пользователи рассоединились с данным NAS.

Сессия закрывается при поступлении Accounting-Request-пакета со статусом Stop и с соответствующим идентификатором либо если обнаруживается незакрытая сессия на данном порту NAS.

Как RADACCT работает с базой пользователей

База пользователей системы RADACCT представляет из себя систему каталогов и файлов в файловой системе Unix. Вся база располагается в одном корневом каталоге, заданном в определении RADACCT_DIR при компиляции; как правило, это каталог /var/radacct.

В корневом каталоге находится опциональный файл конфигурации сервера RADACCT radacctd.conf и следующие подкаталоги (создаваемые автоматически при их отсутствии):

• users/ - профайлы пользователей;
• groups/ - профайлы групп пользователей;
• wtmp/ - история работы пользователей;
• start/ - запускаемые при входе пользователей внешние программы;
• stop/ - запускаемые при выходе пользователей внешние программы.

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

В каталоге groups могут быть расположены файлы, именуемые в произвольной форме; их содержимое аналогично профайлу пользователя. Сервер не работает с этими файлами, однако на эти файлы удобно делать символьные линки из каталога users для пользователей, принадлежащих какой-либо группе из каталога groups и имеющие общие установки и переменные.

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

В каталог wtmp сервер записывает историю работы пользователей, где каждый файл соответствует имени или реалму пользователя. Эти файлы пишутся в формате, совместимом с форматом системного Unix wtmp-файла.

В каталогах start и stop могут содержаться запускаемые сервером внешние программы, соответственно при входе и выходе пользователя. Файл такой программы должен быть выполняемым файлом, имя которого соответствует имени пользователя, для которого он должен выполняться. При завершении start-задачи со значением, отличным от нуля, сервер посылает SNMP-запрос на NAS на очистку линии текущего пользователя. Если сессия пользователя оканчивается раньше завершения его start-задачи, то задача снимается сервером с помощью сигнала SIGTERM.

В файле конфигурации сервера radacctd.conf могут быть использованы следующие установки:

• ACCTMON= - список мониторов текущих соединений;
• REALM= - список сопоставления реалмов с профайлами.

В параметре ACCTMON могут быть перечислены сетевые адреса компьютеров, на которые следует высылать текущую информацию о сессиях пользователей. Адреса мониторов задаются в формате address[:port], номер UDP-порта по умолчанию равен 1647. Адреса могут перечисляться списком через пробельные символы или запятые, или могут задаваться многократным использованием параметра ACCTMON.

В параметре REALM могут быть перечислены маски, сопоставляющие вводимые пользователями реалмы с соответствующими профайлами. Сопоставления задаются в формате regex[file], где regex - это POSIX regex(3) (или GNU regexp(3)) выражение и file - это имя файла пользователя, куда отображается совпавший с этим выражением реалм. Если file не задан, то совпавший с маской реалм считается локальным и в качестве имени файла используется имя пользователя (реалм отсекается). Список сопоставлений задается многократным использованием параметра REALM, список проверяется сверху вниз до первого совпадения.

Если файл radacctd.conf отсутствует или введенный пользователем реалм не совпал ни с одной маской, то в качестве имени профайла используется имя реалма, как оно было введено пользователем.

Сервер перечитывает файлы конфигурации clients и radacctd.conf по сигналу SIGHUP. Сервер записывает текущую таблицу сессий в файл radacctd.save по сигналу SIGPIPE. Сервер завершает работу по сигналу SIGTERM.

Как RADACCT работает со временем

Как уже было сказано выше, основная функция системы RADACCT состоит в контроле используемого dialup IP-клиентами времени работы в Интернет. Система построена таким образом, что не позволяет клиенту вырабатывать времени больше, чем определено администратором.

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

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

Для динамического вычитания времени, контроля границ допустимого времени и некоторых других событий в сервер встроен обработчик прерываний по таймеру реального времени, вызываемый с периодичностью SYSTIMERATE, заданной в определении SYS_TIMERATE при компиляции сервера или в аргументе -s при каждом запуске, по умолчанию прерывание возникает каждые десять секунд. В каждом такте прерывания сервер обрабатывает массив счетчиков всех пользователей, находящихся на линии, вычитая из каждого счетчика величину TIMERATE.

Таким образом, значение TIMERATE определяет скорость убывания счетчика остатка времени пользователя. Наряду со значением TIMELEFT, величина TIMERATE у каждого пользователя также индивидуальна. Например, когда SYSTIMERATE равен 10 секундам, а TIMERATE содержит 20, то остаток времени в TIMELEFT уменьшается в два раза быстрее, если же в TIMERATEзадано 5, то в два раза медленнее реального времени.

Значение TIMERATE может быть задано в соответствующем параметре профайла пользователя или динамически изменяться по время работы сервера с помощью специальной утилиты radacct. По умолчанию величина TIMERATE равна величине SYSTIMERATE.

Точность вычисления остатка времени пользователя определяется величиной интервала прерываний таймера (SYSTIMERATE). Диапазон допустимых значений TIMERATE от 5 до 30 секунд.

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

Такой режим работы выбирается с помощью определения в профайле пользователя интервала апдейта времени в параметре UPDATERATE, его величина может варьироваться от 1 до 90 дней. Необходимо также указать стартовое количество оставшихся апдейтов в переменной UPDATELEFT, при каждом апдейте значение этой переменной декрементируется сервером, время перестает выделяться, когда значение достигло нуля. Если стартовое значение UPDATELEFT отрицательно, то апдейты времени будут происходить бесконечно, тем не менее, они будут фиксироваться как рост отрицательного значения. В этом режиме сервер использует две дополнительные переменные профайла - SAVETIMELEFT и LASTUPDATE, изменять их значения вручную не рекомендуется.

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

Допустимый суточный интервал времени работы пользователя задается в его профайле в параметре ACCESSTIME, который имеет формат hh:mm-hh:mm, где hh - это часы в диапазоне от 00 до 23 и mm - минуты от 00 до 59.

Что и как RADACCT записывает в лог файлы

Для нормального функционирования системы RADACCT не требуется наличия каких-либо промежуточных или log-файлов. В процессе работы сервер RADACCT может порождать следующую отчетность:

• диагностика работы сервера;
• история работы пользователей;
• текущий список пользователей находящихся на линии (опционально);
• log-файл аккаунтинга RADIUS-стиля (опционально);
• log-файл аккаунтинга стиля TACACS+ (опционально).

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

Сервер сохраняет всю историю работы пользователей в файлах подкаталога wtmp своего корневого каталога. Эти файлы могут именоваться по именам пользователей или по используемым реалмам точно так, как именуются соответствующие профайлы пользователей. Файлы имеют формат системного wtmp-файла, поэтому для просмотра содержимого можно использовать штатные системные утилиты, такие как last или ac. Тем не менее, для получения подробных статистических отсчетов рекомендуется использование специальной утилиты radstat, позволяющей получать из файла истории дополнительно еще несколько интересных записей.

Записывая файл в формате wtmp (или utmp), сервер формирует название терминальной линии в следующем формате: XXXXYYY, где XXXX - это два младших байта IP-адреса сервера доступа в шестнадцатеричном представлении и YYY - номер линии сервера доступа в десятичном представлении.

Сервер работает с системным файлом utmp точно так, как это делают программы login и init, так что будет казаться, что пользователь действительно присутствует в Unix-системе, но не имеет ни одного связанного с ним процесса. Сервер должен быть скомпилирован с опцией USE_UTMP, чтобы опеспечивать такую возможность.

Все терминальные линии, информацию с которых предполагается записывать в системный utmp-файл, необходимо предварительно описать в файле /etc/ttys системы, например, в таком виде:

...
4867000 none virtual
4867001 none virtual
4867002 none virtual
...

Имена линий должны быть указаны в RADACCT-формате (см. выше), тип всех линий должен быть virtual.

Некоторые программы, работающие с файлом utmp (например, команда w), требуют наличия соответствующего названию линии файла-устройства в каталоге /dev. Поэтому следует заранее создать все необходимые девайсы с именами как указано в /etc/ttys и с параметрами устройства /dev/null, например, с помощью команды mknod /dev/4867001 c 2 2.

Дополнительно к этому сервер RADACCT поддерживает логирование аккаунтинга в стиле систем авторизации RADIUS и TACACS+. Эти возможности могут быть включены использованием соответствующих опций при запуске сервера.

Как настроить сервер доступа для работы с RADACCT

Использование системы RADACCT< предъявляет единственное требование к серверу доступа (NAS) - он должен поддерживать протокол RADIUS Accounting в соответствии с RFC 2139.

Пример конфигурации Cisco NAS (приведен только аккаунтинг):

aaa new-model
...
aaa accounting network start-stop radius
aaa accounting connection start-stop radius
aaa accounting update periodic 1
...
ip radius source-interface Ethernet0
...
snmp-server community AAAA RW 50
...
radius-server host 192.168.1.1 acct-port 1646
radius-server key BBBB

где AAAA и BBBB соответственно имя SNMP community и секретный ключ RADIUS (смотри пример настройки файла clients).

Использование aaa accounting update periodic не обязательно, его наличие позволяет серверу RADACCT корректно отрабатывать ситуации потери связи с NAS, однако при очень большом количестве входных линий это может существенно повысить нагрузку на RADACCT. В таких случаях, возможно, более рационально использовать больший интервал времени апдейтов (в примере одна минута) или ограничиться только установкой aaa accounting update newinfo.

Если что-то не сработало, пишите на radacct@rinet.nsk.su.