OpenVPN finn ikkje ca.crt sjølv om profilen blir lasta

Tenesta startar, les profilen utan klager og døyr så på ei linje som verkar urelatert: ho kan ikkje opne ca.crt. Ingenting ved sertifikatet er endra, og profilbanen i unit-fila er absolutt. Nettopp den kombinasjonen er hintet. Banen du oppgav, lokaliserer éi fil, og namna inne i den fila blir løyste heilt andre stader, så ein oppstart som ser fullt kvalifisert ut, kan framleis lese nøklane sine frå ein mappe ingen hadde tenkt seg.

Feilen har få årsaker, og dei er verd å skilje i rekkjefølgje: basiskatalogen prosessen faktisk hadde, oppstartskonteksten til tenesta og løyva eller sandkassen rundt fila når banen først er riktig. Kvar av dei etterlèt eit ulikt spor — i unit-fila, i prosessen og på filsystemet.

Profilstien er ikkje ein basiskatalog

Sjå føre deg ein prosess som startar i /tmp og får /etc/vpn/prod/tenant-a.ovpn. Inne i den profilen nemner linja ca ca.crt ein relativ bane. Ingenting i argumentet som fann profilen, skriv om det namnet, så prosessen leitar etter /tmp/ca.crt og rapporterer ei manglande fil.

Det forvirrande er rekkjefølgja på feila. OpenVPN parsar konfigurasjonen først og opnar refererte filer etter kvart som det når dei, så ein skrivefeil i profilen blir rapportert før nokon nøkkel blir rørt, medan eit manglande sertifikat først dukkar opp når parseringa kjem dit. Ein profil som blir lasta, er derfor prov på at syntaksen er riktig, ikkje at filene han nemner, vart funne.

Kva handboka skil: --config og --cd

Handboka for OpenVPN 2.6 skildrar to ulike val. Det eine lastar ei konfigurasjonsfil. Det andre byter katalogen til prosessen før konfigurasjon, nøkkel, skript og andre filer blir lesne, og krev ein absolutt katalog utan tilvising til den gjeldande.

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

Det kallet er ei form, ikkje ein instruks om å starte nokon annan sin profil. Det du får, er determinisme: basisen for kvart relative namn i kjeda står i kommandoen i staden for å arvast frå kva som helst skjel eller handterar som starta prosessen. Alternativet er like gyldig og ofte betre for ei teneste: lat arbeidskatalogen vere og gjer kvar referert fil absolutt inne i profilen.

Same kva du vel, revider heile kjeda og ikkje den første feilen. Ein profil kan dra inn ei anna konfigurasjonsfil, og dei relative namna i den inkluderte fila blir løyste mot same prosesskatalog, ikkje mot katalogen til fila som inkluderte dei. Loggbanar, autentiseringsfiler og hjelpeskript følgjer same regel.

Tenesta startar ein annan stad

Eit interaktivt skjel i profilkatalogen provar ingenting om ein pakka unit. Handterarar set sin eigen arbeidskatalog, og eit innpakningsskript kan endre han igjen før binæra køyrer. Unit-en som feilar, er den einaste oppstarten det er verd å resonnere om.

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

Den andre kommandoen viser katalogen den levande prosessen faktisk held, og det er meir påliteleg enn unit-fila når ei innpakning er involvert. Viss dei to er usamde, er innpakninga svaret ditt, og unit-fila er eit villspor.

Etter oppslaget: løyve, chroot og sandkasse

Ein riktig basiskatalog kan framleis gi same melding, fordi oppslag og tilgang er separate steg. Prosessen treng køyreløyve på kvar overordna katalog og leseløyve på fila, og ein teneste-unit som skjuler ein del av filsystemet, endrar kva prosessen i det heile kan sjå.

Tre vanlege variantar gir same feil. Fila er berre lesbar for root, medan tenesta gir slepp på privilegium før ho opnar henne. Unit-en set eit vernande filsystemsutsyn som ikkje omfattar profilkatalogen. Daemonen køyrer med chroot, så banen som finst på verten, finst ikkje inne i det utsynet.

Diagnostiser med eigarskapen til fila og identiteten til prosessen, ikkje ved å lempe på løyva. Å gjere ein privat nøkkel lesbar for alle for å dempe denne feilen, byter ein høglydt feil mot ein stille, og nøkkelen er nettopp den delen av katalogen du minst vil eksponere.

Prov rettinga med din eigen oppstart

Start den ekte unit-en på nytt frå ein katalog utan samband med profilen og følg den same oppstartslinja. Stadfest deretter at prosessen held den tiltenkte katalogen medan han køyrer, og at sertifikatet han lasta, er det du ventar.

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

Når innlasting av banar lukkast, er autentisering og ruting framleis separate steg med sine eigne feil, og ei tilkopling som kjem opp men ikkje slepp trafikk gjennom, er ei anna undersøking. Rettinga her gjeld berre kva katalog filene kom frå, og ho bør vere synleg i kallet i staden for å hugsast av den som sist køyrde det for hand.

Viss profilen blir rulla ut av ein konfigurasjonshandterar, legg basiskatalogen eller dei absolutte filnamna der òg. Ei manuell retting på éin vert er versjonen av dette problemet som kjem tilbake etter neste gjenoppbygging.