Límits de connexions VPN: estat viu enfront d'un historial conservat
Un límit de tres connexions necessita estat viu dels espais, no un historial de navegació: què ha de guardar el mecanisme, què pot descartar i on va aquest estat després.
Tres connexions simultànies són una decisió d'admissió, i respondre-la exigeix saber quins espais estan ocupats ara mateix i no què va passar el mes passat. Un servei pot refusar una quarta sessió a partir d'una taula petita de registres actius i no construir mai cap cronologia. Això és una afirmació sobre el mecanisme, no sobre l'operador, i la diferència importa quan llegiu una política de privadesa. El model de sota mostra què necessita la decisió i què pot descartar.
El mecanisme: una taula d'espais, no un registre
La implementació més simple associa una subscripció amb fins a tres registres de sessió actius. Cada sessió admesa ocupa un espai, i l'espai s'allibera quan el servei decideix que aquella sessió ha acabat. El registre necessita una identitat prou específica perquè alliberar una connexió no alliberi l'espai d'una altra, i per això l'identificador de sessió importa més que el nom del compte.
L'ocupació i l'historial són estructures de dades diferents. L'ocupació respon una pregunta de sí o no sobre el present, i es pot descartar en el moment que la sessió acaba. Un historial és un flux d'esdeveniments només d'afegir, i sobreviu perquè algú va triar conservar-lo. Un servei pot tenir un, els dos o cap.
La distinció és invisible des de fora. Un límit de connexions visible és compatible amb un comptador petit en memòria, una taula compartida de base de dades i un arxiu complet d'esdeveniments amb un tauler. Res del límit us diu quin d'ells s'executa.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Per què el model viu encara necessita coordinació
Una connexió perduda pot no ser reconeguda com a acabada de seguida. La passarel·la espera un temps d'espera, un error de keepalive o una aturada de comptabilitat, i fins que un d'aquests arriba l'espai resta ocupat. Un usuari que es reconnecta durant aquesta finestra veu un refús que no té res a veure amb un quart dispositiu.
Un servidor reiniciat ha de reconciliar el seu estat, i diverses passarel·les que serveixen el mateix compte necessiten una decisió comuna. Si no, un compte pot superar la seva assignació connectant-se a ubicacions diferents. Un estat compartit o recuperable ho resol, i l'estat compartit és un requisit de disseny, no una prova de vigilància.
Cap d'aquestes coordinacions no requereix historials de navegació. Una passarel·la que reenvia paquets no necessita saber quins llocs ha visitat una sessió per comptar sessions, i els dos fluxos de dades normalment els gestionen components completament diferents.
Guardar un recompte en memòria tampoc no fa anònims els fets associats. Mentre el servei funciona, un registre vinculat a la subscripció revela que un compte té connexions actives, i l'accés a aquest estat i la seva durada són tots dos dignes de preguntar.
On va l'estat després
La pregunta de privadesa no és si el servidor pot comptar. Pregunteu què passa amb una sessió acabada: s'elimina el registre o es converteix en un esdeveniment d'una sèrie de monitoratge? Després pregunteu quins altres components van veure el mateix esdeveniment, perquè els registres d'autenticació, els registres de comptabilitat i les còpies de seguretat poden guardar cadascun una còpia que el camí d'aplicació va descartar.
La comptabilitat RADIUS és l'exemple més clar. Una parella Start i Stop existeix per donar suport a la facturació i al control de sessions, i crea un registre de la connexió independentment que algú el consulti mai com a historial. Un servei que aplica límits mitjançant la comptabilitat, per tant, conserva per construcció més que una taula d'espais.
L'esborrat també té una forma. Un registre eliminat de la taula viva pot persistir en una còpia de seguretat feta una hora abans, i el període de retenció d'aquella còpia és una declaració de política pròpia. Llegir només el magatzem primari dona una resposta incompleta.
Feu la pregunta en termes de camps
Les directrius de minimització de dades de l'RFC 6973 lliguen les dades recollides i emmagatzemades a la finalitat a la qual serveixen. Aplicat aquí, la pregunta útil és quins camps necessita realment la tasca d'admissió concurrent, i quina finalitat justifica conservar cadascun després que aquesta tasca acabi.
Una declaració precisa del servei separa l'estat viu de connexió usat per aplicar l'assignació de qualsevol registre conservat després de la terminació, i anomena els altres sistemes dins l'abast de la promesa. Una frase que només diu que s'apliquen tres connexions no estableix ni que existeixi un arxiu ni que no n'hi hagi cap.
Quan el cicle de vida no és clar, anoteu-ho com una pregunta de retenció sense resposta en lloc d'un veredicte. La presència d'un límit no és prova d'un historial ocult, i una explicació plausible de l'estat viu no és una auditoria del proveïdor.