OpenVPN non arrinca: lea a primeira liña, non a configuración

Unha VPN que morre no primeiro segundo é un animal distinto dunha que se conecta e despois falla, e o erro habitual é tratalas como a mesma cousa. Aquí non hai handshake, nin intercambio de certificados, nin ruta que examinar. Unha liña do rexistro decide cal de varias reparacións non relacionadas se aplica, e saltala custa unha tarde editando unha configuración que nunca se leu. Lea esa liña primeiro.

Tres ordes de só lectura lévanlle alí: primeiro journalctl -u openvpn@server -b --no-pager, despois systemctl status openvpn@server, e ss -lunp para os oíntes UDP e os seus propietarios.

A primeira liña escolle a rama

Un conflito de portos e un binario ausente matan o arrinque en menos dun segundo, e deixan primeiras liñas distintas. Unha mensaxe de que o enderezo xa está en uso nomea o porto; un executábel ausente nomea unha ruta que xa non existe; unha condición fallida ou un ficheiro de configuración ausente nomea o ficheiro. Esas tres levan a reparacións distintas, e ningunha mellora reinstalando o cliente. Copie o primeiro fallo nas súas notas antes de executar calquera outra cousa.

Vixía o bucle de reintentos que agocha a liña orixinal. Unha unidade con unha política de reinicio pode enterrar o primeiro fallo baixo unha ducia de idénticos, así que journalctl -b filtrado pola unidade e lido desde arriba supera a cola.

Quen máis ten o porto 1194

O culpable normalmente non é un segundo servidor que alguén configurase a propósito. Espere un cliente iniciado á man aínda vivo noutro terminal, un segundo perfil que escolleu o mesmo porto, ou un paquete de provedor cuxo propio túnel ten o 1194. O propietario do socket aparece en ss -lunp; pase ese PID a systemctl status para saber se unha unidade é responsábel. Báixe-o polo seu propio camiño de control en lugar de cun sinal.

Un sinal a un proceso xestionado por unha unidade adoita provocar un reinicio, e o mesmo fallo reaparece momentos despois como un problema novo. Use systemctl stop para unha unidade, a orde de servizo do propio paquete para unha instalación de provedor, e un sinal só para algo que vostede iniciou á man nesa shell.

Unidades que quedan tras unha purga

Unha purga borra binarios; os ficheiros de unidade escritos á man, normalmente en /etc/systemd/system, sobreviven. Systemd reintenta entón unha unidade que apunta a unha ruta que xa non existe, e a mensaxe refírese a ese ficheiro ausente e non á eliminación de onte. systemctl status mostra a ruta do fragmento da unidade preto de arriba, así que compróbea con dpkg -S antes de borrar nada. Unha vez que o orfo desaparece, systemctl daemon-reload e systemctl reset-failed limpan o estado; se non, cada comprobación de estado posterior herda o.

Cando which openvpn responde con algo baixo /usr/local, o binario en xogo veu dun instalador de provedor e non de apt. Ese instalador adoita traer o seu propio oínte, a súa propia entrada de arrinque e o seu propio directorio de configuración, así que eliminar a orde visible deixa o socket ocupado.

Desinstáleo co que documente o provedor, confirme que o porto está libre con ss -lunp, e engada o cliente da distribución só se o necesita.

Poña o estado en orde antes de reintentar

Limpe o estado de fallo antes de sacar conclusións: systemctl reset-failed elimina os contadores, e systemctl status informa entón do estado actual da unidade e non do seu historial. Iníciea unha vez e lea o rexistro desa instancia en lugar do estado agregado da máquina. Unha unidade que informa de actividade mentres o túnel non transporta nada é un problema aparte, e moito máis común. Os dous fusiónanse nos informes de erros porque ambos acaban co usuario dicindo que a VPN non funciona.

Anote a rama que tomou: conflito de portos, binario ausente, configuración ausente. A próxima vez será máis rápido recoñecela.