OpenVPN no troba ca.crt tot i que el perfil es carrega

El servei arrenca, llegeix el perfil sense cap queixa i després mor en una línia que sembla no tenir-hi res a veure: no pot obrir ca.crt. Res del certificat no ha canviat, i la ruta del perfil a la unitat és absoluta. Aquesta combinació és la pista. La ruta que heu passat localitza un fitxer, i els noms dins d’aquest fitxer es resolen en un altre lloc del tot, de manera que una llançada que sembla plenament qualificada encara pot llegir les seves claus d’un directori que ningú no volia.

La fallada té pocs causants, i val la pena separar-los per ordre: el directori base que el procés tenia realment, el context de llançament del servei i els permisos o el sandbox al voltant del fitxer un cop la ruta és correcta. Cadascun deixa un rastre diferent: a la unitat, al procés i al sistema de fitxers.

La ruta del perfil no és un directori base

Imagineu un procés que arrenca a /tmp i rep /etc/vpn/prod/tenant-a.ovpn. Dins d’aquest perfil, la línia ca ca.crt anomena una ruta relativa. Res de l’argument que va localitzar el perfil reescriu aquest nom, així que el procés busca /tmp/ca.crt i informa d’un fitxer que falta.

La part confusa és l’ordre dels errors. OpenVPN analitza primer la configuració i obre els fitxers referenciats a mesura que hi arriba, així que una errada d’escriptura al perfil es reporta abans que es toqui cap clau, mentre que un certificat absent només apareix quan l’anàlisi hi arriba. Per tant, un perfil que es carrega és prova que la sintaxi és correcta, no que s’hagin trobat els fitxers que anomena.

Què separa el manual: --config i --cd

El manual d’OpenVPN 2.6 descriu dues opcions diferents. Una carrega un fitxer de configuració. L’altra canvia el directori del procés abans que es llegeixin la configuració, la clau, l’script i altres fitxers, i requereix un directori absolut sense cap referència a l’actual.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

Aquesta invocació és una forma, no una instrucció per llançar el perfil d’algú altre. El que us aporta és determinisme: la base de cada nom relatiu de la cadena s’enuncia a la comanda en lloc d’heretar-se de la shell o del gestor que hagi iniciat el procés. L’alternativa és igual de vàlida i sovint millor per a un servei: deixeu el directori de treball tranquil i feu absolut cada fitxer referenciat dins del perfil.

Tant se val què trieu: auditeu tota la cadena, no la primera fallada. Un perfil pot incorporar un altre fitxer de configuració, i els noms relatius del fitxer inclòs es resolen contra el mateix directori del procés, no contra el directori del fitxer que els ha inclòs. Les rutes de registre, els fitxers d’autenticació i els scripts auxiliars segueixen la mateixa regla.

El servei arrenca en un altre lloc

Una shell interactiva al directori del perfil no demostra res sobre una unitat empaquetada. Els gestors fixen el seu propi directori de treball, i un script embolcall el pot tornar a canviar abans que s’executi el binari. La unitat que falla és l’única llançada sobre la qual val la pena raonar.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

La segona comanda mostra el directori que el procés viu realment manté, cosa més fiable que el fitxer de la unitat quan hi ha un embolcall. Si els dos no coincideixen, l’embolcall és la resposta i la unitat és una pista falsa.

Després de la cerca: permisos, chroot i sandbox

Un directori base correcte encara pot produir el mateix missatge, perquè la resolució i l’accés són passos separats. El procés necessita permís d’execució a cada directori pare i permís de lectura al fitxer, i una unitat de servei que amaga part del sistema de fitxers canvia què pot veure el procés.

Tres variants habituals produeixen el mateix error. El fitxer només és llegible per root mentre el servei deixa anar privilegis abans d’obrir-lo. La unitat estableix una vista protectora del sistema de fitxers que no inclou el directori del perfil. El dimoni s’executa amb chroot, així que la ruta que existeix a l’amfitrió no existeix dins d’aquesta vista.

Diagnostiqueu amb la propietat del fitxer i la identitat del procés, no afluixant permisos. Fer que una clau privada sigui llegible per tothom per silenciar aquest error bescanvia una fallada sorollosa per una de silenciosa, i la clau és la part del directori que menys voleu exposar.

Demostreu la correcció amb la llançada pròpia

Reinicieu la unitat real des d’un directori sense relació amb el perfil i observeu la mateixa línia d’arrencada. Després confirmeu que el procés manté el directori previst mentre s’executa i que el certificat que ha carregat és el que espereu.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

Quan la càrrega de rutes té èxit, l’autenticació i l’encaminament segueixen sent etapes separades amb les seves pròpies fallades, i una connexió que puja però no passa cap trànsit és una altra investigació. La correcció d’aquí només tracta de de quin directori han vingut els fitxers, i hauria de ser visible a la invocació en lloc de recordada per qui la va executar a mà per última vegada.

Si el perfil es desplega amb un gestor de configuració, poseu-hi també el directori base o els noms absoluts dels fitxers. Una correcció manual en un sol amfitrió és la versió d’aquest problema que torna després de la propera reconstrucció.