OpenVPN non arrinca sen erro? Mire o journal

O comando regresa, o servizo aparece como fallido e nada que pareza unha explicación chega ao terminal. Ese silencio é o síntoma que a xente describe como «OpenVPN non arrinca», e case nunca significa que o programa morrese sen dicir nada. Significa que a mensaxe foi a unha canle que non estaba lendo, ou que o que iniciou non era o que configurou. Ambos os casos diagnostícanse en menos dun minuto en canto deixe de tratar o perfil como o sospeitoso.

Catro lugares absorben a saída: o journal da unidade, o complemento que posúe a conexión, o outro extremo do túnel e un binario distinto do que cre que se executa. Cada un ten a súa propia comprobación.

O silencio significa que non estaba mirando a canle correcta

Unha invocación en primeiro plano imprime no seu terminal. Unha unidade imprime no journal, e unha unidade fallida pode saír antes de escribir nada se o fallo está en como se iniciou e non no que se lle dixo. A distinción importa: ningunha entrada no journal significa que o proceso nunca se executou de verdade, mentres que unha entrada seguida dunha saída significa que se executou e rexeitou algo.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Engada systemctl show -p Result -p ExecMainStatus openvpn-client@office para separar unha saída limpa dun sinal. Un estado 1 cun Result=exit-code é unha decisión do programa; Result=signal ou un tempo de espera apuntan máis ben á contorna, e ningunha cantidade de edición do perfil o cambiará. Anote ambos os valores antes de reiniciar nada, porque un reinicio borra o estado transitorio que os produciu.

O nome da instancia forma parte da ruta

A unidade de modelo empaquetada non acepta unha ruta de ficheiro. Acepta un nome de instancia, e ese nome engádese a un directorio para atopar o perfil: office resólvese en /etc/openvpn/client/office.conf no empaquetado de Debian e Ubuntu. Un ficheiro chamado office-v2.conf iniciado como @office nunca se le, e a unidade sae en silencio porque desde o seu punto de vista non había nada que facer. O directorio de busca difire entre o modo cliente e o modo servidor, así que o mesmo erro apunta a un sitio completamente distinto ao cambiar de modelo.

Esa discrepancia é a causa máis común do fallo silencioso, e é invisible no perfil porque o perfil está ben. Enumere o que existe realmente e compare os dous nomes carácter por carácter, incluída calquera extensión que espere o empaquetado.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Se a unidade está habilitada pero non aparece ningunha instancia, a propia habilitación pode referirse a un nome que despois se renomeou. Volver habilitar a instancia correcta adoita abondar, e paga a pena borrar o ficheiro de unidade antigo que queda para que non confunda a seguinte persoa. Un ficheiro de unidade esquecido é unha cousa pequena que despois lle custa unha hora a alguén.

Cando o complemento posúe o túnel, o terminal non ve nada

Unha conexión iniciada desde o applet de escritorio pertence a NetworkManager, e a súa saída de OpenVPN vai ao journal dese servizo en lugar de a calquera shell que teña aberto. Executar o cliente a man e non ver nada é o esperado nesa disposición, porque o proceso executado a man non é o que leva a conexión.

Busque no journal o servizo que o posúe, e despois reproduza a análise cunha verbosidade que poida ler. Os dous comandos seguintes miran a propietarios distintos do mesmo fallo.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

A execución independente serve para ler mensaxes, non para substituír a conexión xestionada, e as dúas difiren despois: a integración de DNS, as rutas e a duración pertencen ao complemento. Corrixir un erro de análise na execución independente non corrixe automaticamente a resolución de nomes cando o applet toma o control, así que manteña as dúas observacións separadas.

Dous binarios, un PATH

Unha compilación manual instalada baixo /usr/local gaña nunha invocación de shell, porque /usr/local/sbin precede a /usr/sbin no PATH predeterminado de Ubuntu. Unha unidade non usa o seu PATH; executa a ruta absoluta escrita en ExecStart. Así que a versión que funciona no seu terminal e a versión que falla como servizo poden ser programas genuinamente distintos.

Compare os dous antes de reconstruír nada. O terceiro comando é o que decide o argumento.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Outra diferenza de contorno escóndese no mesmo sitio. Unha unidade empaquetada depende dun directorio de execución baixo /run que systemd crea para ela; unha unidade de substitución escrita a man que omita ese axuste pode fallar antes de abrir un só ficheiro, e o fallo parece un rexeitamento xenérico sen ningunha mensaxe de OpenVPN.

Fallos que o cliente non pode informar

Algúns resultados decídense no extremo remoto. Unha pasarela que responde cun estado HTTP e pecha a conexión dixoille cal é o seu propio estado, e o seguinte paso útil é o seu rexistro ou a conta detrás da credencial en lugar dos seus ficheiros locais. Nada local está roto nese escenario, e editar o perfil para compensalo fai máis difícil o seguinte diagnóstico. Lea ese rexistro antes de tocar a configuración do cliente.

Outro caso silencioso é un cliente que funciona correctamente. Un túnel en modo cliente nunca escoita nun porto, así que unha comprobación que espere un oínte aberto non informará de nada e parecerá un fallo. Confirme que modo iniciou antes de sacar conclusións dunha lista de portos baleira.

Traballe as capas en orde: existe a unidade e é correcto o nome da instancia, chegou algo ao journal ou ao ficheiro --log, que binario e que perfil se executaron realmente, e o fallo é local ou remoto. Cada resposta elimina unha capa. Empezar polo perfil significa reescribir un ficheiro que quizais nunca se abriu.