OpenVPN iniciouse pero non imprimiu nada: revise primeiro log-append

Inicia OpenVPN desde unha shell cun ficheiro de configuración, e o terminal queda sen ningunha saída. Nin banner, nin erro, nin indicador. O instinto di que o lanzamento fallou, así que inicia outra copia, logo outra, e a máquina acaba con varias instancias a medio configurar. Antes de nada, revise o perfil en busca dunha directiva que xa redirixise o rexistro a outro lugar. O silencio é unha propiedade da consola, non do proceso.

O silencio ten dúas explicacións moi distintas

A primeira é que o proceso funciona ben e escribe nun ficheiro que vostede non está a observar. A segunda é que saíu de inmediato cun erro rexistrado nese mesmo ficheiro.

Ambas deixan un terminal baleiro, e unha soa pregunta sepáraas: hai un proceso agora e que hai no ficheiro ao que se lle dixo que escribise. Responda iso antes de tocar de novo a configuración. Relanzar para obter saída é como dúas instancias acaban pelexando por un dispositivo de túnel e o mesmo porto, o que produce erros que non teñen nada que ver co problema orixinal.

Atope a directiva e logo atope o proceso.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Atope o destino que usa o proceso en execución

Lea o perfil co que realmente se iniciou o proceso, non o que editou. Unha instancia xestionada por un servizo adoita cargar unha ruta distinta e executarse cun directorio de traballo distinto, así que un nome de ficheiro relativo resólvese nun lugar que non esperaba.

Unha directiva cd explícita agudiza esa distinción, porque a ruta relativa móvese co cambio de directorio. Se herdou esta configuración, o ficheiro pode estar nun lugar onde agora ninguén o buscaría.

Compare a hora de modificación do ficheiro co momento en que o lanzou. Un rexistro da semana pasada é evidencia sobre a semana pasada. Logo lea as últimas liñas do ficheiro que cambiou e trate o que haxa alí como a mensaxe de inicio que lle faltaba.

log fronte a log-append: evidencia e borrado

log-append engade ao que xa hai no ficheiro. log abre o ficheiro para escribir e trúncao, así que cambiar entre ambos pode borrar a execución que estaba a piques de ler.

Se alguén cambiou a directiva mentres depuraba, a evidencia anterior xa se foi e o tamaño do ficheiro parecerá sospeitosamente pequeno. Paga a pena sabelo antes de comparar dúas execucións e concluír que algo cambiou. Borre un rexistro a propósito ou consérveo, pero saiba cal das dúas cousas fixo. A evidencia que eliminou deliberadamente é máis fácil de razoar que a que perdeu por accidente.

Ningunha das dúas opcións crea directorios principais que falten, e ningunha concede acceso mediante permisos do sistema de ficheiros ou un sandbox de servizo. Unha ruta que na configuración parece correcta pode seguir sen ser escribible pola conta coa que se executa o daemon, e nese caso o daemon pode fallar antes de poder informar de nada. Comprobe se o directorio existe e quen é o seu propietario antes de supor que o problema é o nome do ficheiro.

Cando un envoltorio de servizo captura a saída

Baixo systemd, a saída estándar e o erro van ao journal salvo que unha directiva de ficheiro explícita teña prioridade, e un envoltorio do provedor pode capturalos nun lugar completamente distinto.

Por iso o mesmo perfil compórtase de forma distinta desde unha shell e desde unha unidade. A contorna da unidade, o seu directorio de traballo e os seus fluxos estándar difiren da súa shell interactiva. Unha ruta relativa pode resolverse nun contexto e non chegar a ningún sitio no outro. Lea a definición da unidade cando os dous discrepen, non o perfil.

Compare as dúas formas de lanzalo en lugar de concluír que unha delas está rota. Lea a liña de ordes da unidade e a súa contorna, e logo lea o journal para a mesma xanela de tempo. Se o envoltorio redirixe a saída ao seu propio ficheiro, ese ficheiro é agora o seu rexistro, e as directivas de OpenVPN son irrelevantes para onde foron as mensaxes.

Suba a verbosidade só cando xa poida lela

Aumentar a verbosidade antes de atopar o destino só produce máis texto nun lugar que non está mirando.

Unha vez que saiba onde vai parar a saída, un nivel moderado mostra que o perfil se está analizando e que se intenta a conexión. Dous ou tres bastan para un problema de inicio. Os niveis máis altos gañan o seu sitio cando o fallo é un detalle da negociación, e ademais fan medrar o ficheiro de presa.

Logo lea o erro real. Un terminal silencioso non demostra nada sobre se o túnel subiu, e o fallo rexistrado no ficheiro é o que merece a pena corrixir.