Облік RADIUS і успішний вхід: що доводить кожен
Access-Accept повідомляє, що сеанс може початися. Записи Start, Interim-Update і Stop кажуть, що сталося далі; ідентифікатор сеансу пов’язує їх.
У кожному обговоренні тарифікації VPN змішуються два питання: чи мав цей користувач право підключитися і що він насправді зробив. На перше відповідає автентифікація. Друге потребує записів обліку, які починаються, оновлюються і закінчуються. Успішний вхід доводить перше і нічого не каже про друге, тому робоче налаштування автентифікації RADIUS усе одно може дати порожній звіт про використання.
Два різні питання
Автентифікація вирішує, чи може початися з’єднання, і повертає вердикт разом з атрибутами, такими як пул адрес або група. Облік записує послугу, що настала, як послідовність подій, прив’язаних до одного сеансу.
Вони йдуть одним протоколом і зазвичай до одного сервера, і саме тому люди припускають, що одне означає інше.
Ніщо в запиті доступу не несе тривалість сеансу, і ніщо в записі Stop не вирішує заново, чи слід було пускати користувача. Якщо розглядати їх як окремі договори, робота інтеграції стає видимою: одному шляху потрібне рішення, іншому життєвий цикл із початком, серединою й кінцем.
Що дають три типи записів
Запис Start відкриває сеанс, Interim-Update повідомляє про активність, доки він відкритий, а Stop закриває його. Усі три несуть ідентифікатор сеансу, щоб отримувач міг пов’язати їх з однією подією послуги.
Цей ідентифікатор є єдиним надійним зв’язком між ними, бо те саме ім’я користувача може мати кілька сеансів послідовно або паралельно. Проєктуйте зберігання навколо нього, а не навколо назви облікового запису.
Підтвердити запис це не те саме, що добре його зберегти. Специфікація обліку забороняє підтвердження, коли запис не вдалося записати, тож відповідь справді повідомляє, що отримувач узяв відповідальність. Вона не повідомляє, що подальше завдання звітності, панель або експорт для білінгу використали його правильно.
Чому ім’я користувача не є сеансом
Одна людина підключається вранці з ноутбука, а вдень із телефона, і обидва сеанси несуть те саме ім’я облікового запису. Запис Start, що надійшов без відповідного Stop, не можна закрити, знайшовши ім’я та вибравши найстаріший відкритий рядок.
Цей короткий шлях і є тим, як звіти про використання отримують неможливі тривалості.
Тримайте ідентичність сервера мережного доступу поруч з ідентифікатором сеансу, бо два сервери можуть призначити те саме значення в різних контекстах, і об’єднання лише за ідентифікатором може з’єднати незв’язані сеанси. Коли сеанс завершується некоректно, політика звіряння має вирішити, як його закрити, і це рішення належить проєктуванню, а не ручному редагуванню бази раз на місяць.
Де PAM доречний, а де ні
Плагін автентифікації OpenVPN викликає етапи автентифікації та керування обліковими записами PAM. Етап облікового запису перевіряє придатність; його назва не означає облік використання, і плагін не керує гачками відкриття та закриття сеансу PAM.
Деякі модулі PAM RADIUS можуть надсилати записи обліку через ці гачки сеансу, і це працює лише тоді, коли застосунок справді їх викликає.
Тож додавання такого модуля до стеку автентифікації не створює подій відключення. Якщо потрібен повний життєвий цикл, обирайте інтеграцію, якій він належить: плагін або підтримувану збірку, що видає Start, Interim-Update і Stop, коли з’єднання змінює стан. Перевірте її стан супроводу та задокументовану поведінку, коли отримувач недоступний, бо плагін, що мовчки губить записи, виглядає так само, як той, що ніколи їх не надсилав. Специфікація обліку визначає семантику записів, якої інтеграція має дотримуватися.
Приймальний прогін, що доводить договір
Перевірте звичайні підключення й відключення, потім повторне підключення під тим самим обліковим записом, потім клієнта, що зникає без відключення.
Простежте один ідентифікатор сеансу від створення через підтвердження до зберігання і перевірте напрямок, одиниці та інтерфейс лічильників. Непозначену кількість байтів неможливо перевірити пізніше.
Нарешті, переконайтеся, що сеанс, який сервер мусив закрити через тайм-аут, подано так, як розуміє звіт. Договір, що покриває лише коректні відключення, це договір, який підводить у дні, коли він найпотрібніший.