OpenVPN seier active (exited)? Finn instansen du starta

Du sjekkar tunnelen, køyrer systemctl status openvpn og får active (exited) utan Main PID og med ei tom prosessliste. Den naturlege lesinga er at tenesta starta og døydde, så du opnar unit-fila, finn /bin/true og konkluderer med at pakken er øydelagd. I Debian-pakken er den tilstanden wrapperen som jobbar som designa, og tunnelen bur i ein av instans-unita han startar. Den samla unit-a vil aldri fortelje deg kva instans som bygde henne.

Kva active (exited) eigentleg tyder på denne unit-a

Den pakka unit-a er ei eingongsoppgåve: ExecStart er /bin/true, og RemainAfterExit=yes er det som held ei fullført unit rapportert som active (exited). Fjern den direktivet, og den same vellukka /bin/true-oppgåva endar i inactive (dead), som nettopp er tilstanden folk ventar og les feil i motsett retning. Kommandoen er ein plasshaldar, og unit-a rapporterer om arbeid som andre unit-ar utfører. Ingenting i denne ordninga er øydelagd, og å bytte ut /bin/true endrar pakkekontrakten, ikkje tunnelen.

Wrapperen delegerer. Han startar instans-unita som pakkekonfigurasjonen eller systemd-generatoren leverer, og difor provar ei tom prosessliste ingenting om tunnelen. Når ingen instans er vald, lukkast wrapperen framleis og startar framleis ingenting. Tilstanden svarar på om wrapperen køyrde, ikkje om det finst ein tunnel.

Les dei tre linjene i status-utskrifta i staden for ordet i parentesen. Loaded nemner unit-fila systemd las, Active ber tidsstempelet for siste vellukka køyring, og den manglande Main PID passar til ei fullført eingongsoppgåve. Dei tre linjene er også måten å skilje denne wrapperen frå ei teneste som krasja eit sekund etter start.

List unit-ane før du les status igjen

Spør systemd kva som finst før du spør kva som køyrer. Ein mal kan vere installert medan ingen instans er oppretta, og berre ei oppretta unit ber ein tunnel. Start med det innlasta settet:

systemctl list-units 'openvpn*'

Den lista er det systemd har lasta inn i dette augneblunken, og det er det næraste ein kjem ei tunneloversikt. Installerte unit-filer svarar på eit anna spørsmål, og den lista viser framleis ein mal når ingenting er oppretta:

systemctl list-unit-files 'openvpn*'

Les dei to listene saman, fordi ein mal i den andre og ein instans i den første er ulike svar. Ein mal som finst og ein instans som køyrer er ikkje same faktum, og berre det andre tyder ein tunnel. Pakkeoppsett varierer også mellom distribusjonar og OpenVPN-versjonar. Ein eldre openvpn@-mal, eit delt client- og serverpar og ein distribusjonswrapper kan alle vere legitime i si eiga pakking.

Tilpass deg maskina di i staden for rettleiinga du fann. Instansnamnet i utskrifta til andre kan vere office medan ditt er home eller work. Det som blir overført er metoden, ikkje strengen.

Følg instansnamnet til fila han les

I upstream client-malen er arbeidskatalogen til unit-a /etc/openvpn/client, og kommandoen tek %i.conf derfrå, så openvpn-client@office les /etc/openvpn/client/office.conf. Stadfest den koplinga på den installerte unit-a i staden for å stole på dømet, fordi malen du har kan vere eldre eller ei omskriving frå distribusjonen:

systemctl cat [email protected]

Les drop-in-filene nedst i den utskrifta, fordi ei fil under .d/ kan endre ExecStart, arbeidskatalogen eller konfigurasjonsstien. Ein profil du lasta ned som office.ovpn er ikkje fila instansen opnar. Det gapet er den vanlege grunnen til at ein feil nemner ein sti du aldri har redigert.

Relative stiar inne i profilen er den neste fella. Å flytte hovudfila medan ca-, cert- og key-referansane blir verande relative byter ein manglande-fil-feil mot ein annan manglande-fil-feil. Den andre peikar på ei fil du var sikker på fanst, og difor tyder profilmappa meir enn filnamnet.

Start han, og les deretter journalen for den instansen

Start instansen du nettopp undersøkte, fordi loggen til den samla unit-a ikkje vil innehalde feila til tunnelen. Les deretter journalen for denne oppstarten og sjå i den rekkjefølgja etter ein konfigurasjonsfeil, ein filtilgangsfeil og ein tilkoplingsfeil, fordi kvar av dei feilar på eit ulikt tidspunkt av oppstarten.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Start og aktivering er separate avgjerder: start køyrer unit-a no, enable ordnar neste oppstart, og enable --now gjer begge i eitt steg. daemon-reload les unit-definisjonar på nytt og startar ikkje ein køyrande prosess på nytt og brukar ikkje ein redigert profil. Når du har endra profilen, start instansen på nytt, fordi det er det som les fila på nytt.

Ikkje set ein andre handsamar på same tunnel

NetworkManager og OpenVPN 3-sesjonshandsmarane eig sin eigen tilkoplingstilstand, og ein systemd-instans ved sida av ein av dei set to eigarar på same tunnel. Symtomet er ein tunnel som kjem opp og blir erstatta sekundar seinare, eller ein som nektar å bli verande stoppa. Vel handsamaren distribusjonen din dokumenterer for skrivebordet, og bruk systemd medvite på ein server.

Sjekk om det alt finst ein eigar før du startar ein instans. Når eit skrivebordsapplet viser tilkoplinga, konkurrerer instansen du startar med det i staden for å fullføre det. Deaktiver handsamaren du ikkje brukar i staden for å køyre begge og håpe at rekkjefølgja held. Den konflikten forklarar også journalar der ein tunnel blir etablert og deretter riven ned av ein prosess du aldri starta.

Svar på det opphavlege spørsmålet med instansnamnet, fila han las og journal-linja som feila. Notata til OpenVPN om systemd-integrering skildrar maloppsettet og filkoplinga som instansnamnet blir løyst gjennom.