Comptabilitat RADIUS enfront d’inici de sessió correcte: què demostra cadascú
Un Access-Accept diu que una sessió pot començar. Els registres Start, Interim-Update i Stop diuen què va passar després; un identificador de sessió els lliga.
Dues preguntes es confonen en tota discussió sobre facturació de VPN: si a aquest usuari se li va permetre connectar-se i què va fer realment. La primera la respon l’autenticació. La segona requereix registres de comptabilitat que comencin, s’actualitzin i acabin. Un inici de sessió correcte demostra la primera i no diu res de la segona, i per això una configuració d’autenticació RADIUS que funciona encara pot produir un informe d’ús buit.
Dues preguntes diferents
L’autenticació decideix si una connexió pot començar, i retorna un veredicte més atributs com ara un pool d’adreces o un grup. La comptabilitat enregistra el servei que va seguir, com una sèrie d’esdeveniments lligats a una sessió.
Viatgen pel mateix protocol i normalment cap al mateix servidor, i per això la gent suposa que un implica l’altre.
Res en una sol·licitud d’accés no porta la durada de la sessió, i res en un registre Stop no torna a decidir si l’usuari hauria d’haver estat admès. Tractar-los com a contractes separats fa visible la feina d’integració: un camí necessita una decisió, l’altre necessita un cicle de vida amb un començament, un mig i un final.
Què et donen els tres tipus de registre
Un registre Start obre una sessió, un Interim-Update informa de l’activitat mentre és oberta, i un Stop la tanca. Tots tres porten un identificador de sessió perquè el receptor pugui relacionar-los amb un sol esdeveniment de servei.
Aquest identificador és l’únic enllaç fiable entre ells, perquè el mateix nom d’usuari pot tenir diverses sessions en sèrie o en paral·lel. Dissenya l’emmagatzematge al voltant d’ell i no del nom del compte.
Reconèixer un registre és un assumpte separat de desar-lo bé. L’especificació de comptabilitat prohibeix el reconeixement quan el registre no s’ha pogut escriure, així que una resposta sí que et diu que el receptor va acceptar la responsabilitat. No et diu que la tasca posterior d’informes, el quadre de comandament o l’exportació de facturació l’hagin consumit correctament.
Per què el nom d’usuari no és la sessió
Una persona es connecta des d’un portàtil al matí i d’un telèfon a la tarda, i les dues sessions porten el mateix nom de compte. Un Start que arriba sense el seu Stop corresponent no es pot tancar buscant el nom i triant la fila oberta més antiga.
Aquesta drecera és com els informes d’ús adquireixen durades impossibles.
Mantingues la identitat del servidor d’accés a la xarxa al costat de l’identificador de sessió, perquè dos servidors poden assignar el mateix valor en contextos diferents i una fusió només per l’identificador pot unir sessions no relacionades. Quan una sessió acaba sense gràcia, la política de reconciliació ha de decidir com tancar-la, i aquesta decisió pertany al disseny i no a una edició manual de la base de dades feta un cop al mes.
On encaixa PAM i on no
El connector d’autenticació d’OpenVPN crida les etapes d’autenticació i de gestió de comptes de PAM. L’etapa de compte comprova l’elegibilitat; el seu nom no vol dir comptabilitat d’ús, i el connector no impulsa els ganxos d’obertura i tancament de sessió de PAM.
Alguns mòduls PAM RADIUS poden enviar registres de comptabilitat a través d’aquests ganxos de sessió, i això només funciona quan l’aplicació realment els invoca.
Afegir aquest mòdul a una pila d’autenticació, per tant, no crea esdeveniments de desconnexió. Si necessites el cicle de vida complet, tria una integració que en sigui responsable: un connector o una compilació compatible que emeti Start, Interim-Update i Stop a mesura que la connexió canvia d’estat. Comprova el seu estat de manteniment i el seu comportament documentat quan el receptor no està disponible, perquè un connector que descarta registres en silenci sembla idèntic a un que mai no els va enviar. L’especificació de comptabilitat defineix la semàntica dels registres que la integració ha de respectar.
Una prova d’acceptació que demostra el contracte
Prova una connexió i una desconnexió normals, després una reconnexió amb el mateix compte, després un client que desapareix sense desconnectar-se.
Segueix un identificador de sessió des de la generació passant pel reconeixement fins a l’emmagatzematge, i comprova la direcció, les unitats i la interfície dels comptadors. Un recompte de bytes sense etiqueta és impossible d’auditar després.
Finalment, confirma que una sessió que el servidor va haver de tancar per temps d’espera es representa d’una manera que l’informe entén. Un contracte que només cobreix desconnexions ordenades és un contracte que falla els dies que més el necessites.