• Главная
  • Карта сайта
Не найдено

Сервер AIX RADIUS: Частина 1. Протоколи аутентифікації і реєстрації подій

  1. Серія контенту:
  2. Цей контент є частиною серії: Сервер AIX RADIUS
  3. Малюнок 1. Огляд процесів сервера RADIUS
  4. процес моніторингу
  5. Малюнок 2. Процеси служби аутентифікації
  6. процес аутентифікації
  7. порядок аутентифікації
  8. Опис пакета аутентифікації
  9. Опис заголовка пакета аутентифікації
  10. Опис пар ім'я / значення пакету аутентифікації
  11. Процес реєстрації повідомлень
  12. Сценарій початку реєстрації повідомлень
  13. Детальний опис параметра Acct-Delay-Time
  14. Опис Accounting Start-пакета
  15. Тема Accounting Start-пакета
  16. Опис пар ім'я / значени Accounting Start-пакета
  17. Сценарій зупинки реєстрації повідомлень
  18. Опис Stop Accounting-пакета
  19. Опис пар ім'я / значення Accounting Stop-пакета
  20. Ресурси для скачування

Сервер AIX RADIUS

Серія контенту:

Цей контент є частиною # з серії # статей: Сервер AIX RADIUS

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Сервер AIX RADIUS

Слідкуйте за виходом нових статей цієї серії.

Сервер AIX® Remote Authentication Dial-In User Service (RADIUS, служба віддаленої аутентифікації користувачів при коммутируемом підключенні) реалізує протоколи клієнт-сервер, певні комітетом Internet Engineering Task Force (IETF). Дані протоколи дозволяють віддаленим клієнтам отримувати доступ до центрального серверу для входу в мережу. Сам RADIUS описаний в стандартах RFC 2865 і RFC 2866. Сервер RADIUS виробляє аутентифікацію користувачів, авторизує їх запити до сервісів і записує облікові дані. Перша реалізація сервера RADIUS була включена в AIX 5L версії 5.3.0.10.

Звичайними клієнтами в RADIUS-середовищі є термінальний сервер, пристрій локальної мережі, що виконує аутентифікацію або бездротова точка доступу.

Сервер AIX RADIUS складається з трьох служб:

  1. Аутентифікація.
  2. Авторизація.
  3. Реєстрація подій (облік).

Ці три служби працюють разом з UNIX-аутентифікацією, локальною базою даних користувачів або каталогу, що використовує протокол Lightweight Directory Access Protocol (LDAP) для надання інформації про аутентифікації. Демон сервера аутентифікації RADIUS забезпечує безпеку і аутентифікацію користувачів для віддалених підключень до мережі. Також цей демон виконує функції авторизації, а саме визначає, які служби доступні для використання і (в деяких конфігураціях) як виконується мережевий доступ. Демон сервера реєстрації подій RADIUS відстежує, коли і як довго віддалені з'єднання підключені до мережі, як показано на малюнку 1 .

Малюнок 1. Огляд процесів сервера RADIUS
Сервер AIX RADIUS   Серія контенту:   Цей контент є частиною # з серії # статей: Сервер AIX RADIUS   https://www

Основні процеси сервера AIX RADIUS:

  • моніторинг;
  • аутентифікація;
  • реєстрація подій.

Основні означає, що при нормальному функціонуванні сервера RADIUS ці демони завжди завантажені. Процеси виконуються під чинним ідентифікатором користувача "radiusd" і не мають постійних повноважень користувача root. Зупинити і запустити процеси можна за допомогою основних команд SRC:

  • startsrc -s radiusd
  • stopsrc -s radiusd

Подивитися, чи завантажені процеси, можна за допомогою команд ps -ef | grep radiusd.

процес моніторингу

Процес моніторингу - це керуючий процес, який запускає або перезапускає всі інші процеси, асоційовані з RADIUS-сервером. При запуску процес моніторингу читає і обробляє всі конфігураційні файли (наприклад, radiusd.conf, client, proxy, dictionary, default.policy). Для реєстрації інформації процес ініціює зв'язок з демоном syslog. Служби в сервері RADIUS - це процеси, які забезпечують мережеві сервіси. Сервер RADIUS може запускати і керувати за допомогою двох служб:

  • аутентифікація RADIUS;
  • реєстрація подій RADIUS-сервером.

