Contabilità RADIUS contro accesso riuscito: cosa dimostra ciascuno
Un Access-Accept dice che una sessione può iniziare. I record Start, Interim-Update e Stop dicono cosa è successo dopo; un identificatore di sessione li collega.
Due domande si confondono in ogni discussione sulla fatturazione VPN: a questo utente era consentito connettersi, e cosa ha effettivamente fatto. Alla prima risponde l’autenticazione. La seconda richiede record di contabilità che iniziano, si aggiornano e finiscono. Un accesso riuscito dimostra la prima e non dice nulla sulla seconda, per questo una configurazione di autenticazione RADIUS funzionante può comunque produrre un report di utilizzo vuoto.
Due domande diverse
L’autenticazione decide se una connessione può iniziare, e restituisce un verdetto più attributi come un pool di indirizzi o un gruppo. La contabilità registra il servizio che è seguito, come una sequenza di eventi legati a una sessione.
Viaggiano sullo stesso protocollo e di solito verso lo stesso server, ed è proprio per questo che le persone suppongono che uno implichi l’altro.
Niente in una richiesta di accesso porta la durata della sessione, e niente in un record Stop decide di nuovo se l’utente avrebbe dovuto essere ammesso. Trattarli come contratti separati rende visibile il lavoro di integrazione: un percorso ha bisogno di una decisione, l’altro di un ciclo di vita con un inizio, un mezzo e una fine.
Cosa danno i tre tipi di record
Un record Start apre una sessione, un Interim-Update segnala attività mentre è aperta, e un Stop la chiude. Tutti e tre portano un identificatore di sessione così che il ricevitore possa collegarli a un unico evento di servizio.
Quell’identificatore è l’unico legame affidabile tra loro, perché lo stesso nome utente può avere più sessioni in sequenza o in parallelo. Progetta l’archiviazione intorno a esso e non intorno al nome dell’account.
Confermare un record è una cosa diversa dal conservarlo bene. La specifica di contabilità vieta la conferma quando il record non è stato scritto, quindi una risposta ti dice davvero che il ricevitore ha accettato la responsabilità. Non ti dice che il successivo lavoro di reportistica, la dashboard o l’esportazione di fatturazione lo abbiano consumato correttamente.
Perché il nome utente non è la sessione
Una persona si connette da un portatile la mattina e da un telefono il pomeriggio, ed entrambe le sessioni portano lo stesso nome account. Un Start che arriva senza il suo Stop corrispondente non si chiude cercando il nome e scegliendo la riga aperta più vecchia.
Questa scorciatoia è il modo in cui i report di utilizzo ottengono durate impossibili.
Tieni l’identità del server di accesso alla rete accanto all’identificatore di sessione, perché due server possono assegnare lo stesso valore in contesti diversi e una fusione sul solo identificatore può unire sessioni non correlate. Quando una sessione finisce male, la politica di riconciliazione deve decidere come chiuderla, e quella decisione appartiene al progetto e non a una modifica manuale del database fatta una volta al mese.
Dove PAM si inserisce e dove no
Il plugin di autenticazione di OpenVPN chiama gli stadi di autenticazione e gestione account di PAM. Lo stadio account verifica l’idoneità; il suo nome non significa contabilità di utilizzo, e il plugin non guida gli hook di apertura e chiusura di sessione di PAM.
Alcuni moduli PAM RADIUS possono inviare record di contabilità attraverso quegli hook di sessione, e questo funziona solo quando l’applicazione li invoca davvero.
Aggiungere un modulo così a uno stack di autenticazione non crea quindi eventi di disconnessione. Se ti serve il ciclo di vita completo, scegli un’integrazione che lo possieda: un plugin o una build supportata che emette Start, Interim-Update e Stop mentre la connessione cambia stato. Controlla il suo stato di manutenzione e il suo comportamento documentato quando il ricevitore non è disponibile, perché un plugin che perde record in silenzio sembra identico a uno che non li ha mai inviati. La specifica di contabilità definisce la semantica dei record che l’integrazione deve rispettare.
Una prova di accettazione che dimostra il contratto
Prova una connessione e una disconnessione normali, poi una riconnessione con lo stesso account, poi un client che scompare senza disconnettersi.
Segui un identificatore di sessione dalla generazione attraverso la conferma fino all’archiviazione, e controlla la direzione, le unità e l’interfaccia dei contatori. Un conteggio di byte senza etichetta è impossibile da verificare in seguito.
Infine, conferma che una sessione che il server ha dovuto chiudere per timeout sia rappresentata in un modo che il report comprende. Un contratto che copre solo le disconnessioni ordinate è un contratto che fallisce nei giorni in cui ti serve di più.