Límites de conexións VPN: estado en vivo fronte a un historial conservado
Un límite de tres conexións necesita o estado dos espazos en vivo, non un historial de navegación: que debe gardar o mecanismo, que pode descartar e onde vai despois ese estado.
Tres conexións simultáneas son unha decisión de admisión, e para respondela hai que saber que espazos están ocupados agora mesmo e non o que ocorreu o mes pasado. Un servizo pode rexeitar unha cuarta sesión cunha pequena táboa de rexistros activos e nunca construír unha liña de tempo. Iso é unha afirmación sobre o mecanismo, non sobre o operador, e a diferenza importa cando un le unha política de privacidade. O modelo seguinte mostra que necesita a decisión e que pode descartar.
O mecanismo: unha táboa de espazos, non un rexistro
A implementación máis sinxela asocia unha subscrición con ata tres rexistros de sesión activos. Cada sesión admitida ocupa un espazo, e o espazo libérase cando o servizo decide que esa sesión rematou. O rexistro necesita unha identidade o bastante específica para que liberar unha conexión non libere o espazo doutra, e por iso o identificador de sesión importa máis có nome da conta.
Ocupación e historial son estruturas de datos distintas. A ocupación responde a unha pregunta de si ou non sobre o presente e pode descartarse no momento en que remata a sesión. Un historial é un fluxo de eventos de só anexión, e sobrevive porque alguén escolleu conservalo. Un servizo pode ter un, ambos ou ningún.
A distinción é invisible desde fóra. Un límite de conexións visible é compatible cun contador minúsculo en memoria, unha táboa de base de datos compartida e un arquivo completo de eventos cun panel. Nada no límite indica cal deles está en marcha.
| 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 |
Por que o modelo en vivo segue necesitando coordinación
Pode que unha conexión perdida non se recoñeza como rematada de inmediato. A pasarela espera un tempo de espera, un fallo de keepalive ou unha parada de contabilidade, e ata que chega un deles o espazo segue ocupado. Un usuario que se volve conectar durante esa xanela ve un rexeitamento que non ten nada que ver cun cuarto dispositivo.
Un servidor reiniciado ten que reconciliar o seu estado, e varias pasarelas que atenden a mesma conta necesitan unha decisión común. Se non, unha conta pode superar a súa cota conectándose a localizacións distintas. Un estado compartido ou recuperable resolve iso, e o estado compartido é un requisito de deseño e non unha proba de vixilancia.
Nada desa coordinación require historiais de navegación. Unha pasarela que reenvía paquetes non necesita saber que sitios visitou unha sesión para contar sesións, e os dous fluxos de datos adoitan manexalos compoñentes completamente distintos.
Manter un reconto en memoria tampouco anonimiza os feitos asociados. Mentres o servizo funciona, un rexistro vinculado á subscrición revela que unha conta ten conexións activas, e tanto o acceso a ese estado como a súa duración merecen preguntarse.
Onde vai despois ese estado
A pregunta de privacidade non é se o servidor pode contar. Pregunte que ocorre cunha sesión rematada: elimínase o rexistro ou convértese nun evento dunha serie de monitorización? Despois pregunte que outros compoñentes viron o mesmo evento, porque os rexistros de autenticación, os rexistros de contabilidade e as copias de seguridade poden gardar cada un unha copia que a ruta de aplicación descartou.
A contabilidade RADIUS é o exemplo máis claro. Un par Start e Stop existe para respaldar a facturación e o control de sesións, e crea un rexistro da conexión sen importar se alguén o consulta algunha vez como historial. Un servizo que aplica límites mediante contabilidade retén, por tanto, máis ca unha táboa de espazos por construción.
A eliminación tamén ten forma. Un rexistro eliminado da táboa en vivo pode persistir nunha copia feita unha hora antes, e o período de retención desa copia é unha declaración de política propia. Ler só o almacén principal dá unha resposta incompleta.
Formule a pregunta en termos de campos
A guía de minimización de datos do RFC 6973 vincula os datos recollidos e almacenados co propósito ao que serven. Aplicada aquí, a pregunta útil é que campos necesita realmente a tarefa de admisión concorrente e que propósito xustifica conservar cada un despois de que esa tarefa remate.
Unha declaración de servizo precisa separa o estado de conexión en vivo usado para aplicar a cota de calquera rexistro conservado tras a terminación, e nomea os demais sistemas dentro do alcance da promesa. Unha frase que só di que se aplican tres conexións non establece nin que exista un arquivo nin que non exista.
Cando o ciclo de vida non está claro, anóteo como unha pregunta de retención sen resposta en lugar dun veredicto. A presenza dun límite non é proba dun historial oculto, e unha explicación plausible do estado en vivo non é unha auditoría do provedor.