Процес моніторингу може запустити від 1 до N примірників кожної служби. Кожен екземпляр служби прослуховує унікальний мережевий порт. За замовчуванням для аутентифікації використовується порт 1812. Порт для обліку - 1813. Визначити додаткові порти можна в головному файлі конфігурації RADIUS - radiusd.conf. Кожен порт, зазначений у файлі radiusd.conf, запускає сервіс, який прослуховує цей порт.

Примірники служб можуть бути однакового або різного типів. Наприклад, процес моніторингу може запустити три екземпляри служби аутентифікації і два примірника служби реєстрації подій.

Запам'ятайте, що всі екземпляри служб повинні працювати на різних портах. Як показано на малюнку 2 , Сервер аутентифікації може мати три виконуються примірника на портах 1812, 6666, і 7779. Конфігураційний файл radiusd.conf містить опису номерів портів.

Малюнок 2. Процеси служби аутентифікації

Після того як всі служби були запущені, процес моніторингу спостерігає за процесами запущених служб. Якщо процес служби аварійно завершив свою роботу, процес моніторингу зареєструє цю подію і перезапустить службу.

Примітка. При частому оновленні сервера RADIUS можливе зменшення числа служб.

процес аутентифікації

Основним призначенням процесу аутентифікації є відповідь на запит доступу від термінальних серверів, аутентифицирующей пристроїв локальної мережі або бездротових точок доступу. Відповідь процесу аутентифікації може бути наступний:

  • надати доступ;
  • відмовити в доступі;
  • відмовити в доступі і зажадати додаткової інформації;
  • перевірити політику авторизації;
  • передати інформацію про авторизацію.

Термінальні сервери управляють і виступають в якості проксі для пристроїв віддаленого доступу, наприклад, модемів до мережі. Якщо процес аутентифікації дозволяє, то віддалений пристрій стає частиною вже існуючої мережі. Якщо в доступі відмовлено, то віддалений пристрій може спробувати заново пройти аутентифікацію або просто відключитися. Наступний порядок аутентифікації описує рух пакетів в разі успішної аутентифікації через модемне з'єднання. Термінальний сервер налаштований так, що після проходження аутентифікації він буде відсилати облікову інформацію, яка необхідна для підрахунку часу, проведеного користувачем в мережі.

порядок аутентифікації

Малюнок 3. Дистанційна аутентифікація RADIUS: приклад для модему

Модем отримує запит (див. Пункт 1 на малюнку 3 ) І сповіщає про це термінальний сервер. Термінальний сервер запитує у абонента ім'я користувача і пароль. Коли термінальний сервер приймає ім'я користувача і пароль, він збирає аутентифицирующей UDP-пакет (UDP Authentication packet, більш детальна інформація в розділі аутентифицирующей пакет ). Термінальний сервер є клієнтом RADIUS-сервера. Аутентифицирующей пакет (Access-Request, запит доступу) містить ім'я користувача, прихований пароль і іншу інформацію, яка описує модемне з'єднання і термінальний сервер, який відправив цей пакет.

Потім аутентифицирующей пакет (Authentication packet) відсилається процесу аутентифікації RADIUS-сервера (див. Пункт 2 на малюнку 3 ), І термінальний сервер очікує відповіді. У разі, якщо протягом заздалегідь визначеного проміжку часу (наприклад, три секунди) процес аутентифікації не відповідає, термінальний сервер повторно надсилає аутентифицирующей пакет. Термінальний сервер буде пересилати аутентифицирующей пакет до тих пір, поки не отримає пакет, що підтверджує прийняття даних (відхилення запиту, запит додаткової інформації або підтвердження запиту), або до тих пір, поки не вичерпає кількість можливих спроб (наприклад, 23). У цей момент він перестане посилати запити аутентифікації і скине виклик, або спробує передати запити аутентифікації іншому процесу аутентифікації, якщо такий визначено.

