OpenVPN no arrenca: llegiu la primera línia, no la configuració

Una VPN que mor al primer segon és un animal diferent d’una que es connecta i després falla, i l’error habitual és tractar-les com la mateixa cosa. Aquí no hi ha handshake, ni intercanvi de certificats, ni cap ruta per examinar. Una línia del registre decideix quina de diverses reparacions no relacionades s’aplica, i saltar-se-la costa un migdia editant una configuració que mai no s’ha llegit. Llegiu aquesta línia primer.

Tres ordres de només lectura us hi porten: primer journalctl -u openvpn@server -b --no-pager, després systemctl status openvpn@server, i ss -lunp per als oients UDP i els seus propietaris.

La primera línia tria la branca

Un conflicte de ports i un binari absent maten l’arrencada en menys d’un segon, i deixen primeres línies diferents. Un missatge que l’adreça ja s’utilitza anomena el port; un executable absent anomena una ruta que ja no existeix; una condició fallida o un fitxer de configuració absent anomena el fitxer. Aquestes tres porten a reparacions diferents, i cap no millora reinstal·lant el client. Copieu la primera fallada a les notes abans d’executar res més.

Vigileu el bucle de reintents que amaga la línia original. Una unitat amb una política de reinici pot enterrar la primera fallada sota una dotzena d’idèntiques, així que journalctl -b filtrat per la unitat i llegit des de dalt supera la cua.

Qui més té el port 1194

El culpable normalment no és un segon servidor que algú hagi configurat expressament. Espereu un client iniciat a mà encara viu en un altre terminal, un segon perfil que hagi triat el mateix port, o un paquet de proveïdor el túnel propi del qual té el 1194. El propietari del sòcol apareix a ss -lunp; passeu aquest PID a systemctl status per saber si una unitat n’és responsable. Atureu-lo pel seu propi camí de control i no amb un senyal.

Un senyal a un procés gestionat per una unitat normalment provoca un reinici, i la mateixa fallada reapareix moments després com un problema nou. Feu servir systemctl stop per a una unitat, l’ordre de servei del paquet per a una instal·lació de proveïdor, i un senyal només per a allò que hàgiu iniciat a mà en aquesta consola.

Unitats que queden després d’una purga

Una purga esborra binaris; els fitxers d’unitat escrits a mà, normalment a /etc/systemd/system, hi sobreviuen. Llavors el Systemd reintenta una unitat que apunta a una ruta que ja no existeix, i el missatge fa referència a aquest fitxer absent i no a l’eliminació d’ahir. systemctl status mostra la ruta del fragment de la unitat a prop de dalt, així que comproveu-la amb dpkg -S abans d’esborrar res. Un cop l’orfe desapareix, systemctl daemon-reload i systemctl reset-failed netegen l’estat; si no, cada comprovació d’estat posterior l’hereta.

Quan which openvpn respon amb alguna cosa sota /usr/local, el binari en joc ve d’un instal·lador de proveïdor i no d’apt. Aquest instal·lador normalment porta el seu propi oient, la seva pròpia entrada d’arrencada i el seu propi directori de configuració, així que eliminar l’ordre visible deixa el sòcol ocupat.

Desinstal·leu-lo amb el que el proveïdor documenti, confirmeu que el port és lliure amb ss -lunp, i afegiu el client de la distribució només si us cal.

Poseu l’estat en ordre abans de reintentar

Netegeu l’estat de fallada abans de treure’n conclusions: systemctl reset-failed elimina els comptadors, i systemctl status informa llavors de l’estat actual de la unitat i no del seu historial. Inicieu-la un cop i llegiu el registre d’aquesta instància i no l’estat agregat de la màquina. Una unitat que informa d’activitat mentre el túnel no transporta res és un problema a part, i molt més habitual. Els dos es fusionen als informes d’errors perquè tots dos acaben amb l’usuari dient que la VPN no funciona.

Anoteu la branca que heu triat: conflicte de ports, binari absent, configuració absent. La propera vegada serà més ràpid de reconèixer.