OpenVPN inasema active (exited)? Pata instance uliyoianzisha

Unakagua tunnel, unaendesha systemctl status openvpn na unapata active (exited) bila Main PID na kwa orodha tupu ya michakato. Usomaji wa kawaida ni kwamba huduma ilianza na kufa, kwa hiyo unafungua unit, unapata /bin/true na unahitimisha kuwa kifurushi kimevunjika. Katika ufungashaji wa Debian hali hiyo ni wrapper inayofanya kazi kama ilivyoundwa, na tunnel inaishi katika moja ya instance unit inazoanzisha. Unit ya jumla haitakuambia kamwe ni instance ipi iliiunda.

Nini active (exited) inamaanisha kweli kwenye unit hii

Unit iliyofungashwa ni kazi ya mara moja: ExecStart yake ni /bin/true, na RemainAfterExit=yes ndiyo inayohifadhi unit iliyokamilika ikiripotiwa kama active (exited). Ondoa agizo hilo na kazi hiyo hiyo ya /bin/true iliyofanikiwa inaishia inactive (dead), ambayo ndiyo hali hasa ambayo watu wanatarajia na kuisoma vibaya kuelekea upande mwingine. Amri ni kishika nafasi tu, na unit inaripoti kuhusu kazi ambazo unit nyingine hufanya. Hakuna kilichovunjika katika mpangilio huo, na kubadilisha /bin/true kunabadilisha mkataba wa ufungashaji, si tunnel.

Wrapper inakabidhi. Inaanzisha instance unit ambazo usanidi wa kifurushi au generator yake ya systemd hutoa, ndiyo sababu orodha tupu ya michakato haithibitishi chochote kuhusu tunnel. Wakati hakuna instance iliyochaguliwa, wrapper bado inafanikiwa na bado haianzishi chochote. Hali inajibu kama wrapper iliendesha, si kama tunnel ipo.

Soma mistari mitatu ya pato la status, si neno lililo kwenye mabano. Loaded inataja faili ya unit ambayo systemd ilisoma, Active inabeba muhuri wa muda wa mwendo wa mwisho uliofanikiwa, na Main PID isiyopo inalingana na kazi ya mara moja iliyokamilika. Mistari hiyo mitatu pia ni njia ya kutofautisha wrapper hii na huduma iliyoanguka sekunde moja baada ya kuanza.

Orodhesha unit kabla ya kusoma status tena

Uliza systemd kile kilichopo kabla ya kuuliza kile kinachoendesha. Template inaweza kuwa imesakinishwa wakati hakuna instance iliyoundwa, na ni unit iliyoundwa pekee inayobeba tunnel. Anza na seti iliyopakiwa:

systemctl list-units 'openvpn*'

Orodha hiyo ni kile systemd imepakia katika wakati huu, na ndiyo kitu kilicho karibu zaidi na orodha ya tunnel. Faili za unit zilizosakinishwa zinajibu swali lingine, na orodha hiyo bado inaonyesha template wakati hakuna kilichoundwa:

systemctl list-unit-files 'openvpn*'

Soma orodha zote mbili pamoja, kwa sababu template katika ya pili na instance katika ya kwanza ni majibu mawili tofauti. Template iliyopo na instance inayoendesha si ukweli mmoja, na ya pili pekee inamaanisha tunnel. Mipangilio ya vifurushi pia inatofautiana kati ya usambazaji na matoleo ya OpenVPN. Template ya zamani ya openvpn@, jozi iliyotenganishwa ya client na server, na wrapper ya usambazaji zote zinaweza kuwa halali katika ufungashaji wao.

Jipange kulingana na mashine yako, si mafunzo uliyopata. Jina la instance katika pato la mtu mwingine linaweza kuwa office wakati lako ni home au work. Kinachohamishwa ni mbinu, si mfuatano.

Fuata jina la instance hadi faili inayoisoma

Katika template ya client upstream, saraka ya kazi ya unit ni /etc/openvpn/client na amri yake inachukua %i.conf kutoka hapo, kwa hiyo openvpn-client@office inasoma /etc/openvpn/client/office.conf. Thibitisha ramani hiyo kwenye unit iliyosakinishwa badala ya kuamini mfano, kwa sababu template uliyonayo inaweza kuwa ya zamani au kuandikwa upya na usambazaji:

systemctl cat [email protected]

Soma drop-in zinazoonekana chini ya pato hilo, kwa sababu faili iliyo chini ya .d/ inaweza kubadilisha ExecStart, saraka ya kazi au njia ya usanidi. Profaili uliyopakua kama office.ovpn si faili ambayo instance inafungua. Pengo hilo ndilo sababu ya kawaida ya kosa kutaja njia ambayo hukuwahi kuihariri.

Njia za jamaa ndani ya profaili ni mtego unaofuata. Kuhamisha faili kuu wakati marejeleo ya ca, cert na key yanabaki kuwa jamaa hubadilisha kosa la faili lililokosekana na kosa lingine la faili lililokosekana. La pili linaelekeza faili ambayo ulikuwa na uhakika ipo, na ndiyo sababu saraka ya profaili ni muhimu kuliko jina la faili.

Ianzishe, kisha soma journal ya instance hiyo

Anzisha instance uliyoikagua sasa hivi, kwa sababu logi ya unit ya jumla haitakuwa na makosa ya tunnel. Kisha soma journal ya boot hii na utafute kwa mpangilio huo kosa la usanidi, kosa la ufikiaji wa faili na kosa la muunganisho, kwa sababu kila moja linashindwa katika hatua tofauti ya kuanza.

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

Kuanza na kuwezesha ni maamuzi tofauti: start inaendesha unit sasa, enable inapanga boot inayofuata, na enable --now hufanya yote mawili katika hatua moja. daemon-reload inasoma upya ufafanuzi wa unit na haiianzishi upya mchakato unaoendesha na haitumii profaili iliyohaririwa. Baada ya kubadilisha profaili, anzisha upya instance, kwa sababu ndiyo inayosoma faili upya.

Usiweke meneja wa pili kwenye tunnel moja

NetworkManager na wasimamizi wa vikao vya OpenVPN 3 wana hali yao ya muunganisho, na instance ya systemd kando ya mmoja wao inaweka wamiliki wawili kwenye tunnel moja. Dalili ni tunnel inayopanda na kubadilishwa sekunde chache baadaye, au ile inayokataa kubaki imesimama. Chagua meneja ambao usambazaji wako unaandika kwa ajili ya desktop, na tumia systemd kwa makusudi kwenye seva.

Kagua kama tayari kuna mmiliki kabla ya kuanzisha instance. Wakati applet ya desktop inaonyesha muunganisho, instance unayoianzisha inashindana nayo badala ya kuikamilisha. Zima meneja usiyetumia badala ya kuendesha wote wawili na kutumaini mpangilio utadumu. Mgongano huo pia unaeleza journal ambazo tunnel inawekwa kisha kuvunjwa na mchakato ambao hukuwahi kuuanzisha.

Jibu swali la awali kwa jina la instance, faili iliyoisoma na mstari wa journal ulioshindwa. Maelezo ya OpenVPN kuhusu muunganisho wa systemd yanafafanua mpangilio wa template na ramani ya faili ambayo jina la instance hutatuliwa kupitia hiyo.