OpenVPN seit active (exited)? Fyn de ynstânsje dy't jo start hawwe

Jo kontrolearje de tunnel, rinne systemctl status openvpn en krije active (exited) sûnder Main PID en mei in lege prosesslist. De natuerlike lêzing is dat de tsjinst start is en stoarn, dus jo iepenje de unit, fine /bin/true en konkludearje dat it pakket stikken is. Yn it Debian-pakket is dy steat de wrapper dy't wurket sa't er ûntwurpen is, en de tunnel libbet yn ien fan 'e instance-units dy't er start. De gearstalde unit sil jo noait fertelle hokker ynstânsje him boud hat.

Wat active (exited) op dizze unit eins betsjut

De pakkete unit is in ienmalige taak: syn ExecStart is /bin/true, en RemainAfterExit=yes is wat in ôfmakke unit as active (exited) rapportearre hâldt. Nim dy direktive fuort en deselde suksesfolle /bin/true-taak einiget yn inactive (dead), krekt de steat dy't minsken ferwachtsje en yn 'e oare rjochting ferkeard lêze. It kommando is in plakhâlder, en de unit rapportearret oer wurk dat oare units dogge. Neat oan dy regeling is stikken, en /bin/true ferfange feroaret it pakketkontrakt, net de tunnel.

De wrapper delegearret. Hy start de instance-units dy't de pakketkonfiguraasje of syn systemd-generator leveret, en dêrom bewiist in lege prosesslist neat oer de tunnel. As gjin ynstânsje keazen is, slagget de wrapper noch altyd en start noch altyd neat. De steat antwurdet oft de wrapper rûn, net oft der in tunnel bestiet.

Lês de trije rigels fan 'e status-útfier ynstee fan it wurd tusken heakjes. Loaded neamt it unit-bestân dat systemd lies, Active draacht de tiidstimpel fan 'e lêste suksesfolle rin, en it ûntbrekken fan Main PID past by in ôfmakke ienmalige taak. Dy trije rigels binne ek hoe't jo dizze wrapper ûnderskiede fan in tsjinst dy't in sekonde nei de start delsloech.

Lis de units op foardat jo de status wer lêze

Freegje systemd wat bestiet foardat jo freegje wat rint. In sjabloan kin ynstallearre wêze wylst gjin ynstânsje makke is, en allinnich in makke unit draacht in tunnel. Begjin mei de laden set:

systemctl list-units 'openvpn*'

Dy list is wat systemd op dit stuit laden hat, en it is it tichtst by in tunnelynventaris. Ynstallearre unit-bestannen beantwurdzje in oare fraach, en dy list lit noch in sjabloan sjen as neat makke is:

systemctl list-unit-files 'openvpn*'

Lês de beide listen byinoar, want in sjabloan yn 'e twadde en in ynstânsje yn 'e earste binne ferskillende antwurden. In sjabloan dat bestiet en in ynstânsje dy't rint binne net itselde feit, en allinnich it twadde betsjut in tunnel. Pakketútlizzingen ferskille ek tusken distribúsjes en OpenVPN-ferzjes. In âlder openvpn@-sjabloan, in splitst client- en serverpear en in distribúsjewrapper kinne allegear legit wêze yn har eigen pakket.

Pas jo oan jo masine oan, net oan 'e tutorial dy't jo fûn hawwe. De ynstânsjenamme yn 'e útfier fan in oar kin office wêze wylst dyn home of work is. Wat oerdroegen wurdt is de metoade, net de tekenrige.

Folgje de ynstânsjenamme nei it bestân dat er lêst

Yn it upstream-client-sjabloan is de wurkmap fan 'e unit /etc/openvpn/client en syn kommando nimt dêrwei %i.conf, dus openvpn-client@office lêst /etc/openvpn/client/office.conf. Befêstigje dy mapping op 'e ynstallearre unit ynstee fan it foarbyld te fertrouwen, want it sjabloan dat jo hawwe kin âlder wêze of in distribúsje-herskriuwing:

systemctl cat [email protected]

Lês de drop-ins dy't ûnderoan dy útfier ferskine, want in bestân ûnder .d/ kin ExecStart, de wurkmap of it konfiguraasjepaad feroarje. In profyl dat jo as office.ovpn ynladen hawwe is net it bestân dat de ynstânsje iepenet. Dy kleau is de gewoane reden dat in flater in paad neamt dat jo nea bewurke hawwe.

Relative paden yn it profyl binne de folgjende falstrik. It haadbestân ferpleatse wylst de ca-, cert- en key-ferwizings relativich bliuwe, ruilet in ûntbrekkend-bestân-flater foar in oare ûntbrekkend-bestân-flater. De twadde wiist nei in bestân dêr't jo wis fan wiene dat it bestie, en dêrom is de profylmap wichtiger as de bestânsnamme.

Start it, en lês dan it logboek fan dy ynstânsje

Start de ynstânsje dy't jo krekt ûndersocht hawwe, want it log fan 'e gearstalde unit sil de flaters fan 'e tunnel net befetsje. Lês dan it logboek foar dizze boot en sykje yn dy folchoarder nei in konfiguraasjeflater, in bestânstagonklikflater en in ferbiningflater, want elk mislearret yn in oare faze fan 'e start.

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

Starte en ynskeakelje binne aparte besluten: start fiert de unit no út, enable regelet de folgjende boot, en enable --now docht beide yn ien stap. daemon-reload lêst unit-definysjes opnij en start gjin rinnend proses opnij en past gjin bewurke profyl ta. Nei't jo it profyl feroare hawwe, start de ynstânsje opnij, want dat is wat it bestân opnij lêst.

Set gjin twadde behearder op deselde tunnel

NetworkManager en de OpenVPN 3-sesjebehearders hawwe har eigen ferbiningsteat, en in systemd-ynstânsje njonken ien fan harren set twa eigeners op deselde tunnel. It symptoom is in tunnel dy't omheech komt en sekonden letter ferfongen wurdt, of ien dy't wegeret stoppe te bliuwen. Kies de behearder dy't jo distribúsje foar it buroblêd dokumintearret, en brûk systemd bewust op in server.

Kontrolearje op in besteande eigner foardat jo in ynstânsje starte. As in buroblêd-applet de ferbining toant, konkurrearret de ynstânsje dy't jo starte dermei ynstee fan it te foltôgjen. Skeakelje de behearder út dy't jo net brûke ynstee fan beide te draaien en te hoopjen dat de folchoarder hâldt. Dat konflikt ferklearret ek logboeken wêryn't in tunnel fêstige en dan ôfbrutsen wurdt troch in proses dat jo nea start hawwe.

Beäntwurdzje de oarspronklike fraach mei de ynstânsjenamme, it bestân dat er lies en de logboekrigel dy't mislearre. De notysjes fan OpenVPN oer systemd-yntergraasje beskriuwe de sjabloanútlizzing en de bestânsmapping dêr't de ynstânsjenamme troch oplost wurdt.