status=200/CHDIR: systemd nunca chegou a iniciar OpenVPN

O servizo falla, os rexistros mencionan un spawn e un directorio, e o primeiro instinto é revisar a configuración da VPN. Nese ficheiro aínda non se leu nada. systemd fallou mentres preparaba o proceso, antes de que se executase o executable, así que non se consultou ningún analizador, ningún certificado nin ningún host remoto. Ler o código de estado como unha afirmación sobre systemd en lugar de sobre OpenVPN é o que converte isto nunha investigación breve.

Le o código de estado antes que a aplicación

O código numérico despois do nome do servizo nomea a etapa que fallou. Un fallo de directorio infórmase como estado CHDIR, mentres que un executable que non se puido executar é un código completamente distinto. Os dous parecen iguais nunha liña de resumo e non teñen nada en común nas súas causas.

Esa distinción importa porque as correccións están en ficheiros distintos. Un fallo CHDIR ten que ver cunha ruta e con como a ve o servizo. Un fallo de exec ten que ver co binario, o seu intérprete ou unha montaxe non relacionada. Cambiar o remoto da VPN, a lista de cifrados ou a ruta do certificado non pode resolver ningún dos dous.

Confirma que o fallo é no arranque e non despois dunha execución correcta. Se o servizo funcionaba onte e agora falla na mesma etapa, algo cambiou no directorio, nos seus permisos ou na propia unidade, e ese cambio é a evidencia que hai que buscar.

Pregúntalle á unidade onde quere estar

Le a unidade efectiva en lugar do ficheiro que cres que está instalado, porque os drop-ins poden sobrescribir o directorio de traballo sen que teñas editado nunca a unidade principal. A saída de show responde directamente á pregunta:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Para o modelo do servidor upstream, o directorio de traballo é o directorio de configuración do servidor e o nome da instancia selecciona o perfil que hai dentro. Unha instancia chamada branch, por tanto, espera o seu propio ficheiro nese mesmo directorio, e un perfil colocado noutro sitio non cumpre en absoluto o requisito do directorio de traballo.

Compara o que pide a unidade co que existe. Unha ruta que antes existía, unha ligazón simbólica que agora apunta a outro sitio ou un nome de instancia que xa non coincide cun directorio son cambios correntes que producen exactamente este fallo.

Comproba a ruta tal como a ve o servizo

A túa shell e o servizo non comparten a mesma vista do sistema de ficheiros. Un directorio raíz ou unha imaxe raíz configurados cambian o que significa unha ruta absoluta dentro da unidade, e unha ruta que está obviamente presente no host pode faltar nese espazo de nomes. Le os axustes da unidade antes de fiarte dunha proba manual.

Os permisos agravan o problema. O servizo execútase como un usuario concreto, e ese usuario debe poder atravesar cada directorio pai para chegar ao obxectivo, non só ler o obxectivo en si. Un directorio lexible por root e non atravesable polo usuario do servizo produce un fallo que parece unha ruta inexistente.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Os axustes de endurecemento tamén forman parte deste cadro. Unha unidade que oculta os directorios persoais ou fai de só lectura unha parte do sistema de ficheiros fai exactamente o que se lle configurou, e o directorio de traballo debe vivir nun lugar que o sandbox aínda expoña.

Corrixe o propietario e despois espera outro erro

Corrixe a disposición ou a unidade a través de quen posúa esa configuración. Mover un perfil ao directorio esperado é unha corrección lexítima cando a disposición é incorrecta, pero non explica un directorio ao que non se pode entrar, así que non o trates como a resposta xeral.

Resiste o atallo de ampliar os permisos na árbore de configuración ou de eliminar o sandbox. Ambos fan desaparecer o síntoma mentres eliminan as proteccións que se puxeron alí deliberadamente, e o seguinte fallo será máis difícil de interpretar.

Reinicia a instancia e le o seguinte evento en lugar de dar por feito o éxito. O seguinte erro probable é que OpenVPN non poida abrir o seu ficheiro de configuración, o cal é un avance: entrouse no directorio de traballo e o analizador xa se executa. Segue a cartografía real de ficheiros da unidade desde aí en lugar de volver á resolución de problemas de rede.

A referencia de execución de systemd define como se interpreta o directorio de traballo xunto cos directorios raíz e o illamento. O patrón que hai que recordar é simple: cada código de estado nomea unha etapa distinta, e só os erros propios da aplicación describen a aplicación.