Коли процес аутентифікації приймає запит на аутентифікацію, він робить запит до користувальницької базі даних. Залежно від того як системний адміністратор налаштував RADIUS-сервер, можливі три варіанти розміщення призначеної для користувача бази даних: база даних користувачів в локальній UNIX-системі, певна для RADIUS локальна база даних або каталог LDAP (див. Пункт 3 на малюнку 3 ). Отже, процес витягує інформацію про користувача, що запрошує аутентифікацію. Для успішної аутентифікації необхідно виконання наступних трьох умов:

  1. Призначений для користувача ідентифікатор повинен бути присутнім в базі даних.
  2. Пароль в аутентифицирующей пакеті повинен відповідати паролю, знайденому в базі даних або LDAP-каталозі.
  3. Повинна бути перевірена політика авторизації. Ця політика є опцією, тому її потрібно конфігурувати. Якщо політика налаштована, пара ім'я / значення (attribute-value) з пакету повинна відповідати значенням з бази даних.

Коли всі дії по аутентифікації успішно завершаться, термінального сервера повертається пакет дозволу (Acceptance packet, Аccess-Accept). Залежно від конфігурації модему може бути присвоєно IP-адресу і надано доступ в приватну мережу (див. Пункт 4 на малюнку 3 ).

Якщо аутентифікація була пройдена, термінального сервера (див. Пункт 4 на малюнку 3 ) Надсилається повідомлення про відмову в доступі (Access-Reject); в свою чергу термінальний сервер повідомляє про те, що не вдалося провести аутентифікацію користувача. Далі клієнт може відмовитися або повторити спроби аутентифікації, або спробувати аутентифицироваться під новим ім'ям користувача і паролем.

Опис пакета аутентифікації

Нижче представлений приклад пакету аутентифікації, який був отриманий процесом аутентифікації. Ці дані записуються в syslog, на 9-му рівні налагодження. Інформація представлена ​​в шістнадцятковому і текстовому форматі.

Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Incoming Packet: Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Code = 1, Id = 253, Length = 90 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 1, Length = 8, Value = 0x67656E747937 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 2, Length = 18 , Value = 0x ******************************** Sep 20 10:03:18 server1 radiusd [1773678]: [ 2]: Type = 4, Length = 6, Value = 0x0A0A0A09 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 5, Length = 6, Value = 0x00000002 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 6, Length = 6, Value = 0x00000001 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 7, Length = 6, Value = 0x00000001 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 30, Length = 10, Value = 0x3132332D34353637 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Type = 31, Length = 10 , Value = 0x3736352D34333231 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Starting parse_packet () Sep 20 10:03:18 server1 radiusd [177 3678]: [2]: Code 1, ID = 253, Port = 44224 Host = 10.10.10.9 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: User-Name = "user_id" Sep 20 10: 3:18 server1 radiusd [1773678]: [2]: NAS-IP-Address = 10.10.10.9 Sep 20 10:03:18 server1 radiusd [1773678]: [2]: NAS-Port = 2 Sep 20 10:03: 18 server1 radiusd [1773678]: [2]: Service-Type = Login-User Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Framed-Protocol = PPP Sep 20 10:03:18 server1 radiusd [ 1773678]: [2]: Called-Station-Id = "123-4567" Sep 20 10:03:18 server1 radiusd [1773678]: [2]: Calling-Station-Id = "765-4321" Sep 20 10: 3:18 server1 radiusd [1773678]: [2]: Leaving parse_packet ()

Інформація з аутентифицирующей пакета, запит доступу, як видно з налагоджувальної інформації RADIUS-сервера, складається з наступних частин:

Sep 20 10:03:18 server1 radiusd [1773678]

Основна інформація syslog: день, час, ім'я сервера і ідентифікатор radius-процесу. [2] Номер пакета з моменту запуску демона. Incoming packet: Повідомлення, яке означає початок обробки пакета. Code = 1, Id = 253, Length = 90 Код запиту доступу і довжина пакета. Type = 1, Length = 8, Value = 0x67656E747937 Запускає обробку пар ім'я / значення, представлених в 16-й системі числення. Цей приклад містить 8 пар ім'я / значення. Starting parse_packet () Запис повідомлення, яке означає початок обробки пакета - те ж саме повідомлення, що і в Incoming packet, тільки в текстовому зрозумілому людині форматі.

