OpenVPN kan ca.crt nie vind nie, hoewel die profiel laai

Die diens begin, lees die profiel sonder klagte en sterf dan op ’n reël wat onverwant lyk: dit kan nie ca.crt oopmaak nie. Niks aan die sertifikaat het verander nie, en die profielpad in die unit-lêer is absoluut. Daardie kombinasie is die teken. Die pad wat jy deurgegee het, wys een lêer aan, en die name binne daardie lêer word heeltemal elders opgelos, so ’n bekendstelling wat volkome gekwalifiseerd lyk, kan steeds sy sleutels uit ’n gids lees wat niemand bedoel het nie.

Die mislukking het ’n klein aantal oorsake, en dit is die moeite werd om hulle in volgorde te skei: die basisgids wat die proses werklik gehad het, die bekendstellingskonteks van die diens, en die toestemmings of sandbox rondom die lêer sodra die pad reg is. Elkeen laat ’n ander spoor na, in die unit, in die proses en op die lêerstelsel.

Die profielpad is nie ’n basisgids nie

Stel jou ’n proses voor wat in /tmp begin en /etc/vpn/prod/tenant-a.ovpn kry. Binne daardie profiel noem die reël ca ca.crt ’n relatiewe pad. Niks in die argument wat die profiel gelokaliseer het, herskryf daardie naam nie, so die proses soek /tmp/ca.crt en rapporteer ’n vermiste lêer.

Die verwarrende deel is die volgorde van die foute. OpenVPN ontleed eers die konfigurasie en maak verwysde lêers oop soos hy hulle bereik, so ’n tikfout in die profiel word gerapporteer voordat enige sleutel aangeraak word, terwyl ’n ontbrekende sertifikaat eers verskyn wanneer die ontleding so ver kom. ’n Profiel wat laai, is dus bewys dat die sintaksis reg is, nie dat die lêers wat dit noem, gevind is nie.

Wat die handleiding onderskei: --config en --cd

Die OpenVPN 2.6-handleiding beskryf twee verskillende opsies. Die een laai ’n konfigurasielêer. Die ander verander die prosesgids voordat konfigurasie-, sleutel-, script- en ander lêers gelees word, en dit vereis ’n absolute gids met geen verwysing na die huidige een nie.

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

Daardie aanroeping is ’n vorm, nie ’n opdrag om iemand anders se profiel te begin nie. Wat dit vir jou koop, is determinisme: die basis vir elke relatiewe naam in die ketting word in die opdrag genoem eerder as geërf van watter dop of bestuurder die proses ook al begin het. Die alternatief is ewe geldig en dikwels beter vir ’n diens: laat die werkgids alleen en maak elke verwysde lêer absoluut binne die profiel.

Maak nie saak wat jy kies nie, ouditeer die hele ketting eerder as die eerste fout. ’n Profiel kan ’n ander konfigurasielêer intrek, en die ingeslote lêer se relatiewe name word teen dieselfde prosesgids opgelos, nie teen die gids van die lêer wat hulle ingesluit het nie. Logpunte, lêers vir verifikasie en hulpscripts volg dieselfde reël.

Die diens begin op ’n ander plek

’n Interaktiewe dop in die profielgids bewys niks oor ’n verpakte unit nie. Bestuurders stel hulle eie werkgids, en ’n omhulselscript kan dit weer verander voordat die binêre lêer loop. Die unit wat misluk, is die enigste bekendstelling waaroor dit die moeite werd is om te redeneer.

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

Die tweede opdrag wys die gids wat die lewende proses werklik vashou, wat meer betroubaar is as die unit-lêer wanneer ’n omhulsel betrokke is. As die twee nie saamstem nie, is die omhulsel jou antwoord en is die unit ’n afleiding.

Ná die opsoek: toestemmings, chroot en sandboxing

’n Korrekte basisgids kan steeds dieselfde boodskap lewer, want oplossing en toegang is afsonderlike stappe. Die proses het uitvoertoestemming op elke ouergids nodig en leestoestemming op die lêer, en ’n diensunit wat ’n deel van die lêerstelsel wegsteek, verander wat die proses hoegenaamd kan sien.

Drie algemene variante lewer ’n identiese fout. Die lêer is slegs vir root leesbaar terwyl die diens voor die oopmaak van voorregte afstand doen. Die unit stel ’n beskermende lêerstelsel-siening wat nie die profielgids insluit nie. Die daemon loop met ’n chroot, so die pad wat op die gasheer bestaan, bestaan nie binne daardie siening nie.

Diagnoseer met die lêer se eienaarskap en die proses se identiteit, nie deur toestemmings te verslap nie. Om ’n private sleutel wêreldleesbaar te maak om hierdie fout stil te maak, ruil ’n harde mislukking vir ’n stille een, en die sleutel is die deel van die gids wat jy die minste wil blootstel.

Bewys die regstelling met die eie bekendstelling

Herbegin die werklike unit vanuit ’n gids wat nie met die profiel verband hou nie en kyk na dieselfde beginreël. Bevestig dan dat die proses die bedoelde gids vashou terwyl dit loop, en dat die sertifikaat wat dit gelaai het, die een is wat jy verwag.

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

Wanneer padlaai slaag, is verifikasie en roetering steeds aparte fases met hulle eie mislukkings, en ’n verbinding wat opkom maar geen verkeer deurlaat nie, is ’n ander ondersoek. Die regstelling hier gaan net oor uit watter gids die lêers gekom het, en dit moet in die aanroeping sigbaar wees eerder as om onthou te word deur wie dit laas met die hand geloop het.

As die profiel deur ’n konfigurasiebestuurder ontplooi word, sit die basisgids of die absolute lêername ook daar. ’n Handmatige regstelling op een gasheer is die weergawe van hierdie probleem wat ná die volgende herbou terugkeer.