O que conta como um login VPN bem-sucedido num relatório?

Três relatórios sobre a mesma VPN podem divergir sem que nenhum esteja errado, porque cada um entende algo diferente por login bem-sucedido. Um conta as ligações que chegaram ao servidor, outro conta as identidades que o passo de autenticação aceitou e um terceiro conta as sessões que concluíram a inicialização. Escolher um deles antes de recolher dados é a diferença entre uma métrica e uma discussão.

A pergunta útil não é qual definição está correta em geral, mas sobre que resultado o leitor vai agir.

Três eventos diferentes usam a mesma etiqueta

Um servidor aceita uma ligação de transporte assim que o aperto de mão termina, e isso acontece antes de qualquer credencial ser apresentada. Esse evento diz-lhe que a porta está acessível e que o caminho de rede funciona, e não diz nada sobre quem se ligou. A autenticação é um passo posterior que pode falhar, e também pode ter sucesso para uma identidade a quem nunca é permitido entrar na rede.

A inicialização vem depois da autenticação, e um túnel que terminou a inicialização pode ficar inativo pelo resto do dia. O pedido de uma aplicação é o único evento que demonstra que um utilizador chegou a algo que queria. Estas fases estão encaixadas umas nas outras, por isso a contagem da mais ampla excederá sempre a da mais estreita. Nada na sequência de eventos prova que o utilizador foi produtivo, apenas que cada porta se abriu por sua vez.

A documentação do produto costuma nomear os estados de forma explícita. As notas da interface de gestão do OpenVPN separam a ligação TCP, o resultado da autenticação e a inicialização concluída, que é exatamente a distinção de que um relatório precisa. Um estado rotulado como connected não certifica que uma partilha de ficheiros ou uma operação de base de dados tivesse sucesso depois.

Conte sessões, identidades ou pedidos

Decida a unidade antes de decidir o número. Uma contagem de sessões responde a quantas vezes o serviço foi usado, uma contagem de identidades responde a quantas contas distintas apareceram e uma contagem de pedidos responde a quanto trabalho foi feito. Os fornecedores também as contam de forma diferente, e um direito medido em utilizadores não é comparável com um gráfico medido em sessões. Escolher a unidade errada é como um plano de capacidade acaba dimensionado para a quantidade errada.

As reconexões são onde as contagens de sessões incham em silêncio. Um cliente que cai a cada poucos minutos e se volta a ligar produz dezenas de registos de sessão para uma só pessoa, por isso um relatório que conta sessões como pessoas sobrestimará o uso exatamente nas condições em que a fiabilidade é pior. Escreva a regra: uma nova sessão após uma reconexão conta em separado, ou continua a anterior dentro de uma janela definida.

Os endereços são a identidade mais fraca disponível. Um endereço de túnel pode ser reatribuído a outro utilizador minutos depois, e dois utilizadores podem partilhar um endereço através de tradução. Anexe o identificador de conta do evento de autenticação em vez de inferir uma pessoa a partir de um endereço no registo.

Ponha a definição à prova num dia real

Pegue num único dia de registos e conte o mesmo tráfego de três formas. Se os três números estiverem próximos, a definição pode não importar muito para o seu objetivo; se diferirem por um fator grande, o relatório tem de dizer qual usa.

journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l

Execute a mesma extração num dia com uma falha conhecida e compare a forma em vez do total. Um dia em que a ligação ascendente oscilou deveria mostrar um pico nos eventos de ligação com um aumento moderado de contas distintas, e se não o fizer, é provável que o contador esteja a medir outra coisa que não o que o relatório afirma.

Guarde a consulta em si ao lado do resultado. Qualquer pessoa pode reproduzir um filtro documentado, e um número sem o seu filtro não é auditável.

Relate o que o evento estabelece

Uma tentativa falhada merece a sua própria categoria em vez de ser dobrada para qualquer dos lados. As falhas incluem palavras-passe mal escritas, clientes com um perfil desatualizado e sondagens deliberadas, e as três têm respostas diferentes. Uma falha não é prova de uma intrusão bem-sucedida, e também não é prova de inocuidade.

Escreva a conclusão com a força que o evento sustenta: esta conta autenticou-se neste serviço nesta janela, a partir desta fonte, e a sessão chegou à inicialização. Qualquer coisa sobre o que o utilizador fez depois exige um registo do lado da aplicação e não mais dados do túnel.

Quando o relatório vai para alguém que vai tomar uma decisão de licenciamento, capacidade ou segurança, ponha a definição na primeira linha e não numa nota de rodapé. A definição é a descoberta, e o número só faz sentido dentro dela.