Contabilitate RADIUS versus autentificare reușită: ce demonstrează fiecare

În orice discuție despre facturarea VPN se amestecă două întrebări: avea acest utilizator voie să se conecteze și ce a făcut de fapt. La prima răspunde autentificarea. A doua cere înregistrări de contabilitate care încep, se actualizează și se termină. O autentificare reușită o demonstrează pe prima și nu spune nimic despre a doua, de aceea o configurație RADIUS funcțională poate produce totuși un raport de utilizare gol.

Două întrebări diferite

Autentificarea decide dacă o conexiune poate începe, și returnează un verdict împreună cu atribute precum un pool de adrese sau un grup. Contabilitatea înregistrează serviciul care a urmat, ca o secvență de evenimente legate de o singură sesiune.

Ele circulă pe același protocol și de obicei către același server, și exact de aceea oamenii presupun că unul îl implică pe celălalt.

Nimic dintr-o cerere de acces nu poartă durata sesiunii, și nimic dintr-o înregistrare Stop nu decide din nou dacă utilizatorul ar fi trebuit admis. Tratarea lor ca contracte separate face vizibilă munca de integrare: o cale are nevoie de o decizie, cealaltă de un ciclu de viață cu început, mijloc și sfârșit.

Ce oferă cele trei tipuri de înregistrare

O înregistrare Start deschide o sesiune, un Interim-Update raportează activitate cât timp este deschisă, iar un Stop o închide. Toate trei poartă un identificator de sesiune, astfel încât receptorul să le poată lega de un singur eveniment de serviciu.

Acel identificator este singura legătură de încredere între ele, pentru că același nume de utilizator poate avea mai multe sesiuni succesive sau paralele. Proiectați stocarea în jurul lui, nu în jurul numelui contului.

Confirmarea unei înregistrări este altceva decât stocarea ei bună. Specificația de contabilitate interzice confirmarea când înregistrarea nu a putut fi scrisă, deci un răspuns chiar vă spune că receptorul și-a asumat responsabilitatea. Nu vă spune că sarcina ulterioară de raportare, panoul de control sau exportul de facturare au consumat-o corect.

De ce numele de utilizator nu este sesiunea

O persoană se conectează de pe un laptop dimineața și de pe un telefon după-amiaza, iar ambele sesiuni poartă același nume de cont. O înregistrare Start care sosește fără Stop-ul corespunzător nu poate fi închisă căutând numele și alegând rândul deschis cel mai vechi.

Această scurtătură este modul în care rapoartele de utilizare capătă durate imposibile.

Păstrați identitatea serverului de acces la rețea lângă identificatorul de sesiune, pentru că două servere pot atribui aceeași valoare în contexte diferite, iar o fuziune doar pe identificator poate uni sesiuni neînrudite. Când o sesiune se termină neîngrijit, politica de reconciliere trebuie să decidă cum o închide, iar acea decizie aparține proiectării, nu unei editări manuale a bazei de date făcută o dată pe lună.

Unde se potrivește PAM și unde nu

Pluginul de autentificare al OpenVPN apelează etapele de autentificare și de administrare a conturilor din PAM. Etapa de cont verifică eligibilitatea; numele ei nu înseamnă contabilitate de utilizare, iar pluginul nu conduce cârligele de deschidere și închidere a sesiunii din PAM.

Unele module PAM RADIUS pot trimite înregistrări de contabilitate prin acele cârlige de sesiune, iar asta funcționează doar când aplicația le invocă într-adevăr.

Adăugarea unui astfel de modul la un stack de autentificare nu creează, așadar, evenimente de deconectare. Dacă aveți nevoie de ciclul de viață complet, alegeți o integrare care îl deține: un plugin sau o compilare acceptată care emite Start, Interim-Update și Stop pe măsură ce conexiunea își schimbă starea. Verificați starea de întreținere și comportamentul documentat când receptorul nu este disponibil, pentru că un plugin care aruncă înregistrări în tăcere arată identic cu unul care nu le-a trimis niciodată. Specificația de contabilitate definește semantica înregistrărilor pe care integrarea trebuie să o respecte.

O rulare de acceptare care demonstrează contractul

Testați o conectare și o deconectare normale, apoi o reconectare sub același cont, apoi un client care dispare fără să se deconecteze.

Urmați un identificator de sesiune de la generare, prin confirmare, până la stocare și verificați direcția, unitățile și interfața contoarelor. Un număr de bytes fără etichetă este imposibil de auditat mai târziu.

În final, confirmați că o sesiune pe care serverul a trebuit să o închidă din cauza expirării este reprezentată într-un mod pe care raportul îl înțelege. Un contract care acoperă doar deconectările ordonate este un contract care eșuează în zilele când aveți cea mai mare nevoie de el.