client-config-dir blir ignorert etter at OpenVPN vart ei teneste

Tunnelen din kjem opp og klienten koplar til, men den faste adressa og dei pusja rutene du definerte for den eine brukaren manglar. Loggen seier ikkje “file not found”, og det er nettopp dette som sender folk ut for å laga sertifikat på nytt. I dei fleste av desse tilfella køyrer daemonen frå ein annan katalog enn skalet du testa i, og client-config-dir vart aldri løyst slik du gjekk ut frå. Rettninga er ein stirettning, ikkje ein nullstilling av påloggingsinformasjon.

Les unit-fila før du rører konfigurasjonen

Start med prosessen som faktisk køyrer, ikkje fila du redigerte. Spør systemd om køyrelinja, arbeidskatalogen og kontoen han byter til. Dei tre svara forklarer dei fleste feila i denne klassa:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Ein tom WorkingDirectory betyr at unit-fila startar i /, så ein relativ client-config-dir ccd blir leita etter i /ccd. Den katalogen finst nesten aldri, og daemonen ser ikkje på fråværet som fatalt.

Samanlikn det med den interaktive starten du brukte under testing, der gjeldande katalog i skalet ditt truleg var konfigurasjonskatalogen. Same fil, same nøkkelord, to ulike resultat.

Kva ein relativ sti blir løyst mot

Nøkkelordet blir løyst mot arbeidskatalogen til prosessen i det augneblinken valet blir brukt. Det tyder ikkje “ved sida av konfigurasjonsfila eg sende med --config”. OpenVPN les gjerne ein konfigurasjon frå ein absolutt sti og løyser likevel relative verdiar andre stader, og det er nettopp fella her. OpenVPN 2.6-handboka oppgir regelen under --client-config-dir og igjen under --cd.

Nøkkelordet cd endrar den konteksten før andre filer blir lesne, så ein unit som set cd /etc/openvpn/server og deretter client-config-dir ccd, blir løyst til /etc/openvpn/server/ccd. Viss du legg til cd, sjekk rekkjefølgja på direktiva og hugs at det påverkar kvar annan relativ referanse i same fil.

Gå stien som kontoen til daemonen

Ein sti kan vere rett og likevel uleseleg. Etter privilegiefallet er daemonen ikkje lenger root, så kvar overordna katalog treng søkeløyve for den kontoen, og klientfila sjølv treng leseløyve. Eitt manglande utføringsbit på ein overordna katalog er nok til å gøyme fila, og feilen viser seg berre som ein klient som stille får standardbassenget.

namei skriv ut løyva for kvar komponent i rekkjefølgje, noko som er raskare enn å sjekke katalogane ein for ein:

namei -l /etc/openvpn/server/ccd/client1

Test deretter lesinga som tenestekontoen i staden for som deg sjølv:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Viss unit-fila brukar chroot, må katalogen finnast inne i fengselet, og stien i konfigurasjonen blir tolka etter at chroot er brukt. Ei fil som ligg på verten utanfor fengselet, er usynleg innanfrå.

Stadfest oppslaget i staden for å gisse

Auk loggnivået for éin omstart og les kva tenaren seier om klientspesifikke val. Ved verb 4 rapporterer daemonen konfigurasjonen per klient som han importerte, så ei manglande linje er direkte prov på at inga fil vart lesen for den tilkoplinga.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Køyr det i forgrunnen på ein ledig port og kople til éin klient. Det fjernar systemd heilt frå biletet: viss overstyringane dukkar opp her og ikkje under tenesta, er skilnaden konteksten til unit-fila, ikkje fila.

Avgjer kva som skal skje når inga fil passar. Utan ccd-exclusive blir klienten teken inn med berre dei globale bassenginnstillingane, og det er den stille feilen skildra over. Med han blir ei manglande fil ei avvist tilkopling, og den avvisinga er lettare å leggje merke til, men vanskelegare å feilsøkje under last.

Rett, start på nytt, stadfest

Gjer katalogen absolutt i konfigurasjonen og hald han slik. Relative stiar er berre trygge når unit-fila festar arbeidskatalogen, og å feste han er ein ekstra bevegeleg del som nokon fjernar seinare.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Start instansen på nytt, kople til ein kjend klient igjen og les adressa han fekk saman med rutene som vart pusja til han. Viss adressa samsvarar med linja ifconfig-push i fila til den klienten, verka oppslaget. Viss klienten framleis hamnar i det generelle bassenget, gå tilbake til talet på logglinjer: null importar tyder at stien eller identiteten er feil, éin import med feil innhald tyder at du redigerer ei anna fil enn den daemonen les.

Rull tilbake ved å gjenopprette førre unit og konfigurasjon saman, og start deretter på nytt. Sertifikat treng ikkje bli gjevne ut på nytt for noko av dette, og å handsame eit katalogproblem som eit påloggingsproblem er måten ein fem minutts retting blir eit vedlikehaldsvindauge.