Sinasabi ng OpenVPN na active (exited)? Hanapin ang instance na sinimulan mo

Sinusuri mo ang tunnel, pinapatakbo ang systemctl status openvpn at nakakakuha ng active (exited) na walang Main PID at may walang laman na listahan ng proseso. Ang natural na pagbasa ay nagsimula at namatay ang serbisyo, kaya binuksan mo ang unit, hinanap ang /bin/true at hinuhang sira ang pakete. Sa packaging ng Debian ang estadong iyon ay ang wrapper na gumagana ayon sa disenyo, at ang tunnel ay nabubuhay sa isa sa mga instance unit na sinisimulan nito. Hindi kailanman sasabihin ng pinagsamang unit kung aling instance ang nagtayo nito.

Ano talaga ang ibig sabihin ng active (exited) sa unit na ito

Ang naka-package na unit ay isang beses na gawain: ang ExecStart nito ay /bin/true, at ang RemainAfterExit=yes ang nagpapanatili sa isang tapos nang unit na iniuulat bilang active (exited). Alisin ang direktiba na iyon at ang parehong matagumpay na gawain ng /bin/true ay nagtatapos sa inactive (dead), na eksaktong estadong inaasahan ng mga tao at mali ang pagbasa sa kabilang direksyon. Ang utos ay isang pansamantalang pansin lamang, at ang unit ay nag-uulat tungkol sa gawaing ginagawa ng ibang unit. Walang sira sa kaayusang iyon, at ang pagpapalit ng /bin/true ay nagbabago ng kontrata ng packaging, hindi ang tunnel.

Ang wrapper ay nagde-delegate. Sinisimulan nito ang mga instance unit na ibinibigay ng configuration ng package o ng systemd generator nito, kaya ang walang laman na listahan ng proseso ay walang pinapatunayan tungkol sa tunnel. Kapag walang napiling instance, nagtatagumpay pa rin ang wrapper at wala pa ring sinisimulan. Ang estado ay sumasagot kung tumakbo ang wrapper, hindi kung may tunnel.

Basahin ang tatlong linya ng output ng status, hindi ang salita sa panaklong. Pinapangalanan ng Loaded ang file ng unit na binasa ng systemd, dinadala ng Active ang timestamp ng huling matagumpay na pagtakbo, at ang wala pang Main PID ay tumutugma sa isang tapos nang gawain. Ang tatlong linyang iyon ay paraan din upang makilala ang wrapper na ito sa serbisyong bumagsak isang segundo pagkatapos magsimula.

Ilista ang mga unit bago mo muling basahin ang status

Tanungin ang systemd kung ano ang umiiral bago tanungin kung ano ang tumatakbo. Maaaring naka-install ang template habang walang instance na nalikha, at tanging unit na nalikha ang may dalang tunnel. Magsimula sa na-load na set:

systemctl list-units 'openvpn*'

Ang listahang iyon ay ang na-load ng systemd sa sandaling ito, at ito ang pinakamalapit sa imbentaryo ng tunnel. Ang mga naka-install na file ng unit ay sumasagot sa ibang tanong, at ang listahang iyon ay nagpapakita pa rin ng template kapag walang nalikha:

systemctl list-unit-files 'openvpn*'

Basahin ang dalawang listahan nang sabay, dahil ang template sa pangalawa at instance sa una ay dalawang magkaibang sagot. Ang template na umiiral at instance na tumatakbo ay hindi iisang katotohanan, at ang pangalawa lamang ang nangangahulugang tunnel. Nagkakaiba rin ang mga layout ng package sa pagitan ng mga distribusyon at bersyon ng OpenVPN. Ang mas lumang template na openvpn@, hiwalay na pares ng client at server, at wrapper ng distribusyon ay lahat maaaring lehitimo sa sariling packaging.

Umangkop sa iyong makina, hindi sa tutorial na natagpuan mo. Ang pangalan ng instance sa output ng iba ay maaaring office habang sa iyo ay home o work. Ang inililipat ay ang paraan, hindi ang string.

