Limites de conexões VPN: estado ao vivo versus histórico retido

Três conexões simultâneas são uma decisão de admissão, e responder a ela exige saber quais slots estão ocupados agora, e não o que aconteceu no mês passado. Um serviço pode recusar uma quarta sessão a partir de uma pequena tabela de registros ativos e nunca construir uma linha do tempo. Isso é uma afirmação sobre o mecanismo, não sobre o operador, e a diferença importa quando você lê uma política de privacidade. O modelo abaixo mostra o que a decisão precisa e o que pode descartar.

O mecanismo: uma tabela de slots, não um registro

A implementação mais simples associa uma assinatura a até três registros de sessão ativos. Cada sessão admitida ocupa um slot, e o slot é liberado quando o serviço decide que aquela sessão terminou. O registro precisa de uma identidade específica o bastante para que liberar uma conexão não libere o slot de outra conexão; por isso o identificador de sessão importa mais que o nome da conta.

Ocupação e histórico são estruturas de dados diferentes. A ocupação responde a uma pergunta de sim ou não sobre o presente e pode ser descartada no momento em que a sessão termina. Um histórico é um fluxo de eventos apenas de acréscimo, e sobrevive porque alguém escolheu mantê-lo. Um serviço pode ter um, ambos ou nenhum.

A distinção é invisível de fora. Um limite de conexões visível é compatível com um contador minúsculo na memória, uma tabela de banco de dados compartilhada e um arquivo completo de eventos com painel. Nada no limite diz qual deles está em execução.

Por que o modelo ao vivo ainda precisa de coordenação

Uma conexão perdida pode não ser reconhecida como encerrada de imediato. O gateway espera um tempo limite, uma falha de keepalive ou uma parada de contabilidade, e até que um deles chegue o slot permanece ocupado. Um usuário que se reconecta nessa janela vê uma recusa que nada tem a ver com um quarto dispositivo.

Um servidor reiniciado precisa reconciliar seu estado, e vários gateways que atendem a mesma conta precisam de uma decisão comum. Caso contrário, uma conta pode exceder sua cota conectando-se a locais diferentes. Estado compartilhado ou recuperável resolve isso, e o estado compartilhado é um requisito de projeto, não uma prova de vigilância.

Nada dessa coordenação exige históricos de navegação. Um gateway que encaminha pacotes não precisa saber quais sites uma sessão visitou para contar sessões, e os dois fluxos de dados costumam ser tratados por componentes completamente diferentes.

Manter um contador na memória também não torna os fatos associados anônimos. Enquanto o serviço funciona, um registro vinculado à assinatura revela que uma conta tem conexões ativas, e tanto o acesso a esse estado quanto sua duração merecem ser questionados.

Para onde esse estado vai depois

A questão de privacidade não é se o servidor consegue contar. Pergunte o que acontece com uma sessão encerrada: o registro é removido, ou vira um evento em uma série de monitoramento? Depois pergunte quais outros componentes viram o mesmo evento, porque registros de autenticação, registros contábeis e backups podem cada um guardar uma cópia que o caminho de aplicação descartou.

A contabilidade RADIUS é o exemplo mais claro. Um par Start e Stop existe para apoiar a cobrança e o controle de sessões, e cria um registro da conexão independentemente de alguém algum dia consultá-lo como histórico. Um serviço que aplica limites por meio da contabilidade retém, portanto, por construção, mais que uma tabela de slots.

A exclusão também tem forma. Um registro removido da tabela ao vivo pode persistir em um backup feito uma hora antes, e o período de retenção desse backup é uma declaração de política própria. Ler apenas o armazenamento primário dá uma resposta incompleta.

Faça a pergunta em termos de campos

A orientação de minimização de dados do RFC 6973 vincula os dados coletados e armazenados à finalidade atendida. Aplicada aqui, a pergunta útil é quais campos a tarefa de admissão simultânea realmente precisa e qual finalidade justifica manter cada um depois que essa tarefa termina.

Uma declaração de serviço precisa separa o estado de conexão ao vivo usado para aplicar a cota de qualquer registro retido após o encerramento, e nomeia os outros sistemas dentro do escopo da promessa. Uma frase que diz apenas que três conexões são aplicadas não estabelece nem que um arquivo existe nem que não existe.

Quando o ciclo de vida não está claro, registre-o como uma pergunta de retenção sem resposta em vez de um veredito. A presença de um limite não é prova de um histórico oculto, e uma explicação plausível do estado ao vivo não é uma auditoria do provedor.