Зібрати інформацію, описану вище, можна тоді, коли сервер RADIUS працює в налагоджувальному режимі (рівень 9). Пари ім'я / значення є параметрами RADIUS- сервера, які були передані йому апаратним сервером доступу. Друга стаття цього циклу описує різні рівні налагодження.

Опис заголовка пакета аутентифікації
code

Тип RADIUS-пакета. Всі запити аутентифікації мають код "1". ID Порядковий номер пакета, який визначається термінальним сервером. Пакети, послані до поточного пакета, мають менші значення ідентифікатора (ID), в той час як пакети, надіслані після поточного пакета, мають великі значення ID. Як тільки ID досягає значення 256, то скидається в "1". Це може бути корисно при встановленні послідовності отримання пакетів. Крім того, коли ідентифікатори пакетів приходять не по порядку, це означає наявність затримки при передачі даних через мережу або інші проблеми. Length Довжина всього пакета в байтах. Host IP-адреса хоста, який відправив пакет, в шістнадцятковій системі числення. Кожна пара шістнадцяткових чисел означає одну з чотирьох частин IP-адреси.

Опис пар ім'я / значення пакету аутентифікації
Username

Type = 1 Ім'я користувача для мережевої аутентифікації. Password Type = 2 Прихований пароль користувача. NAS-IP-Address Type = 4 IP-адреса термінального сервера, що запитує аутентифікацію. NAS-Port Type = 5 S-port, до якого звертається користувач (наприклад, модем). Service-Type Type = 6 Тип служби, яку запитує користувач. Більшість користувачів можуть бути або Framed-Users, або мережевими користувачами. Framed-Protocol Type = 7 Атрибут Framed-Protocol дозволяє вказати протокол, який використовується для передачі даних між клієнтом і мережею. Дана пара ім'я / значення доступна тільки тоді, коли властивість User-Service-Type встановлено в Framed-Users. Called-Station-ID Type = 30 Номер телефону, у якого клієнт запитував доступ в мережу. Це поле заповнюється тільки в тому випадку, якщо необхідна інформація доступна термінального сервера. Calling-Station-ID Type = 31 Номер телефону, з якого клієнт запитував доступ в мережу. Це поле заповнюється тільки в тому випадку, якщо термінальний сервер володіє необхідною інформацією.

Процес реєстрації повідомлень

Призначенням процесу реєстрації повідомлень є запис інформації про роботу системи. Термінальний сервер може бути налаштований таким чином, щоб генерувати облікову інформацію RADIUS-сервера відразу після аутентифікації клієнта. Облікова інформація RADIUS-сервера складається з повідомлень двох типів, які генеруються термінальним сервером:

  1. Почати з'єднання (start accounting message, start-повідомлення).
  2. Припинити з'єднання (stop accounting message, stop-повідомлення).

Сценарій початку реєстрації повідомлень

Малюнок 4. Повідомлення RADIUS-сервера про початок обліку

Наступний приклад підходить для користувачів, визначених у LDAP-каталозі. Користувачі, певні в LDAP, мають особливість, яка дозволяє реєструвати інформацію про події всередині процесорів. Якщо користувач визначено в локальній базі даних або є UNIX-користувачем, "внутріпроцессная" інформація (або RADIUS Active objectclass) не оновлюється.

Визначення користувачів в LDAP дозволяє використовувати додаткову можливість: обмеження числа спроб входу в систему. Якщо LDAP-користувач створений з заданим параметром maximum allowed login times ( "максимально можливе число спроб входів в систему"), тоді по пакетам, повідомляти про початок і кінець обліку, можна визначити момент, коли користувач пройшов аутентифікацію. Якщо користувач вичерпав всі спроби входу в систему (maximum allowed login times), то він більше не зможе аутентифицироваться.

