OpenVPN segir active (exited)? Finndu tilvikið sem þú ræstir

Þú athugar göngin, keyrir systemctl status openvpn og færð active (exited) án Main PID og með tóman ferlalista. Eðlileg lesning er að þjónustan hafi ræst og dáið, svo þú opnar unitið, finnur /bin/true og ályktar að pakkinn sé bilaður. Í Debian-pökkuninni er það ástand wrapperinn sem vinnur eins og hann var hannaður, og göngin lifa í einu af instance-unitunum sem hann ræsir. Samsett unit mun aldrei segja þér hvaða tilvik byggði það.

Hvað active (exited) þýðir í raun á þessu uniti

Pakkaða unitið er einskiptisverk: ExecStart þess er /bin/true, og RemainAfterExit=yes er það sem heldur loknu uniti tilkynntu sem active (exited). Fjarlægðu þá tilskipun og sama farsæla /bin/true verkið endar í inactive (dead), sem er einmitt ástandið sem fólk býst við og les rangt í hina áttina. Skipunin er aðeins staðgengill, og unitið greinir frá vinnu sem önnur unit vinna. Ekkert í þessu fyrirkomulagi er bilað, og að skipta um /bin/true breytir pökkunarsamningnum en ekki göngunum.

Wrapperinn framselur. Hann ræsir instance-unitin sem stilling pakkans eða systemd-gerill hans útvegar, og þess vegna sannar tómur ferlalisti ekkert um göngin. Þegar ekkert tilvik er valið tekst wrapperinum samt og ræsir samt ekkert. Ástandið svarar því hvort wrapperinn rann, ekki hvort göng eru til.

Lestu þrjár línur status-úttaksins frekar en orðið í svigunum. Loaded nefnir unit-skrána sem systemd las, Active ber tímastimpil síðustu farsælu keyrslu, og Main PID sem vantar passar við lokið einskiptisverk. Þessar þrjár línur eru líka leiðin til að greina þennan wrapper frá þjónustu sem hrundi sekúndu eftir ræsingu.

Listaðu unitin áður en þú lest status aftur

Spyrðu systemd hvað sé til áður en þú spyrð hvað sé í gangi. Sniðmát getur verið uppsett án þess að nokkurt tilvik sé búið til, og aðeins búið unit ber göng. Byrjaðu á hlaðna safninu:

systemctl list-units 'openvpn*'

Sá listi er það sem systemd hefur hlaðið í þessu augnabliki, og það er það næsta sem kemst skrá yfir göng. Uppsettar unit-skrár svara annarri spurningu, og sá listi sýnir enn sniðmát þegar ekkert er búið til:

systemctl list-unit-files 'openvpn*'

Lestu báða listana saman, því sniðmát í þeim seinni og tilvik í þeim fyrri eru ólík svör. Sniðmát sem er til og tilvik sem er í gangi eru ekki sama staðreynd, og aðeins hið síðara þýðir göng. Pökkunaruppsetningar eru líka ólíkar milli dreifinga og OpenVPN-útgáfa. Eldra openvpn@ sniðmát, aðskilið client og server par og dreifingarwrapper geta öll verið lögmæt í eigin pökkun.

Lagaðu þig að þinni vél frekar en handbókinni sem þú fannst. Tilviksnafnið í úttaki annars gæti verið office á meðan þitt er home eða work. Það sem flyst er aðferðin, ekki strengurinn.

Fylgdu tilviksnafninu að skránni sem það les

Í upstream client sniðmátinu er vinnumappa unitsins /etc/openvpn/client og skipun þess tekur %i.conf þaðan, svo openvpn-client@office les /etc/openvpn/client/office.conf. Staðfestu þessa vörpun á uppsetta unitinu í stað þess að treysta dæminu, því sniðmátið sem þú hefur gæti verið eldra eða endurskrifun dreifingarinnar:

systemctl cat [email protected]

Lestu drop-inin sem birtast neðst í þessu úttaki, því skrá undir .d/ getur breytt ExecStart, vinnumöppunni eða stillingarslóðinni. Prófíll sem þú hlóðst niður sem office.ovpn er ekki skráin sem tilvikið opnar. Það bil er venjulega ástæðan fyrir því að villa nefnir slóð sem þú breyttir aldrei.

Afstæðar slóðir inni í prófílnum eru næsta gildra. Að færa aðalskrána á meðan ca, cert og key tilvísanir eru áfram afstæðar skiptir villu um skrá sem vantar fyrir aðra villu um skrá sem vantar. Sú síðari bendir á skrá sem þú varst viss um að væri til, og þess vegna skiptir prófílumappan meira máli en skráarnafnið.

Ræstu það og lestu síðan dagbók þess tilviks

Ræstu tilvikið sem þú skoðaðir rétt í þessu, því log samsetta unitsins mun ekki innihalda villur ganganna. Lestu síðan dagbókina fyrir þessa ræsingu og leitaðu í þeirri röð að stillingarvillu, skráaraðgangsvillu og tengingarvillu, því hver þeirra mistekst á öðru stigi ræsingarinnar.

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

Ræsing og virkjun eru aðskildar ákvarðanir: start keyrir unitið núna, enable sér um næstu ræsingu, og enable --now gerir hvort tveggja í einu skrefi. daemon-reload les unit-skýringar aftur og endurræsir ekki ferli í gangi og beitir ekki breyttum prófíl. Eftir að þú breyttir prófílnum skaltu endurræsa tilvikið, því það les skrána aftur.

Settu ekki annan stjórnanda á sömu göng

NetworkManager og OpenVPN 3 setustjórnendur eiga sitt eigið tengingarástand, og systemd tilvik við hlið eins þeirra setur tvo eigendur á sömu göng. Einkennið er göng sem rísa og er skipt út sekúndum síðar, eða þau sem neita að vera stoppuð. Veldu þann stjórnanda sem dreifingin þín skjalfestir fyrir skjáborðið, og notaðu systemd viljandi á netþjóni.

Athugaðu hvort eigandi sé þegar til staðar áður en þú ræsir tilvik. Þegar skjáborðsapplet sýnir tenginguna keppir tilvikið sem þú ræsir við hana í stað þess að ljúka henni. Slökktu á stjórnandanum sem þú notar ekki í stað þess að keyra báða og vona að röðin haldist. Þessi árekstur útskýrir líka dagbækur þar sem göng eru sett upp og síðan rifin niður af ferli sem þú ræstir aldrei.

Svaraðu upprunalegu spurningunni með tilviksnafninu, skránni sem það las og dagbókarlínunni sem mistókst. Athugasemdir OpenVPN um systemd-samþættingu lýsa uppsetningu sniðmátsins og skráarvörpuninni sem tilviksnafnið leysist gegnum.