client-config-dir ignoreres etter at OpenVPN ble en tjeneste

Tunnelen din kommer opp og klienten kobler til, men den faste adressen og de pushede rutene du definerte for den ene brukeren mangler. Loggen sier ikke “file not found”, og det er nettopp dette som sender folk ut for å generere sertifikater på nytt. I de fleste av disse tilfellene kjører daemonen fra en annen katalog enn skallet du testet i, og client-config-dir ble aldri løst slik du antok. Rettelsen er en stikorreksjon, ikke en nullstilling av påloggingsinformasjon.

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

Start med prosessen som faktisk kjører, ikke filen du redigerte. Spør systemd om kjørelinjen, arbeidskatalogen og kontoen den bytter til. De tre svarene forklarer de fleste feilene i denne klassen:

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

En tom WorkingDirectory betyr at unit-filen starter i /, så en relativ client-config-dir ccd letes etter i /ccd. Den katalogen finnes nesten aldri, og daemonen anser ikke fraværet som fatalt.

Sammenlign det med den interaktive oppstarten du brukte under testing, der skallets gjeldende katalog sannsynligvis var konfigurasjonskatalogen. Samme fil, samme nøkkelord, to ulike resultater.

Hva en relativ sti løses mot

Nøkkelordet løses mot prosessens arbeidskatalog i det øyeblikket valget brukes. Det betyr ikke “ved siden av konfigurasjonsfilen jeg sendte med --config”. OpenVPN leser gjerne en konfigurasjon fra en absolutt sti og løser likevel relative verdier andre steder, og det er nettopp fellen her. OpenVPN 2.6-håndboken angir regelen under --client-config-dir og igjen under --cd.

Nøkkelordet cd endrer den konteksten før andre filer leses, så en unit som setter cd /etc/openvpn/server og deretter client-config-dir ccd, løses til /etc/openvpn/server/ccd. Hvis du legger til cd, sjekk rekkefølgen på direktivene og husk at det påvirker hver annen relativ referanse i samme fil.

Gå stien som daemonens konto

En sti kan være riktig og likevel uleselig. Etter privilegiefallet er daemonen ikke lenger root, så hver overordnet katalog trenger søketillatelse for den kontoen, og klientfilen selv trenger lesetillatelse. Én manglende utførelsesbit på en overordnet katalog er nok til å skjule filen, og feilen viser seg bare som en klient som stille får standardbassenget.

namei skriver ut tillatelsene for hver komponent i rekkefølge, noe som er raskere enn å sjekke katalogene én for én:

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

Test deretter lesingen som tjenestekontoen i stedet for som deg selv:

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

Hvis unit-filen bruker chroot, må katalogen finnes inne i fengselet, og stien i konfigurasjonen tolkes etter at chroot er anvendt. En fil som ligger på verten utenfor fengselet, er usynlig innenfra.

Bekreft oppslaget i stedet for å gjette

Øk loggnivået for én omstart og les hva serveren sier om klientspesifikke valg. Ved verb 4 rapporterer daemonen konfigurasjonen per klient som den importerte, så en manglende linje er direkte bevis på at ingen fil ble lest for den tilkoblingen.

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

Kjør det i forgrunnen på en ledig port og koble til én klient. Det fjerner systemd helt fra bildet: hvis overstyringene dukker opp her og ikke under tjenesten, er forskjellen unit-filens kontekst, ikke filen.

Bestem hva som skal skje når ingen fil passer. Uten ccd-exclusive tas klienten inn med bare de globale bassenginnstillingene, og det er den stille feilen beskrevet over. Med den blir en manglende fil en avvist tilkobling, og den avvisningen er lettere å legge merke til, men vanskeligere å feilsøke under last.

Rett, start på nytt, verifiser

Gjør katalogen absolutt i konfigurasjonen og hold den slik. Relative stier er bare trygge når unit-filen fester arbeidskatalogen, og å feste den er en ekstra bevegelig del som noen fjerner senere.

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

Start instansen på nytt, koble til en kjent klient igjen og les adressen den fikk sammen med rutene som ble pushet til den. Hvis adressen samsvarer med linjen ifconfig-push i den klientens fil, virket oppslaget. Hvis klienten fortsatt havner i det generelle bassenget, gå tilbake til antall logglinjer: null importer betyr at stien eller identiteten er feil, én import med feil innhold betyr at du redigerer en annen fil enn den daemonen leser.

Rull tilbake ved å gjenopprette forrige unit og konfigurasjon sammen, og start deretter på nytt. Sertifikater trenger ikke utstedes på nytt for noe av dette, og å behandle et katalogproblem som et påloggingsproblem er måten en fem minutters rettelse blir et vedlikeholdsvindu.