OpenVPN kan ikke finde ca.crt, selvom profilen indlæses

Tjenesten starter, læser profilen uden klager og dør derefter på en linje, der ser uvedkommende ud: den kan ikke åbne ca.crt. Intet ved certifikatet er ændret, og profilens sti i unit-filen er absolut. Den kombination er tegnet. Stien, du gav, lokaliserer én fil, og navnene inde i den fil slås op helt andre steder, så en opstart, der ser fuldt kvalificeret ud, kan stadig læse sine nøgler fra en mappe, som ingen havde tænkt på.

Fejlen har få årsager, og de er værd at skille ad i rækkefølge: den basismappe, processen faktisk havde, tjenestens opstartskontekst og tilladelserne eller sandkassen omkring filen, når stien er rigtig. Hver især efterlader et forskelligt spor — i unit-filen, i processen og på filsystemet.

Profilstien er ikke en basismappe

Forestil dig en proces, der starter i /tmp og får udleveret /etc/vpn/prod/tenant-a.ovpn. Inde i den profil angiver linjen ca ca.crt en relativ sti. Intet i det argument, der fandt profilen, omskriver det navn, så processen leder efter /tmp/ca.crt og rapporterer en manglende fil.

Det forvirrende er rækkefølgen af fejl. OpenVPN parser først konfigurationen og åbner de refererede filer, efterhånden som den når dem, så en tastefejl i profilen rapporteres, før nogen nøgle røres, mens et manglende certifikat først dukker op, når parsingen når dertil. En profil, der indlæses, er derfor bevis på, at syntaksen er i orden, ikke på at filerne, den navngiver, blev fundet.

Hvad manualen skelner: --config og --cd

Manualen til OpenVPN 2.6 beskriver to forskellige muligheder. Den ene indlæser en konfigurationsfil. Den anden skifter processens mappe, før konfiguration, nøgle, script og andre filer læses, og den kræver en absolut mappe uden henvisning til den nuværende.

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

Det kald er en form, ikke en instruktion om at starte en andens profil. Det, du får, er determinisme: basis for hvert relativt navn i kæden står i kommandoen i stedet for at være arvet fra den shell eller manager, der startede processen. Alternativet er lige så gyldigt og ofte bedre for en tjeneste: lad arbejdsmappen være og gør hver refereret fil absolut inde i profilen.

Uanset hvad du vælger, skal du revidere hele kæden og ikke den første fejl. En profil kan trække en anden konfigurationsfil ind, og den inkluderede fils relative navne slås op mod den samme procesmappe, ikke mod mappen for den fil, der inkluderede dem. Logstier, godkendelsesfiler og hjælpescripts følger samme regel.

Tjenesten starter et andet sted

En interaktiv shell i profilmappen beviser intet om en pakket unit. Managere sætter deres egen arbejdsmappe, og et wrapper-script kan ændre den igen, før binæren kører. Den unit, der fejler, er den eneste opstart, der er værd at ræsonnere om.

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

Den anden kommando viser den mappe, den levende proces faktisk holder, og det er mere troværdigt end unit-filen, når en wrapper er involveret. Hvis de to er uenige, er wrapperen dit svar, og unit-filen er et vildspor.

Efter opslaget: tilladelser, chroot og sandkasse

En korrekt basismappe kan stadig give samme besked, fordi opslag og adgang er separate trin. Processen skal have køretilladelse på hver forældremappe og læsetilladelse på filen, og en service-unit, der skjuler en del af filsystemet, ændrer, hvad processen overhovedet kan se.

Tre almindelige varianter giver den samme fejl. Filen er kun læsbar for root, mens tjenesten opgiver privilegier, før den åbner den. Unit-filen sætter et beskyttende filsystemsyn, der ikke omfatter profilmappen. Daemonen kører med chroot, så stien, der findes på værten, findes ikke inde i det syn.

Diagnostiser med filens ejerskab og processens identitet, ikke ved at lempe tilladelserne. At gøre en privat nøgle læsbar for alle for at bringe denne fejl til tavshed bytter en højlydt fejl for en stille, og nøglen er netop den del af mappen, du mindst vil blotte.

Bevis rettelsen med din egen opstart

Genstart den rigtige unit fra en mappe uden forbindelse til profilen og se den samme opstartslinje. Bekræft derefter, at processen holder den tilsigtede mappe, mens den kører, og at certifikatet, den indlæste, er det, du forventer.

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

Når stiindlæsningen lykkes, er godkendelse og routing stadig separate trin med deres egne fejl, og en forbindelse, der kommer op, men ikke sender trafik, er en anden undersøgelse. Rettelsen her handler kun om, hvilken mappe filerne kom fra, og den bør være synlig i kaldet i stedet for at blive husket af den, der sidst kørte det i hånden.

Hvis profilen udrulles af en konfigurationsmanager, så læg basismappen eller de absolutte filnavne der også. En manuel rettelse på én vært er den version af problemet, der vender tilbage efter næste genopbygning.