OpenVPN kin ca.crt net fine, ek al laden it profyl

De tsjinst start, lêst it profyl sûnder klachten en stjert dan op in rigel dy’t net besibbe liket: hy kin ca.crt net iepenje. Oan it sertifikaat is neat feroare, en it profylpaad yn de unit-datotekst is absolút. Krekt dy kombinaasje is it teken. It paad dat jo joegen, pleatst ien bestân, en de namen yn dat bestân wurde hielendal earne oars oplost, sadat in lansearring dy’t folslein kwalifisearre liket, dochs syn kaaien lêze kin út in map dy’t nimmen bedoelde.

De mislearring hat in pear oarsaken, en it is de muoite wurdich se op folchoarder te skieden: de basismap dy’t it proses wier hie, de lansearringskontekst fan de tsjinst en de rjochten of sandbox om it bestân hinne as it paad ienris goed is. Elk lit in oare spoar nei — yn de unit, yn it proses en op it bestânssysteem.

It profylpaad is gjin basismap

Stel jo in proses foar dat yn /tmp begjint en /etc/vpn/prod/tenant-a.ovpn krijt. Yn dat profyl neamt de rigel ca ca.crt in relatyf paad. Neat yn it argumint dat it profyl fûn, skriuwt dy namme oer, dus it proses siket /tmp/ca.crt en meldt in ûntbrekkend bestân.

Ferwarrend is de folchoarder fan de flaters. OpenVPN parsearret earst de konfiguraasje en iepenet ferwiisde bestannen sa’t it se berikt, sadat in typflater yn it profyl melde wurdt foardat ien kaai oanrekke is, wylst in ûntbrekkend sertifikaat pas ferskynt as it parsearjen sa fier komt. In profyl dat laadt, is dus bewiis dat de syntaksis goed is, net dat de bestannen dy’t it neamt fûn binne.

Wat de hânlieding skiedt: --config en --cd

De hânlieding fan OpenVPN 2.6 beskriuwt twa ferskillende opsjes. Ien laadt in konfiguraasjebestân. De oare feroaret de map fan it proses foardat konfiguraasje, kaai, script en oare bestannen lêzen wurde, en freget in absolute map sûnder ferwizing nei de hjoeddeistige.

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

Dy oanrop is in foarm, gjin opdracht om it profyl fan in oar te starten. Wat it jo jout is determinisme: de basis foar elke relatyf namme yn de keatling stiet yn it kommando yn stee fan urven te wurden fan hokker shell of behearder it proses ek start is. It alternatyf is like jildich en faak better foar in tsjinst: lit de wurkmap gewurde en meitsje elk ferwiisd bestân absolút yn it profyl.

Hokker jo ek kieze, kontrolearje de hiele keatling yn stee fan de earste mislearring. In profyl kin in oar konfiguraasjebestân oanlûke, en de relative namen fan it opnommen bestân wurde oplost tsjin deselde prosesmap, net tsjin de map fan it bestân dat se opnaam. Lochnaden, autentikaasjebestannen en helperscripts folgje deselde regel.

De tsjinst start earne oars

In ynteraktive shell yn de profylmap bewiist neat oer in pakket unit. Behearders sette har eigen wurkmap, en in wrapper-script kin dy noch ris feroarje foardat de binary rint. De unit dy’t mislearret is de iennige lansearring dêr’t it sin hat oer te riddenearjen.

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

It twadde kommando lit de map sjen dy’t it libjende proses wier hâldt, en dat is betrouberder as de unit-datotekst as der in wrapper yn it spul is. As de twa it net iens binne, is de wrapper jo antwurd en is de unit in falsk spoar.

Nei it sykjen: rjochten, chroot en sandbox

In goede basismap kin dochs deselde melding jaan, want oplossing en tagong binne aparte stappen. It proses hat útfierrjocht op elke âldermap nedich en lêsrjocht op it bestân, en in tsjinst-unit dy’t in part fan it bestânssysteem ferstoppet, feroaret wat it proses hielendal sjen kin.

Trije gewoane farianten jouwe deselde flater. It bestân is allinnich foar root lêsber wylst de tsjinst foar it iepenjen rjochten ôfstiet. De unit set in beskermjende bestânssysteemwerjefte dy’t de profylmap net omfettet. De daemon rint mei chroot, dus it paad dat op de host bestiet, bestiet net yn dy werjefte.

Diagnostisearje mei it eigenskip fan it bestân en de identiteit fan it proses, net troch rjochten losser te meitsjen. In privee kaai foar elkenien lêsber meitsje om dizze flater stil te krijen ruilet in lûde mislearring foar in stille, en de kaai is krekt it part fan de map dat jo it minst bleatstelle wolle.

Bewiis de oplossing mei de eigen lansearring

Start de echte unit op ’e nij út in map sûnder ferbân mei it profyl en besjoch deselde startrigel. Befêstigje dan dat it proses by it rinnen de bedoelde map hâldt en dat it sertifikaat dat it laden hat, is wat jo ferwachtsje.

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

As it laden fan paden slagget, binne autentikaasje en routing noch hieltyd aparte fazen mei har eigen mislearrings, en in ferbining dy’t opkomt mar gjin ferkear trochlit, is in oar ûndersyk. De oplossing hjir giet allinnich oer út hokker map de bestannen kamen, en dy moat sichtber wêze yn it oanrop yn stee fan ûntholden te wurden troch wa’t it foar it lêst by de hân rûn hat.

As it profyl troch in konfiguraasjebehearder útrôle wurdt, set dan de basismap of de absolute bestânsnammen dêr ek. In hânmjittige oplossing op ien host is de ferzje fan dit probleem dy’t nei de folgjende werbou weromkomt.