Que conta como un inicio de sesión VPN correcto nun informe?

Tres informes sobre a mesma VPN poden discrepar sen que ningún estea equivocado, porque cada un entende algo distinto por inicio de sesión correcto. Un conta as conexións que chegaron ao servidor, outro conta as identidades que aceptou o paso de autenticación e un terceiro conta as sesións que remataron a inicialización. Escoller un antes de recoller datos é a diferenza entre unha métrica e unha discusión.

A pregunta útil non é que definición é correcta en xeral, senón sobre que resultado vai actuar o lector.

Tres acontecementos distintos levan a mesma etiqueta

Un servidor acepta unha conexión de transporte en canto se completa o apretón de mans, e iso ocorre antes de que se presente calquera credencial. Ese acontecemento dille que o porto é alcanzable e que a ruta de rede funciona, e non lle di nada sobre quen se conectou. A autenticación é un paso posterior que pode fallar, e tamén pode ter éxito para unha identidade á que nunca se lle permite entrar na rede.

A inicialización chega despois da autenticación, e un túnel que remata de inicializarse pode quedar inactivo o resto do día. A solicitude dunha aplicación é o único acontecemento que demostra que un usuario chegou a algo que quería. Estas etapas aníñanse, así que o reconto da máis ampla sempre superará o da máis estreita. Nada na secuencia de acontecementos demostra que o usuario fose produtivo, só que cada porta se abriu á súa vez.

A documentación do produto adoita nomear os estados de forma explícita. A documentación da interface de xestión de OpenVPN separa a conexión TCP, o resultado da autenticación e a inicialización completada, que é exactamente a distinción que necesita un informe. Un estado etiquetado como connected non certifica que un recurso compartido ou unha operación de base de datos tivese éxito despois.

Conte sesións, identidades ou solicitudes

Decida a unidade antes de decidir o número. Un reconto de sesións responde cantas veces se usou o servizo, un de identidades responde cantas contas distintas apareceron e un de solicitudes responde canto traballo se fixo. Os provedores tamén o contan de forma distinta, e un dereito medido en usuarios non se pode comparar cun gráfico medido en sesións. Escoller a unidade equivocada é como un plan de capacidade acaba dimensionado para a cantidade incorrecta.

As reconexións son onde os recontos de sesións se inflan en silencio. Un cliente que cae cada poucos minutos e se volve conectar produce decenas de rexistros de sesión para unha soa persoa, así que un informe que conta sesións como persoas sobreestimará o uso xusto nas condicións en que a fiabilidade é peor. Escriba a regra: unha sesión nova tras unha reconexión conta por separado, ou continúa a anterior dentro dunha xanela definida.

Os enderezos son a identidade máis feble dispoñible. Un enderezo de túnel pode reasignarse a outro usuario minutos despois, e dous usuarios poden compartir un enderezo mediante tradución. Engada o identificador de conta do acontecemento de autenticación en lugar de inferir unha persoa a partir dun enderezo nun rexistro.

Poña a definición a proba cun día real

Colla un só día de rexistros e conte o mesmo tráfico de tres maneiras. Se os tres números están preto, pode que a definición non importe moito para o seu propósito; se difiren nun factor grande, o informe debe dicir cal 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 extracción nun día cunha caída coñecida e compare a forma en lugar do total. Un día en que a ligazón ascendente parpadeou debería mostrar un pico nos acontecementos de conexión cun aumento moderado de contas distintas, e se non o fai, é probable que o contador estea medindo algo distinto do que afirma o informe.

Conserve a consulta mesma xunto ao resultado. Calquera pode reproducir un filtro documentado, e un número sen o seu filtro non é auditable.

Informe do que establece o acontecemento

Un intento fallido merece a súa propia categoría en lugar de pregala cara a calquera dos dous lados. Os fallos inclúen contrasinais mal escritos, clientes cun perfil desactualizado e sondaxes deliberadas, e os tres teñen respostas distintas. Un fallo non é proba dunha intrusión exitosa, e tampouco é proba de inocuidade.

Escriba a conclusión coa forza que o acontecemento respalda: esta conta autenticouse neste servizo nesta xanela, desde esta fonte, e a sesión chegou á inicialización. Calquera cousa sobre o que o usuario fixo despois require un rexistro do lado da aplicación e non máis datos do túnel.

Cando o informe chega a alguén que vai tomar unha decisión de licenzas, capacidade ou seguridade, poña a definición na primeira liña e non nunha nota ao pé. A definición é o achado, e o número só ten sentido dentro dela.