start-повідомлення ( "Start Accounting message") створюється в момент отримання термінальним сервером підтвердження про успішно пройденої аутентифікації (див. пункт 5 на малюнку 4 ). Після отримання підтвердження про аутентифікації термінальний сервер створює пакет Start Accounting (Почати з'єднання, start-пакет) (див. Розділ Опис Accounting Start пакета ). start-пакет містить параметр "Acct-Session-ID", значення якого ідентично значенням такого ж параметра в пакеті Stop Accounting (Закінчити з'єднання, Stop-пакет). Acct-Session-ID допомагає знаходити відповідні пари повідомлень Start Accounting і Stop Accounting, які були зареєстровані.

start-пакет містить інформацію про термінальному сервері і типі з'єднання. Також пакет містить дані про час, який минув з моменту отримання підтвердження про аутентифікації. Час початку з'єднання для користувача обчислюється таким чином: треба відняти Acct-Delay-Time з поточного часу системи (див. Розділ Детальний опис Acct-Delay-Time ).

Коли сервер реєстрації повідомлень RADIUS отримує повідомлення про реєстрацію подій (Accounting packet) (див. Пункти 6 та 7 на малюнку 4 ):

  1. Перевіряється LDAP-поле active objectclass на наявність користувача з заданими параметрами (наприклад, ім'я користувача і модифікатор, який вказує що користувач ще не увійшов в систему).
  2. Якщо користувач був знайдений, процес реєстрації подій оновлює поточний active objectclass, додаючи до об'єкта Acct-Session-ID і час початку з'єднання. Лічильник входів в систему також збільшується.
  3. Дані про початок з'єднання записуються в файл / var / radius / data / accounting.

Всі пакети підтверджуються. Якщо дії, описані вище, не будуть успішно виконані, в журнал будуть записані помилки. Щоб не порушувати порядок повідомлень обліку (Accounting packets), також реєструються і помилкові пакети.

Термінальний сервер припиняє передавати start-пакети або коли отримує підтвердження від RADIUS-сервера, або коли перевищує число можливих спроб відіслати повідомлення. Термінальний сервер пересилає start-пакети через певний інтервал часу (наприклад, 0, 2 хвилини, 4 хвилини, 8 хвилин, і так далі) до тих пір, поки не отримає підтвердження або перевищить допустиму кількість спроб відправити цей пакет (див. Пункт 8 на малюнку 4 ).

Детальний опис параметра Acct-Delay-Time

Атрибут Acct-Delay-Time не відображає затримок у передачі даних по мережі. Він відображає затримки через невиконані доставок попередніх пакетів. Власне, це говорить про наявність проблем з передачею даних по мережі або про те, що була якась помилка в процесі аутентифікації (він був недоступний з якоїсь причини).

Коли клієнт отримує доступ до мережі, висилається start-пакет (Acct-Delay-Time = 0). Якщо за певний період часу не було отримано коректного підтвердження, відсилається другий пакет, який містить нову затримку (Acct-Delay-Time = 120). Перш ніж термінальний сервер завершить своє виконання, ці спроби будуть тривати (як і у випадку з аутентифицирующей пакетом) певну кількість разів. Так само як і у випадку з аутентифицирующей пакетом, буде зроблена спроба доставити stat-пакет іншому процесу реєстрації подій, якщо такий визначено.

Опис Accounting Start-пакета

Нижче наведено приклад ситуації, коли сервер реєстрації подій RADIUS отримує Accounting Start-пакет.

Oct 1 15:47:43 server1 radiusd [540746]: [1]: Starting parse_packet () Oct 1 15:47:43 server1 radiusd [540746]: [1]: Code 4, ID = 54, Port = 49475 Host = 10.10.10.9 Oct 1 15:47:43 server1 radiusd [540746]: [1]: Acct-Status-Type = Start Oct 1 15:47:43 server1 radiusd [540746]: [1]: Acct-Session-Id = "000004F5" Oct 1 15:47:43 server1 radiusd [540746]: [1]: User-Name = "user_id" Oct 1 15:47:43 server1 radiusd [540746]: [1]: NAS-IP-Address = 10.10.10.9 Oct 1 15:47:43 server1 radiusd [540746]: [1]: NAS-Port = 12 Oct 1 15:47:43 server1 radiusd [540746]: [1]: Acct-Authentic = RADIUS Oct 1 15 : 47: 43 server1 radiusd [540746]: [1]: Service-Type = Framed-User Oct 1 15:47:43 server1 radiusd [540746]: [1]: Framed-Protocol = PPP Oct 1 15:47:43 server1 radiusd [540746]: [1]: Framed-IP-Address = 10.10.10.10 Oct 1 15:47:43 server1 radiusd [540746]: [1]: Acct-Delay-Time = 1

Інформація в Accounting Start-пакеті, як показано на отладочном виведення сервера RADIUS, складається з наступних частин:

  • Тема (перший рядок).
  • Пари ім'я / значення.

І Accounting Start-пакет, і пакет аутентифікації містять деякі загальні пари ім'я / значення. Для додаткової зручності пакети містять і загальні, і унікальні елементи.

Інформація, наведена вище, може бути зібрана, якщо RADIUS-сервер працює на 9-му рівні налагодження. Друга стаття цього циклу надасть опис того, як працює RADIUS-сервер при налагодженні.

Тема Accounting Start-пакета
Code

Тип RADIUS-пакета. Всі запити, пов'язані з реєстрацією подій, мають код "4". ID Порядковий номер пакета, який визначається термінальним сервером. Пакети, послані до поточного пакета, мають менші значення ідентифікатора (ID), в той час як пакети, надіслані після поточного пакета, мають великі значення ID. Номер ID відкочується до "1" як тільки ID досягає значення 256. Це може бути корисно при встановленні послідовності отримання пакетів. Крім того, коли ідентифікатори пакетів приходять не по порядку, це означає наявність затримки при передачі даних через мережу, або інші проблеми. Length Довжина всього пакета в байтах. Host IP-адреса хоста, який відправив пакет, в шістнадцятковій системі числення. Кожна пара шістнадцяткових чисел означає одну з чотирьох частин IP-адреси.

Опис пар ім'я / значени Accounting Start-пакета
Acct-Status-Type Type

= 40 Визначає тип пакета реєстрації подій (початок або кінець з'єднання). В даному прикладі використовується start-пакет. Acct-Session-ID Type = 44 Шістнадцяткове число з восьми цифр, що генерується передавачем термінальним сервером. Термінальний сервер гарантує, що це число буде унікальним (для нього самого) з моменту його останнього перезавантаження. Пакет про закінчення з'єднання для поточної облікової сесії містить ідентифікатор Acct-Session-ID, за яким легко знайти повідомлення про початок / закінчення з'єднань. User-Name Type = 1 Ім'я користувача, що вводиться для мережевої аутентифікації. NAS-IP-Address Type = 4 IP-адреса термінального сервера, який запитує аутентифікацію. NAS-Port Type = 5 S-port, до якого звертається користувач (наприклад, модем). Acct-Authentic Type = 45 Визначає, яким методом автентифіковані користувачі. Завжди має бути RADIUS. Service-Type Type = 6 Тип служби, яку запитує користувач. Більшість користувачів можуть бути або Framed-Users, або мережевими користувачами. Framed-Protocol Type = 7 Атрибут Framed-Protocol дозволяє вказати протокол, який використовується для передачі даних між клієнтом і мережею. Дана пара ім'я / значення доступна тільки тоді, коли властивість User-Service-Type встановлено в Framed-Users. Framed-IP-Address Type = 8 IP-адреса, які використовують клієнти коли приєднуються до мережі. Ця пара з'являється тільки тоді, коли властивість User-Service-Type має значення Framed-Users. Acct-Delay-Time Type = 41 Затримка за часом, яка мала місце з моменту посилки пакета і приходом підтвердження аутентифікації. Віднімання Acct-Delay-Time з поточного системного часу має дати приблизний час, коли користувач отримав доступ до мережі (див. Розділ Детальний опис Acct-Delay-Time ).

Сценарій зупинки реєстрації повідомлень

Малюнок 5. Повідомлення про зупинку реєстрації повідомлень RADIUS-сервером

Процес створення пакету про зупинку реєстрації повідомлень (Stop Accounting-пакет) починається в момент, коли віддалений пристрій завершує або скидає з'єднання. Після цього термінальний сервер генерує Stop-пакет (див. Пункт 9 на малюнку 5 и Опис Stop Accounting-пакета ).

Stop Accounting-пакет містить той же Acct-Session-Id, що і Start Accounting-пакет. Як і Start Accounting -пакет, Stop Accounting-пакет може відсилати пару ім'я / значення Acct-Delay-Time. Acct-Delay-Time для Stop Accounting-пакета - це кількість часу, що пройшов з того моменту, як справжній пакет був посланий і клієнт завершив з'єднання. Більш детальна інформація про Acct-Delay-Time може бути знайдена в розділі Детальний опис Acct-Delay-Time .

Коли сервер реєстрації подій RADIUS приймає Stop Accounting-пакет (див. Пункти 10 і 11 на малюнку 5 ):

  1. Виконується пошук LDAP- поля active objectclass відповідного користувача. Пошук заснований на Session-Id, User-Name і прапорі входу в систему.
  2. Якщо була знайдена відповідна запис, запис видаляється. Objectclass повинен відображати те, що клієнт завершив з'єднання.
  3. Дані з Stop Accounting-пакета записуються в / var / radius / data / accounting.

Число секунд, протягом яких користувач був у мережі, відсилаються в параметрі Acct-Session-Time.

Як і у випадку зі Start Accounting-пакетом, всі отримані пакети підтверджуються, щоб виключити повторні запити термінального сервера і мінімізувати мережевий трафік і обчислювальні навантаження. Якщо кроки вище були успішно виконані, всі помилки записуються в syslog.

Термінальний сервер припиняє передавати Stop Accounting-пакети, коли отримує підтвердження від RADIUS-сервера, або коли вичерпує всі спроби передати цей пакет. Термінальний сервер пересилає Stop Accounting-пакети через заздалегідь певні інтервали часу (наприклад, 0, 2 хвилини, 4 хвилини, 8 хвилин, і так далі) до тих пір, поки йому не прийде підтвердження або він не перевищить число можливих спроб відправки пакета (див . пункт 12 на малюнку 5 ). Якщо визначено проксі, доставка Stop Accounting-пакета може бути виконана на альтернативний сервер реєстрації повідомлень RADIUS.

Опис Stop Accounting-пакета

Нижче наведено приклад, коли сервер реєстрації подій RADIUS отримує Stop Accounting-пакет.

Oct 1 15:50:17 server1 radiusd [540746]: [2]: Starting parse_packet () Oct 1 15:50:17 server1 radiusd [540746]: [2]: Code 4, ID = 67, Port = 49475 Host = 10.10.10.9 Oct 1 15:50:17 server1 radiusd [540746]: [2]: Acct-Status-Type = Stop Oct 1 15:50:17 server1 radiusd [540746]: [2]: Acct-Session-Id = "000004F5" Oct 1 15:50:17 server1 radiusd [540746]: [2]: User-Name = "user_id" Oct 1 15:50:17 server1 radiusd [540746]: [2]: NAS-IP-Address = 10.10.10.9 Oct 1 15:50:17 server1 radiusd [540746]: [2]: NAS-Port = 12 Oct 1 15:50:17 server1 radiusd [540746]: [2]: Service-Type = Framed-User Oct 1 15:50:17 server1 radiusd [540746]: [2]: Framed-Protocol = PPP Oct 1 15:50:17 server1 radiusd [540746]: [2]: Framed-IP-Address = 10.10.10.10 Oct 1 15 : 50: 17 server1 radiusd [540746]: [2]: Acct-Input-Octets = 100 Oct 1 15:50:17 server1 radiusd [540746]: [2]: Acct-Output-Octets = 200 Oct 1 15:50 : 17 server1 radiusd [540746]: [2]: Acct-Session-Time = 7200 Oct 1 15:50:17 server1 radiusd [540746]: [2]: Acct-Terminate-Cause = User-Request

Дані в Stop Accounting-пакеті, як видно з інформації, виведеної RADIUS-сервером на 9-му рівні налагодження, складаються з наступних частин:

  1. Header information (first line)
  2. Послідовність пар ім'я / значення.

Stop Accounting-пакет і пакет аутентифікації мають деякі загальні пари ім'я / значення, однак для зручності у них є і унікальні пари ім'я / значення. Щодо розглянутого прикладу зауважимо, що був відправлений атрибут Acct-Session-Time зі значенням 7200; це означає, що користувач user_id був в системі протягом 7200 секунд.

Опис пар ім'я / значення Accounting Stop-пакета
Acct-Status-Type Type

= 40 Визначає тип пакета реєстрації подій (Початок або кінець з'єднання). В даному прикладі використовується Stop Accounting-пакет. Acct-Session-Id Type = 44 Шістнадцяткове число з восьми цифр, що генерується передавачем термінальним сервером. Термінальний сервер гарантує, що це число буде унікальним (для нього самого) з моменту його останнього перезавантаження. Stop Accounting-пакет для поточної облікової сесії містить Acct-Session-ID. Завдяки цьому легко шукати повідомлення про початок / закінчення з'єднань. User-Name Type = 1 Ім'я користувача, що вводиться для мережевої аутентифікації. NAS-IP-Address Type = 4 IP-адреса термінального сервера, який запитує аутентифікацію. NAS-Port Type = 5 S-port, до якого звертається користувач (наприклад, модем). Acct-Session-Time Type = 46 Приблизний час, протягом якого клієнт був в мережі. Визначається термінальним сервером. Acct-Authentic Type = 45 Визначає, яким методом автентифіковані користувачі. Завжди має бути RADIUS. Service-Type Type = 6 Тип служби, яку запитує користувач. Більшість користувачів можуть бути або Framed-Users, або мережевими користувачами. Framed-Protocol Type = 7 Атрибут Framed-Protocol дозволяє вказати протокол, який використовується для передачі даних між клієнтом і мережею. Дана пара ім'я / значення доступна тільки тоді, коли властивість User-Service-Type встановлено в Framed-Users. Framed-IP-Address Type = 8 IP-адреса, які використовують клієнти коли приєднуються до мережі. Ця пара з'являється тільки тоді, коли властивість User-Service-Type має значення Framed-Users. Acct-Input-Octets Type = 42 Як багато октетів було отримано з цього порту. Acct-Output-Octets Type = 42 Число октетів, відправлених через порт. Acct-Terminate-Cause Type = 49 Причина, по якій була припинена сесія.

Облікові дані записуються в файл журналу / var / radius / data / accounting. Формат даних параметр = значення; час у вигляді текстового рядка і день виводяться на початку зведення інформації, а тимчасова мітка виводиться в кінці. Тимчасова мітка являє собою число секунд з 1970 року.

Можна написати сценарії, щоб створювати звіти різних типів, наприклад: облікові дані про активність за місяць, активності певного користувача або IP-адреси.

Друга стаття цього циклу присвячена установці і конфігурації сервера AIX RADIUS.

Ресурси для скачування

Схожі тими

  • AIX RADIUS server, Part 1: Authentication and accounting protocols : Оригінал статті (EN).
  • AIX RADIUS server, Part 2: Installation and configuration (EN) (developerWorks, січень 2005): стаття про те, як встановлювати, конфігурувати, авторизувати і налагоджувати RADIUS сервер.
  • розділ developerWorks AIX и UNIX містить сотні інформативних статей для читачів початкової, середньої і високої кваліфікації.
  • Розділи бібліотеки інформації по темам AIX і UNIX: (EN)
  • IBM trial software : Ознайомчі версії програмного забезпечення для розробників, які можна завантажити прямо зі сторінки спільноти developerWorks. (EN)
  • Візьміть участь в форумах AIX і UNIX: (EN)

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Com/developerworks/ru/library/?
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью