¿Qué cuenta como un inicio de sesión VPN correcto en un informe?

Tres informes sobre la misma VPN pueden discrepar sin que ninguno esté equivocado, porque cada uno entiende algo distinto por inicio de sesión correcto. Uno cuenta las conexiones que llegaron al servidor, otro cuenta las identidades que aceptó el paso de autenticación y un tercero cuenta las sesiones que terminaron la inicialización. Elegir uno antes de recoger datos es la diferencia entre una métrica y una discusión.

La pregunta útil no es qué definición es correcta en general, sino sobre qué resultado va a actuar el lector.

Tres sucesos distintos llevan la misma etiqueta

Un servidor acepta una conexión de transporte en cuanto se completa el apretón de manos, y eso ocurre antes de que se presente cualquier credencial. Ese suceso le dice que el puerto es alcanzable y que la ruta de red funciona, y no le dice nada sobre quién se conectó. La autenticación es un paso posterior que puede fallar, y también puede tener éxito para una identidad a la que nunca se le permite entrar en la red.

La inicialización llega después de la autenticación, y un túnel que termina de inicializarse puede quedarse inactivo el resto del día. La solicitud de una aplicación es el único suceso que demuestra que un usuario llegó a algo que quería. Estas etapas se anidan, así que el recuento de la más amplia siempre superará al de la más estrecha. Nada en la secuencia de sucesos demuestra que el usuario fuera productivo, solo que cada puerta se abrió a su vez.

La documentación del producto suele nombrar los estados de forma explícita. La OpenVPN notas de la interfaz de gestión separan la conexión TCP, el resultado de la autenticación y la inicialización completada, que es exactamente la distinción que necesita un informe. Un estado etiquetado como connected no certifica que un recurso compartido o una operación de base de datos tuviera éxito después.

Cuente sesiones, identidades o solicitudes

Decida la unidad antes de decidir el número. Un recuento de sesiones responde cuántas veces se usó el servicio, uno de identidades responde cuántas cuentas distintas aparecieron y uno de solicitudes responde cuánto trabajo se hizo. Los proveedores también lo cuentan de forma distinta, y un derecho medido en usuarios no se puede comparar con un gráfico medido en sesiones. Elegir la unidad equivocada es como un plan de capacidad acaba dimensionado para la cantidad incorrecta.

Las reconexiones son donde los recuentos de sesiones se inflan en silencio. Un cliente que se cae cada pocos minutos y se vuelve a conectar produce decenas de registros de sesión para una sola persona, así que un informe que cuenta sesiones como personas sobreestimará el uso justo en las condiciones en que la fiabilidad es peor. Escriba la regla: una sesión nueva tras una reconexión cuenta por separado, o continúa la anterior dentro de una ventana definida.

Las direcciones son la identidad más débil disponible. Una dirección de túnel puede reasignarse a otro usuario minutos después, y dos usuarios pueden compartir una dirección mediante traducción. Adjunte el identificador de cuenta del suceso de autenticación en lugar de inferir una persona a partir de una dirección en un registro.

Ponga la definición a prueba con un día real

Tome un solo día de registros y cuente el mismo tráfico de tres maneras. Si los tres números están cerca, puede que la definición no importe mucho para su propósito; si difieren en un factor grande, el informe debe decir cuál 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

Ejecute la misma extracción en un día con una caída conocida y compare la forma en lugar del total. Un día en que el enlace ascendente parpadeó debería mostrar un pico en los sucesos de conexión con un aumento moderado de cuentas distintas, y si no lo hace, es probable que el contador esté midiendo algo distinto de lo que afirma el informe.

Conserve la consulta misma junto al resultado. Cualquiera puede reproducir un filtro documentado, y un número sin su filtro no es auditable.

Informe de lo que establece el suceso

Un intento fallido merece su propia categoría en lugar de plegarse hacia cualquiera de los dos lados. Los fallos incluyen contraseñas mal escritas, clientes con un perfil desactualizado y sondeos deliberados, y los tres tienen respuestas distintas. Un fallo no es prueba de una intrusión exitosa, y tampoco es prueba de inocuidad.

Escriba la conclusión con la fuerza que el suceso respalda: esta cuenta se autenticó en este servicio en esta ventana, desde esta fuente, y la sesión llegó a la inicialización. Cualquier cosa sobre lo que el usuario hizo después requiere un registro del lado de la aplicación y no más datos del túnel.

Cuando el informe llega a alguien que tomará una decisión de licencias, capacidad o seguridad, ponga la definición en la primera línea y no en una nota al pie. La definición es el hallazgo, y el número solo tiene sentido dentro de ella.