Ju kontrolloni tunelin, ekzekutoni systemctl status openvpn dhe merrni active (exited) pa Main PID dhe me një listë procesesh bosh. Leximi i natyrshëm është se shërbimi filloi dhe vdiq, kështu që hapni unitin, gjeni /bin/true dhe përfundoni se paketa është prishur. Në paketimin Debian ai gjendje është wrapper që punon siç është projektuar, dhe tuneli jeton në një nga unitet e instancës që ai nis. Uniti agregat nuk do t'ju thotë kurrë cila instancë e ndërtoi atë.

Çfarë do të thotë në të vërtetë active (exited) në këtë unit

Uniti i paketuar është një detyrë e vetme: ExecStart i tij është /bin/true, dhe RemainAfterExit=yes është ajo që mban një unit të përfunduar të raportuar si active (exited). Hiqni atë direktivë dhe e njëjta detyrë /bin/true e suksesshme përfundon në inactive (dead), që është saktësisht gjendja që njerëzit presin dhe e lexojnë gabim në drejtimin tjetër. Komanda është vetëm një zëvendësues, dhe uniti raporton për punën që bëjnë unitet e tjera. Asgjë në këtë rregullim nuk është prishur, dhe zëvendësimi i /bin/true ndryshon kontratën e paketimit, jo tunelin.

Wrapper-i delegon. Ai nis unitet e instancës që siguron konfigurimi i paketës ose gjeneratori i tij systemd, prandaj një listë procesesh bosh nuk provon asgjë për tunelin. Kur nuk zgjidhet asnjë instancë, wrapper-i përsëri ka sukses dhe përsëri nuk nis asgjë. Gjendja përgjigjet nëse wrapper-i ka punuar, jo nëse ekziston një tunel.

Lexoni tre rreshtat e daljes së status, jo fjalën në kllapa. Loaded emërton skedarin e unitit që lexoi systemd, Active mban vulën kohore të ekzekutimit të fundit të suksesshëm, dhe Main PID që mungon përputhet me një detyrë të vetme të përfunduar. Ata tre rreshta janë gjithashtu mënyra për të dalluar këtë wrapper nga një shërbim që u rrëzua një sekondë pas nisjes.

Listoni unitet përpara se të lexoni përsëri statusin

Pyetni systemd çfarë ekziston përpara se të pyesni çfarë po punon. Një shabllon mund të jetë i instaluar ndërkohë që nuk është krijuar asnjë instancë, dhe vetëm një unit i krijuar mban një tunel. Filloni me grupin e ngarkuar:

systemctl list-units 'openvpn*'

Ajo listë është ajo që systemd ka ngarkuar në këtë moment, dhe është gjëja më e afërt me një inventar tunelesh. Skedarët e uniteve të instaluar përgjigjen një pyetjeje tjetër, dhe ajo listë ende tregon një shabllon kur nuk është krijuar asgjë:

systemctl list-unit-files 'openvpn*'

Lexoni të dyja listat së bashku, sepse një shabllon në të dytën dhe një instancë në të parën janë dy përgjigje të ndryshme. Një shabllon që ekziston dhe një instancë që punon nuk janë i njëjti fakt, dhe vetëm e dyta do të thotë tunel. Shtrirjet e paketave ndryshojnë edhe midis shpërndarjeve dhe versioneve të OpenVPN. Një shabllon më i vjetër openvpn@, një çift i veçantë client dhe server, dhe një wrapper shpërndarjeje mund të jenë të gjithë të ligjshëm në paketimin e tyre.

Përshtatuni me makinën tuaj, jo me tutorialin që gjetët. Emri i instancës në daljen e dikujt tjetër mund të jetë office ndërsa e juaja është home ose work. Ajo që transferohet është metoda, jo vargu.

Ndiqni emrin e instancës deri te skedari që ajo lexon

Në shabllonin client upstream direktoria e punës e unitit është /etc/openvpn/client dhe komanda e tij merr %i.conf prej andej, kështu që openvpn-client@office lexon /etc/openvpn/client/office.conf. Konfirmoni atë hartë në unitin e instaluar në vend që t'i besoni shembullit, sepse shablloni që keni mund të jetë më i vjetër ose një rishkrim i shpërndarjes:

systemctl cat [email protected]

Lexoni drop-in që shfaqen në fund të asaj daljeje, sepse një skedar nën .d/ mund të ndryshojë ExecStart, direktorinë e punës ose rrugën e konfigurimit. Një profil që shkarkuat si office.ovpn nuk është skedari që hap instanca. Ai boshllëk është arsyeja e zakonshme që një gabim emërton një rrugë që nuk e keni redaktuar kurrë.

Rrugët relative brenda profilit janë kurthi tjetër. Zhvendosja e skedarit kryesor ndërsa referencat ca, cert dhe key mbeten relative shkëmben një gabim skedari që mungon me një gabim tjetër skedari që mungon. I dyti tregon një skedar për të cilin ishit i sigurt se ekzistonte, dhe prandaj direktoria e profilit ka më shumë rëndësi se emri i skedarit.

Niseni atë, më pas lexoni ditarin e asaj instance

Nisni instancën që sapo inspektuat, sepse regjistri i unitit agregat nuk do të përmbajë gabimet e tunelit. Më pas lexoni ditarin për këtë nisje dhe kërkoni në atë rend një gabim konfigurimi, një gabim aksesi në skedar dhe një gabim lidhjeje, sepse secili dështon në një fazë të ndryshme të nisjes.

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

Nisja dhe aktivizimi janë vendime të veçanta: start e ekzekuton unitin tani, enable përgatit nisjen tjetër, dhe enable --now i bën të dyja në një hap. daemon-reload rilexon përkufizimet e uniteve dhe nuk rinis një proces që punon dhe nuk zbaton një profil të redaktuar. Pasi të keni ndryshuar profilin, rinisni instancën, sepse kjo është ajo që rilexon skedarin.

Mos vendosni një menaxher të dytë në të njëjtin tunel

NetworkManager dhe menaxherët e sesioneve të OpenVPN 3 kanë gjendjen e tyre të lidhjes, dhe një instancë systemd pranë njërit prej tyre vendos dy pronarë në të njëjtin tunel. Simptoma është një tunel që ngrihet dhe zëvendësohet sekonda më vonë, ose një që refuzon të qëndrojë i ndalur. Zgjidhni menaxherin që shpërndarja juaj dokumenton për desktopin, dhe përdorni systemd me qëllim në një server.

Kontrolloni për një pronar ekzistues përpara se të nisni një instancë. Kur një applet desktopi tregon lidhjen, instanca që nisni konkurron me të në vend që ta plotësojë. Çaktivizoni menaxherin që nuk e përdorni në vend që t'i ekzekutoni të dy dhe të shpresoni se rendi do të mbajë. Ai konflikt shpjegon gjithashtu ditarë ku një tunel vendoset dhe më pas çmontohet nga një proces që nuk e keni nisur kurrë.

Përgjigjuni pyetjes origjinale me emrin e instancës, skedarin që ajo lexoi dhe rreshtin e ditarit që dështoi. Shënimet e OpenVPN për integrimin me systemd përshkruajnë shtrirjen e shabllonit dhe hartën e skedarit përmes së cilës zgjidhet emri i instancës.

Artikuj të ngjashëm