Limiti di connessione VPN: stato in tempo reale o cronologia conservata

Tre connessioni simultanee sono una decisione di ammissione, e per rispondere occorre sapere quali slot sono occupati in questo momento e non cosa è successo il mese scorso. Un servizio può rifiutare una quarta sessione da una piccola tabella di record attivi e non costruire mai una linea temporale. È un'affermazione sul meccanismo, non sull'operatore, e la differenza conta quando si legge un'informativa sulla privacy. Il modello seguente mostra di cosa ha bisogno la decisione e cosa può scartare.

Il meccanismo: una tabella di slot, non un registro

L'implementazione più semplice associa un abbonamento a un massimo di tre record di sessione attivi. Ogni sessione ammessa occupa uno slot, e lo slot viene liberato quando il servizio decide che quella sessione è terminata. Il record ha bisogno di un'identità sufficientemente specifica perché liberare una connessione non liberi lo slot di un'altra connessione; per questo l'identificatore di sessione conta più del nome dell'account.

Occupazione e cronologia sono strutture dati diverse. L'occupazione risponde a una domanda sì o no sul presente e può essere scartata nel momento in cui la sessione termina. Una cronologia è un flusso di eventi in sola aggiunta, e sopravvive perché qualcuno ha scelto di conservarlo. Un servizio può avere l'una, entrambe o nessuna.

La distinzione è invisibile dall'esterno. Un limite di connessioni visibile è compatibile con un minuscolo contatore in memoria, una tabella di database condivisa e un archivio completo di eventi con una dashboard. Nulla nel limite ti dice quale di questi sia in esecuzione.

Perché il modello in tempo reale ha comunque bisogno di coordinamento

Una connessione persa potrebbe non essere riconosciuta subito come terminata. Il gateway attende un timeout, un guasto di keepalive o un arresto della contabilità, e finché uno di questi non arriva lo slot resta occupato. Un utente che si riconnette in quella finestra vede un rifiuto che non ha nulla a che fare con un quarto dispositivo.

Un server riavviato deve riconciliare il proprio stato, e più gateway che servono lo stesso account hanno bisogno di una decisione comune. Altrimenti un account può superare la propria quota collegandosi a località diverse. Uno stato condiviso o recuperabile risolve la cosa, e lo stato condiviso è un requisito di progettazione, non una prova di sorveglianza.

Niente di quel coordinamento richiede cronologie di navigazione. Un gateway che inoltra pacchetti non ha bisogno di sapere quali siti ha visitato una sessione per contare le sessioni, e i due flussi di dati sono di solito gestiti da componenti completamente diversi.

Tenere un conteggio in memoria non rende nemmeno anonimi i fatti associati. Mentre il servizio è in funzione, un record collegato all'abbonamento rivela che un account ha connessioni attive, e sia l'accesso a quello stato sia la sua durata meritano di essere chiesti.

Dove va poi quello stato

La questione della privacy non è se il server possa contare. Chiedi cosa succede a una sessione terminata: il record viene rimosso o diventa un evento in una serie di monitoraggio? Poi chiedi quali altri componenti hanno visto lo stesso evento, perché i log di autenticazione, i record contabili e i backup possono ciascuno conservare una copia che il percorso di applicazione ha scartato.

La contabilità RADIUS è l'esempio più chiaro. Una coppia Start e Stop esiste per supportare la fatturazione e il controllo delle sessioni, e crea un record della connessione indipendentemente dal fatto che qualcuno lo interroghi mai come cronologia. Un servizio che applica limiti tramite la contabilità conserva quindi per costruzione più di una tabella di slot.

Anche la cancellazione ha una forma. Un record rimosso dalla tabella in tempo reale può persistere in un backup effettuato un'ora prima, e il periodo di conservazione di quel backup è una dichiarazione di policy a sé. Leggere solo l'archivio primario dà una risposta incompleta.

Poni la domanda in termini di campi

Le linee guida sulla minimizzazione dei dati del RFC 6973 legano i dati raccolti e memorizzati allo scopo servito. Applicata qui, la domanda utile è quali campi richieda davvero l'attività di ammissione simultanea e quale scopo giustifichi conservare ciascuno dopo che tale attività è terminata.

Un'affermazione di servizio precisa separa lo stato di connessione in tempo reale usato per applicare la quota da qualsiasi record conservato dopo la terminazione, e nomina gli altri sistemi nell'ambito della promessa. Una frase che dice solo che vengono applicate tre connessioni non stabilisce né che un archivio esista né che non esista.

Quando il ciclo di vita non è chiaro, registralo come domanda di conservazione senza risposta anziché come verdetto. La presenza di un limite non è prova di una cronologia nascosta, e una spiegazione plausibile dello stato in tempo reale non è un audit del fornitore.