Sundan ang pangalan ng instance hanggang sa file na binabasa nito

Sa template ng client upstream ang working directory ng unit ay /etc/openvpn/client at kinukuha ng utos nito ang %i.conf doon, kaya binabasa ng openvpn-client@office ang /etc/openvpn/client/office.conf. Kumpirmahin ang mapping na iyon sa naka-install na unit sa halip na magtiwala sa halimbawa, dahil ang template mo ay maaaring mas luma o muling isinulat ng distribusyon:

systemctl cat [email protected]

Basahin ang mga drop-in na lumilitaw sa ilalim ng output na iyon, dahil ang file sa ilalim ng .d/ ay maaaring magbago ng ExecStart, working directory o path ng configuration. Ang profile na na-download mo bilang office.ovpn ay hindi ang file na binubuksan ng instance. Ang puwang na iyon ang karaniwang dahilan kung bakit may tinutukoy na path ang error na hindi mo kailanman na-edit.

Ang mga relative path sa loob ng profile ang susunod na bitag. Ang paglipat ng pangunahing file habang nananatiling relative ang mga reference na ca, cert at key ay nagpapalit ng error na kulang na file sa isa pang error na kulang na file. Ang pangalawa ay tumuturo sa file na sigurado kang umiiral, kaya mas mahalaga ang direktoryo ng profile kaysa sa pangalan ng file.

Simulan ito, pagkatapos basahin ang journal ng instance na iyon

Simulan ang instance na sinuri mo lang, dahil hindi maglalaman ang log ng pinagsamang unit ng mga error ng tunnel. Pagkatapos basahin ang journal ng boot na ito at hanapin sa ganoong pagkakasunod-sunod ang error sa configuration, error sa pag-access ng file at error sa koneksyon, dahil bawat isa ay nabigo sa ibang yugto ng simula.

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

Ang pagsisimula at pagpapagana ay magkaibang desisyon: ang start ay pinapatakbo ang unit ngayon, ang enable ay naghahanda ng susunod na boot, at ang enable --now ay ginagawa ang dalawa sa isang hakbang. Ang daemon-reload ay muling nagbabasa ng mga depinisyon ng unit at hindi nire-restart ang tumatakbong proseso at hindi inilalapat ang na-edit na profile. Pagkatapos mong baguhin ang profile, i-restart ang instance, dahil iyon ang muling nagbabasa ng file.

Huwag maglagay ng pangalawang manager sa parehong tunnel

Ang NetworkManager at mga session manager ng OpenVPN 3 ay may sariling estado ng koneksyon, at ang instance ng systemd sa tabi ng isa sa kanila ay naglalagay ng dalawang may-ari sa parehong tunnel. Ang sintomas ay tunnel na bumabangon at pinapalitan makalipas ang ilang segundo, o isa na tumatangging manatiling naka-stop. Piliin ang manager na dokumentado ng iyong distribusyon para sa desktop, at gamitin ang systemd nang sinasadya sa isang server.

Tingnan kung may umiiral nang may-ari bago magsimula ng instance. Kapag nagpapakita ng koneksyon ang applet ng desktop, ang instance na sinisimulan mo ay nakikipagkumpitensya dito sa halip na kumpletuhin ito. I-disable ang manager na hindi mo ginagamit sa halip na patakbuhin ang dalawa at umasa na mananatili ang pagkakasunod-sunod. Ipinapaliwanag din ng conflict na iyon ang mga journal kung saan naitatag ang tunnel at pagkatapos ay giniba ng prosesong hindi mo kailanman sinimulan.

Sagutin ang orihinal na tanong gamit ang pangalan ng instance, ang file na binasa nito at ang linyang journal na nabigo. Ang mga tala ng OpenVPN tungkol sa integrasyon sa systemd ay naglalarawan ng layout ng template at ng mapping ng file kung saan niresolba ang pangalan ng instance.