¿Qué instancia de OpenVPN usa realmente tu perfil de PiVPN?

PiVPN escribe una configuración de servidor y un perfil de cliente, y luego termina; nunca se convierte en el proceso que transporta tu tráfico. Por eso, un handshake fallido, un cliente que marca el extremo equivocado o un servicio que vuelve mal tras un reinicio no se pueden explicar desde los menús del instalador. Esos síntomas pertenecen al demonio de OpenVPN que se ejecuta ahora, a la configuración que ese demonio cargó realmente y al registro al que se le apuntó. Cuatro comandos de solo lectura suelen resolverlo, y ninguno de ellos cambia tus certificados ni tus claves.

El asistente y el demonio son objetos distintos

La confusión es fácil de explicar: un directorio contiene el archivo que generó el asistente, el archivo que lee el demonio y, a veces, una copia obsoleta de ambos. Un asistente es un script de aprovisionamiento. Instala paquetes, escribe archivos de unidad e imprime un perfil de cliente, y luego su trabajo termina. Lo que queda es una entrada del gestor de servicios y una línea de comandos.

En un host systemd, empieza por la unidad activa en lugar del listado del directorio. El nombre depende del empaquetado: las imágenes de Debian y Raspberry Pi OS suelen exponer una instancia de plantilla como openvpn-server@server, mientras que las instalaciones antiguas usan openvpn@server. Pregunta al gestor cuál se ejecuta en lugar de adivinarlo por un nombre de archivo.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lee ExecStart= en esa salida. Nombra el ejecutable y las opciones que el gestor lanza realmente, incluida cualquier --config ruta; un archivo de configuración que está cerca y al que ningún comando hace referencia no forma parte del túnel en funcionamiento.

Sigue la cadena de configuración que resolvió el demonio

OpenVPN no escanea un directorio en busca de ajustes. Lee el archivo que se le pasa con --config, sigue cualquier config directiva dentro de él y luego aplica las opciones de la línea de comandos. El manual de 2.6 describe ese orden, y eso importa cuando dos archivos no coinciden en el puerto, el dispositivo o el cifrado.

Vuelca primero la invocación efectiva y luego mira las directivas que deciden identidad y accesibilidad. Ambos comandos son de solo lectura y seguros en un servidor activo, aunque el segundo imprime rutas que quizá no quieras en un ticket público.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Un archivo .ovpn en un directorio personal es un artefacto de cliente. El demonio del servidor nunca lo lee, así que editar ese archivo para arreglar un fallo de handshake del lado del servidor no consigue nada.

Las inclusiones son la otra trampa. Una línea config incorpora un segundo archivo cuyas opciones se procesan en ese punto, de modo que una directiva posterior de un solo valor puede imponerse sobre lo que el archivo principal parece decir. Si el archivo visible parece correcto y el demonio sigue comportándose distinto, lee el archivo incluido antes de cambiar nada.

Asocia el registro con el proceso, no con el error que recuerdas

Dos destinos de registro son habituales, y solo uno es el journal. Con log-append configurado, el demonio escribe en ese archivo y el journal conserva poco más allá de las líneas de arranque. Sin él, journalctl es la fuente de eventos.

journalctl -u openvpn-server@server -n 80 --no-pager

Correlaciona un intento de conexión con una ventana temporal. Anota el extremo del cliente y luego lee los eventos del servidor de los mismos segundos. Un handshake TLS que nunca llega al intercambio de certificados apunta a accesibilidad o a un desajuste de protocolo, mientras que un rechazo de autenticación llega cuando los parámetros del túnel ya se han acordado.

Una entrada antigua del registro no demuestra nada sobre un perfil que descargaste hace cinco minutos. Regenera el archivo de cliente, conéctate una vez y lee solo las líneas que aparecieron durante ese intento.

Anota el primer fallo concreto en lugar del último genérico. Un error de bind, un intercambio externo sin respuesta, un rechazo de certificado y un rechazo de cuenta te llevan cada uno a una capa distinta, y un tiempo de espera al final suele ocultar el evento útil de arriba.

Reconstruir el túnel no es un paso de diagnóstico

El atajo tentador es levantar un segundo túnel más simple: clave estática, sin certificados, sin autenticación adicional. A menudo conectará, y solo demuestra que dos hosts pueden pasar UDP o TCP entre ellos. No dice nada sobre por qué falla el despliegue autenticado con certificados, y sustituye en silencio el modelo de seguridad que se te pidió mantener.

Lo mismo se aplica a desactivar tls-auth o tls-crypt, relajar verify-x509-name, o eliminar un segundo factor para obtener un estado verde. Un túnel que conecta porque se retiró la verificación es otro sistema, no uno reparado.

Haz un cambio acotado en la capa que nombró el registro, reinicia la misma unidad y repite el único intento de conexión. Eso mantiene honesta la comparación y deja un cambio que puedes revertir.

Qué entregar a la siguiente persona

Anota cuatro datos mientras aún los tienes: la versión de OpenVPN de openvpn --version, la unidad que está activa, la cadena de configuración con sus inclusiones y la ventana de registro que cubre un intento. Esos cuatro convierten una queja vaga en un caso reproducible.

Redacta antes de compartir. Las claves privadas, auth-user-pass y otros archivos, el material de clave estática y los paquetes completos de cliente no pertenecen a un ticket; los nombres de opción y la forma de la cadena suelen bastar para un segundo par de ojos.

Si la cadena está intacta y el registro sigue apuntando a la red, el siguiente paso es el camino entre cliente y servidor en lugar de otra instalación. Esa es la única parte de la historia que el asistente nunca poseyó.