Límites de conexiones VPN: estado en vivo frente a un historial conservado

Tres conexiones simultáneas son una decisión de admisión, y responderla exige saber qué espacios están ocupados ahora mismo y no lo que ocurrió el mes pasado. Un servicio puede rechazar una cuarta sesión con una pequeña tabla de registros activos y no construir nunca una línea de tiempo. Eso es una afirmación sobre el mecanismo, no sobre el operador, y la diferencia importa cuando uno lee una política de privacidad. El modelo siguiente muestra qué necesita la decisión y qué puede descartar.

El mecanismo: una tabla de espacios, no un registro

La implementación más sencilla asocia una suscripción con hasta tres registros de sesión activos. Cada sesión admitida ocupa un espacio, y el espacio se libera cuando el servicio decide que esa sesión ha terminado. El registro necesita una identidad lo bastante específica para que liberar una conexión no libere el espacio de otra, y por eso el identificador de sesión importa más que el nombre de la cuenta.

Ocupación e historial son estructuras de datos distintas. La ocupación responde a una pregunta de sí o no sobre el presente y puede descartarse en el momento en que termina la sesión. Un historial es un flujo de eventos de solo anexión, y sobrevive porque alguien eligió conservarlo. Un servicio puede tener uno, ambos o ninguno.

La distinción es invisible desde fuera. Un límite de conexiones visible es compatible con un contador minúsculo en memoria, una tabla de base de datos compartida y un archivo completo de eventos con panel. Nada en el límite indica cuál de ellos está en marcha.

Por qué el modelo en vivo sigue necesitando coordinación

Puede que una conexión perdida no se reconozca como terminada de inmediato. La pasarela espera un tiempo de espera, un fallo de keepalive o una parada de contabilidad, y hasta que llega uno de ellos el espacio sigue ocupado. Un usuario que vuelve a conectarse durante esa ventana ve un rechazo que no tiene nada que ver con un cuarto dispositivo.

Un servidor reiniciado tiene que reconciliar su estado, y varias pasarelas que atienden la misma cuenta necesitan una decisión común. De lo contrario, una cuenta puede superar su cuota conectándose a ubicaciones distintas. Un estado compartido o recuperable resuelve eso, y el estado compartido es un requisito de diseño y no una prueba de vigilancia.

Nada de esa coordinación requiere historiales de navegación. Una pasarela que reenvía paquetes no necesita saber qué sitios visitó una sesión para contar sesiones, y los dos flujos de datos suelen manejarlos componentes completamente distintos.

Mantener un recuento en memoria tampoco anonimiza los hechos asociados. Mientras el servicio funciona, un registro vinculado a la suscripción revela que una cuenta tiene conexiones activas, y tanto el acceso a ese estado como su duración merecen preguntarse.

Adónde va después ese estado

La pregunta de privacidad no es si el servidor puede contar. Pregunte qué ocurre con una sesión terminada: ¿se elimina el registro o se convierte en un evento de una serie de monitorización? Luego pregunte qué otros componentes vieron el mismo evento, porque los registros de autenticación, los registros de contabilidad y las copias de seguridad pueden guardar cada uno una copia que la ruta de aplicación descartó.

La contabilidad RADIUS es el ejemplo más claro. Un par Start y Stop existe para respaldar la facturación y el control de sesiones, y crea un registro de la conexión sin importar si alguien lo consulta alguna vez como historial. Un servicio que aplica límites mediante contabilidad retiene, por tanto, más que una tabla de espacios por construcción.

La eliminación también tiene forma. Un registro eliminado de la tabla en vivo puede persistir en una copia hecha una hora antes, y el periodo de retención de esa copia es una declaración de política propia. Leer solo el almacén principal da una respuesta incompleta.

Formule la pregunta en términos de campos

La guía de minimización de datos del RFC 6973 vincula los datos recogidos y almacenados con el propósito al que sirven. Aplicada aquí, la pregunta útil es qué campos necesita realmente la tarea de admisión concurrente y qué propósito justifica conservar cada uno después de que esa tarea termine.

Una declaración de servicio precisa separa el estado de conexión en vivo usado para aplicar la cuota de cualquier registro conservado tras la terminación, y nombra los demás sistemas dentro del alcance de la promesa. Una frase que solo dice que se aplican tres conexiones no establece ni que exista un archivo ni que no exista.

Cuando el ciclo de vida no está claro, anótelo como una pregunta de retención sin responder en lugar de un veredicto. La presencia de un límite no es prueba de un historial oculto, y una explicación plausible del estado en vivo no es una auditoría del proveedor.