OpenVPN no arrenca sense cap error? Mireu el journal

L’ordre torna, el servei apareix com a fallit i res que sembli una explicació arriba al terminal. Aquest silenci és el símptoma que la gent descriu com «OpenVPN no arrenca», i gairebé mai no vol dir que el programa hagi mort sense dir res. Vol dir que el missatge va anar a un canal que no estàveu llegint, o que allò que vau iniciar no era allò que vau configurar. Els dos casos es poden diagnosticar en menys d’un minut un cop deixeu de tractar el perfil com el sospitós.

Quatre llocs absorbeixen la sortida: el journal de la unitat, el connector que posseeix la connexió, l’altre extrem del túnel i un binari diferent del que creieu que s’executa. Cadascun té la seva pròpia comprovació.

El silenci vol dir que no estàveu mirant el canal correcte

Una invocació en primer pla imprimeix al terminal. Una unitat imprimeix al journal, i una unitat fallida pot sortir abans d’escriure res si la fallada és en com es va iniciar i no en el que se li va dir. La distinció importa: cap entrada al journal vol dir que el procés mai no es va executar, mentre que una entrada seguida d’una sortida vol dir que es va executar i va rebutjar alguna cosa.

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

Afegiu systemctl show -p Result -p ExecMainStatus openvpn-client@office per separar una sortida neta d’un senyal. Un estat 1 amb un Result=exit-code és una decisió del programa; Result=signal o un temps d’espera assenyalen l’entorn, i cap quantitat d’edició del perfil no ho canviarà. Anoteu tots dos valors abans de reiniciar res, perquè un reinici esborra l’estat transitori que els va produir.

El nom de la instància forma part del camí

La unitat de plantilla empaquetada no accepta un camí de fitxer. Accepta un nom d’instància, i aquest nom s’afegeix a un directori per trobar el perfil: office es resol a /etc/openvpn/client/office.conf en l’empaquetatge de Debian i Ubuntu. Un fitxer anomenat office-v2.conf iniciat com a @office no es llegeix mai, i la unitat surt en silenci perquè des del seu punt de vista no hi havia res a fer. El directori de cerca difereix entre el mode client i el mode servidor, així que el mateix error assenyala un lloc completament diferent quan canvieu de plantilla.

Aquesta discrepància és la causa més comuna de la fallada silenciosa, i és invisible al perfil perquè el perfil és correcte. Llisteu què existeix realment i compareu els dos noms caràcter per caràcter, incloent-hi qualsevol extensió que esperi l’empaquetatge.

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

Si la unitat està habilitada però no hi ha cap instància llistada, l’habilitació mateixa pot fer referència a un nom que després es va canviar. Tornar a habilitar la instància correcta sol ser suficient, i val la pena esborrar el fitxer de unitat antic que queda perquè no confongui la següent persona. Un fitxer de unitat oblidat és una cosa petita que després costa una hora a algú.

Quan el connector posseeix el túnel, el terminal no veu res

Una connexió iniciada des de l’applet d’escriptori la posseeix NetworkManager, i la seva sortida d’OpenVPN va al journal d’aquest servei i no a cap shell que tingueu obert. Executar el client a mà i no veure res és l’esperat en aquesta disposició, perquè el procés executat a mà no és el que porta la connexió.

Cerqueu al journal el servei que el posseeix, i després reproduïu l’anàlisi amb una verbositat que pugueu llegir. Les dues ordres següents miren propietaris diferents de la mateixa fallada.

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

L’execució independent serveix per llegir missatges, no per substituir la connexió gestionada, i les dues difereixen després: la integració de DNS, les rutes i la durada pertanyen al connector. Corregir un error d’anàlisi en l’execució independent no corregeix automàticament la resolució de noms quan l’applet pren el control, així que manteniu les dues observacions separades.

Dos binaris, un PATH

Una compilació manual instal·lada sota /usr/local guanya en una invocació de shell, perquè /usr/local/sbin precedeix /usr/sbin al PATH per defecte d’Ubuntu. Una unitat no utilitza el vostre PATH; executa el camí absolut escrit a ExecStart. Per tant, la versió que funciona al terminal i la versió que falla com a servei poden ser programes genuïnament diferents.

Compareu els dos abans de reconstruir res. La tercera ordre és la que decideix l’argument.

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

Una altra diferència d’entorn s’amaga al mateix lloc. Una unitat empaquetada depèn d’un directori d’execució sota /run que systemd crea per a ella; una unitat de substitució escrita a mà que ometi aquest paràmetre pot fallar abans d’obrir un sol fitxer, i la fallada sembla un rebuig genèric sense cap missatge d’OpenVPN.

Fallades que el client no pot informar

Alguns resultats es decideixen a l’altre extrem. Una passarel·la que respon amb un estat HTTP i tanca la connexió us ha explicat el seu propi estat, i el següent pas útil és el seu registre o el compte darrere de la credencial, no els vostres fitxers locals. En aquest escenari no hi ha res local trencat, i editar el perfil per compensar-ho fa més difícil el diagnòstic següent. Llegiu aquest registre abans de tocar la configuració del client.

Un altre cas silenciós és un client que funciona correctament. Un túnel en mode client no escolta mai en un port, així que una comprovació que esperi un oient obert no informarà de res i semblarà una fallada. Confirmeu quin mode vau iniciar abans de treure conclusions d’una llista de ports buida.

Treballeu les capes per ordre: existeix la unitat i és correcte el nom de la instància, ha arribat res al journal o al fitxer --log, quin binari i quin perfil s’han executat realment, i si la fallada és local o remota. Cada resposta elimina una capa. Començar pel perfil vol dir reescriure un fitxer que potser mai no s’ha obert.