OpenVPN ne najde ca.crt, čeprav se profil naloži

Storitev se zažene, prebere profil brez pripomb in nato umre v vrstici, ki deluje nepovezano: ne more odpreti ca.crt. Pri potrdilu se ni nič spremenilo, pot profila v datoteki unit pa je absolutna. Prav ta kombinacija je namig. Pot, ki ste jo podali, najde eno datoteko, imena znotraj te datoteke pa se razrešijo povsem drugje, zato lahko zagon, ki je videti popolnoma kvalificiran, svoje ključe še vedno bere iz imenika, ki ga nihče ni predvidel.

Napaka ima malo vzrokov in vredno jih je ločiti po vrsti: osnovni imenik, ki ga je proces dejansko imel, kontekst zagona storitve ter dovoljenja ali peskovnik okoli datoteke, ko je pot že pravilna. Vsak pusti drugačno sled — v unit, v procesu in v datotečnem sistemu.

Pot profila ni osnovni imenik

Predstavljajte si proces, ki se začne v /tmp in dobi /etc/vpn/prod/tenant-a.ovpn. Znotraj tega profila vrstica ca ca.crt navaja relativno pot. Nič v argumentu, ki je profil našel, tega imena ne prepiše, zato proces išče /tmp/ca.crt in sporoči manjkajočo datoteko.

Zmede vrstni red napak. OpenVPN najprej razčleni konfiguracijo in odpre navedene datoteke, ko do njih pride, zato se tipkarska napaka v profilu sporoči, preden se dotakne kateri koli ključ, medtem ko se manjkajoče potrdilo pojavi šele, ko razčlenjevanje pride tja. Profil, ki se naloži, je torej dokaz, da je skladnja pravilna, ne pa da so bile datoteke, ki jih navaja, najdene.

Kaj ločuje priročnik: --config in --cd

Priročnik OpenVPN 2.6 opisuje dve različni možnosti. Ena naloži konfiguracijsko datoteko. Druga spremeni imenik procesa, preden se preberejo konfiguracija, ključ, skript in druge datoteke, in zahteva absolutni imenik brez sklicevanja na trenutnega.

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

Ta klic je oblika, ne navodilo za zagon tujega profila. Kar ponuja, je določnost: osnova za vsako relativno ime v verigi je navedena v ukazu, namesto da bi se podedovala iz lupine ali upravitelja, ki je pognal proces. Alternativa je enako veljavna in za storitev pogosto boljša: pustite delovni imenik pri miru in naredite vsako navedeno datoteko absolutno znotraj profila.

Karkoli izberete, pregledajte celotno verigo in ne prve napake. Profil lahko potegne drugo konfiguracijsko datoteko, relativna imena vključene datoteke pa se razrešujejo glede na isti imenik procesa, ne glede na imenik datoteke, ki jih je vključila. Poti dnevnikov, datoteke za preverjanje pristnosti in pomožni skripti sledijo istemu pravilu.

Storitev se zažene drugje

Interaktivna lupina v imeniku profila ne dokaže ničesar o pakirani enoti. Upravitelji nastavijo svoj delovni imenik, ovijalni skript pa ga lahko pred zagonom binarne datoteke spet spremeni. Enota, ki odpove, je edini zagon, o katerem je vredno razmišljati.

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

Drugi ukaz pokaže imenik, ki ga živi proces dejansko drži, in to je zanesljivejše od datoteke unit, kadar je vpleten ovijalec. Če se oba ne ujemata, je ovijalec vaš odgovor, enota pa lažna sled.

Po iskanju: dovoljenja, chroot in peskovnik

Pravilen osnovni imenik lahko še vedno da isto sporočilo, ker sta razrešitev in dostop ločena koraka. Proces potrebuje dovoljenje za izvajanje v vsakem nadrejenem imeniku in dovoljenje za branje datoteke, storitvena enota, ki skriva del datotečnega sistema, pa spremeni, kaj proces sploh lahko vidi.

Tri pogoste različice dajo enako napako. Datoteka je berljiva samo za root, medtem ko se storitev pred odpiranjem odreče privilegijem. Enota nastavi zaščitni pogled na datotečni sistem, ki ne vključuje imenika profila. Demon teče s chrootom, zato pot, ki obstaja na gostitelju, v tem pogledu ne obstaja.

Diagnosticirajte po lastništvu datoteke in identiteti procesa, ne z rahlanjem dovoljenj. Narediti zasebni ključ berljiv vsem, da bi to napako utišali, zamenja glasno napako za tiho, ključ pa je prav tisti del imenika, ki ga najmanj želite razkriti.

Dokažite popravek z lastnim zagonom

Ponovno zaženite pravo enoto iz imenika, ki ni povezan s profilom, in opazujte isto zagonsko vrstico. Nato potrdite, da proces med delovanjem drži predvideni imenik in da je naloženo potrdilo tisto, ki ga pričakujete.

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

Ko nalaganje poti uspe, sta preverjanje pristnosti in usmerjanje še vedno ločeni stopnji z lastnimi napakami, povezava, ki se dvigne, a ne prepusti prometa, pa je druga preiskava. Popravek tukaj se nanaša le na to, iz katerega imenika so prišle datoteke, in mora biti viden v klicu, namesto da bi si ga zapomnil tisti, ki ga je nazadnje zagnal ročno.

Če profil uvaja upravitelj konfiguracije, tja vstavite tudi osnovni imenik ali absolutna imena datotek. Ročni popravek na enem gostitelju je različica te težave, ki se vrne po naslednji ponovni gradnji.