Que instancia de OpenVPN está a usar realmente o teu perfil de PiVPN?

PiVPN escribe unha configuración de servidor e un perfil de cliente, e despois sae; nunca se converte no proceso que transporta o teu tráfico. Por iso, un handshake fallido, un cliente que marca o extremo equivocado ou un servizo que volve mal tras un reinicio non se poden explicar desde os menús do instalador. Eses síntomas pertencen ao daemon de OpenVPN que se executa agora, á configuración que ese daemon cargou realmente e ao rexistro ao que se apuntou. Catro ordes de só lectura adoitan resolvelo, e ningunha delas cambia os teus certificados nin as túas claves.

O axudante e o daemon son obxectos distintos

A confusión é doada de explicar: un directorio contén o ficheiro que xerou o axudante, o ficheiro que le o daemon e, ás veces, unha copia obsoleta de ambos. Un axudante é un script de aprovisionamento. Instala paquetes, escribe ficheiros de unidade e imprime un perfil de cliente, e logo o seu traballo remata. O que queda é unha entrada do xestor de servizos e unha liña de ordes.

Nun host systemd, comeza pola unidade activa en lugar do listado do directorio. O nome depende do empaquetado: as imaxes de Debian e Raspberry Pi OS adoitan expor unha instancia de modelo como openvpn-server@server, mentres que as instalacións máis antigas usan openvpn@server. Pregúntalle ao xestor cal se executa en lugar de adiviñalo polo nome dun ficheiro.

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

Le ExecStart= nesa saída. Nomea o executable e as opcións que o xestor lanza realmente, incluída calquera --config ruta; un ficheiro de configuración que está preto e ao que ningún comando fai referencia non forma parte do túnel en funcionamento.

Segue a cadea de configuración que resolveu o daemon

OpenVPN non escanea un directorio na procura de axustes. Le o ficheiro que se lle pasa con --config, segue calquera config directiva dentro del e despois aplica as opcións da liña de ordes. O manual de 2.6 describe esa orde, e iso importa cando dous ficheiros non coinciden no porto, o dispositivo ou o cifrado.

Volve primeiro a invocación efectiva e logo mira as directivas que deciden identidade e accesibilidade. Ambos os comandos son de só lectura e seguros nun servidor activo, aínda que o segundo imprime rutas que quizais non queiras nun 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 ficheiro .ovpn nun directorio persoal é un artefacto de cliente. O daemon do servidor nunca o le, así que editar ese ficheiro para arranxar un fallo de handshake do lado do servidor non consegue nada.

As inclusións son a outra trampa. Unha liña config incorpora un segundo ficheiro cuxas opcións se procesan nese punto, de modo que unha directiva posterior dun só valor pode impoñerse sobre o que o ficheiro principal parece dicir. Se o ficheiro visible parece correcto e o daemon segue comportándose distinto, le o ficheiro incluído antes de cambiar nada.

Asocia o rexistro co proceso, non co erro que recordas

Dous destinos de rexistro son habituais, e só un é o journal. Con log-append configurado, o daemon escribe nese ficheiro e o journal conserva pouco máis alá das liñas de arranque. Sen el, journalctl é a fonte de eventos.

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

Correlaciona un intento de conexión cunha xanela temporal. Anota o extremo do cliente e logo le os eventos do servidor dos mesmos segundos. Un handshake TLS que nunca chega ao intercambio de certificados apunta a accesibilidade ou a un desaxuste de protocolo, mentres que un rexeitamento de autenticación chega cando os parámetros do túnel xa se acordaron.

Unha entrada antiga do rexistro non demostra nada sobre un perfil que descargaches hai cinco minutos. Rexenera o ficheiro de cliente, conéctate unha vez e le só as liñas que apareceron durante ese intento.

Anota o primeiro fallo concreto en lugar do último xenérico. Un erro de bind, un intercambio externo sen resposta, un rexeitamento de certificado e un rexeitamento de conta lévanche cada un a unha capa distinta, e un tempo de espera ao final adoita ocultar o evento útil de arriba.

Reconstruír o túnel non é un paso de diagnóstico

O atallo tentador é levantar un segundo túnel máis simple: clave estática, sen certificados, sen autenticación adicional. A miúdo conectará, e só demostra que dous hosts poden pasar UDP ou TCP entre eles. Non di nada sobre por que falla o despregamento autenticado con certificados, e substitúe en silencio o modelo de seguridade que se che pediu manter.

O mesmo se aplica a desactivar tls-auth ou tls-crypt, relaxar verify-x509-name, ou eliminar un segundo factor para obter un estado verde. Un túnel que conecta porque se retirou a verificación é outro sistema, non un arranxado.

Fai un cambio acoutado na capa que nomeou o rexistro, reinicia a mesma unidade e repite o único intento de conexión. Iso mantén honesta a comparación e deixa un cambio que podes reverter.

Que entregar á seguinte persoa

Anota catro datos mentres aínda os tes: a versión de OpenVPN de openvpn --version, a unidade que está activa, a cadea de configuración coas súas inclusións e a xanela de rexistro que cobre un intento. Eses catro converten unha queixa vaga nun caso reproducible.

Redacta antes de compartir. As claves privadas, auth-user-pass e outros ficheiros, o material de clave estática e os paquetes completos de cliente non pertencen a un ticket; os nomes de opción e a forma da cadea adoitan abondar para un segundo par de ollos.

Se a cadea está intacta e o rexistro segue apuntando á rede, o seguinte paso é o camiño entre cliente e servidor en lugar doutra instalación. Esa é a única parte da historia que o axudante nunca posuíu.