OpenVPN nuk niset pa gabim? Shikoni journal

Komanda kthehet, shërbimi shfaqet si i dështuar dhe asgjë që i ngjan një shpjegimi nuk arrin në terminal. Ai heshtje është simptoma që njerëzit e përshkruajnë si «OpenVPN nuk niset», dhe pothuajse kurrë nuk do të thotë se programi vdiq pa thënë asgjë. Do të thotë se mesazhi shkoi në një kanal që nuk po lexoje, ose se ajo që nisje nuk ishte ajo që kishe konfiguruar. Të dyja rastet mund të diagnostikohen në më pak se një minutë sapo të ndalosh trajtimin e profilit si i dyshuari.

Katër vende e thithin daljen: journal-i i unit-it, shtojca që zotëron lidhjen, skaji tjetër i tunelit dhe një binare tjetër nga ajo që mendon se po ekzekutohet. Secili ka kontrollin e vet.

Heshtja do të thotë që nuk po shikoje kanalin e duhur

Një thirrje në plan të parë printon në terminalin tënd. Një unit printon në journal, dhe një unit i dështuar mund të dalë para se të shkruajë çfarëdo nëse dështimi qëndron në mënyrën se si u nis dhe jo në atë që iu tha. Ky dallim ka rëndësi: asnjë hyrje në journal do të thotë që procesi nuk ekzekutua kurrë vërtet, ndërsa një hyrje e ndjekur nga një dalje do të thotë se ekzekutua dhe refuzoi diçka.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Shto systemctl show -p Result -p ExecMainStatus openvpn-client@office për të ndarë një dalje të pastër nga një sinjal. Një status 1 me një Result=exit-code është një vendim i programit; Result=signal ose një afat kohor tregojnë mjedisin, dhe asnjë sasi e redaktimit të profilit nuk e ndryshon atë. Shkruaj të dyja vlerat para se të rinisësh çfarëdo, sepse një rinisje fshin gjendjen kalimtare që i prodhoi ato.

Emri i instancës është pjesë e shtegut

Unit-i i shabllonit të paketuar nuk pranon një shteg skedari. Ai pranon një emër instance, dhe ai emër i shtohet një direktorie për të gjetur profilin: office në paketimin Debian dhe Ubuntu zgjidhet në /etc/openvpn/client/office.conf. Një skedar i quajtur office-v2.conf, i nisur si @office nuk lexohet kurrë, dhe unit-i del në heshtje sepse nga pikëpamja e tij nuk kishte asgjë për të bërë. Direktoria e kërkimit ndryshon midis modalitetit klient dhe server, prandaj i njëjti gabim tregon diku krejt tjetër kur ndryshon shabllonin.

Ai mospërputhje është burimi më i zakonshëm i dështimit të heshtur, dhe është i padukshëm në profil sepse profili është në rregull. Listo çfarë ekziston vërtet dhe krahaso dy emrat karakter për karakter, duke përfshirë çdo zgjatim që paketimi pret.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Nëse unit-i është i aktivizuar por asnjë instancë nuk listohet, vetë aktivizimi mund t’i referohet një emri që u riemërtua më vonë. Riaktivizimi i instancës së saktë zakonisht mjafton, dhe skedari i vjetër i unit-it që mbetet ia vlen të fshihet që të mos ngatërrojë personin tjetër. Një skedar unit-i i harruar është një gjë e vogël që i kushton dikujt një orë më vonë.

Kur shtojca zotëron tunelin, terminali nuk sheh asgjë

Një lidhje e nisur nga applet-i i desktopit zotërohet nga NetworkManager, dhe dalja e saj OpenVPN shkon në journal-in e atij shërbimi dhe jo në ndonjë shell që ke të hapur. Të ekzekutosh klientin me dorë dhe të mos shohësh asgjë është e pritshme në atë rregullim, sepse procesi i ekzekutuar me dorë nuk është ai që mban lidhjen.

Kërko në journal shërbimin që e zotëron, pastaj riprodho analizën me një nivel detajesh që mund të lexosh. Dy komandat më poshtë shikojnë pronarë të ndryshëm të të njëjtit dështim.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Ekzekutimi i pavarur është për të lexuar mesazhe, jo për të zëvendësuar lidhjen e menaxhuar, dhe të dyja ndryshojnë më pas: integrimi DNS, rrugët dhe jetëgjatësia i përkasin shtojcës. Rregullimi i një gabimi analize në ekzekutimin e pavarur nuk e rregullon automatikisht zgjidhjen e emrave kur applet-i merr kontrollin, prandaj mbaji dy vëzhgimet të ndara.

Dy binare, një PATH

Një ndërtim manual i instaluar nën /usr/local fiton në një thirrje shell, sepse /usr/local/sbin vjen para /usr/sbin në PATH-in standard të Ubuntu. Një unit nuk përdor PATH-in tënd; ai ekzekuton shtegun absolut të shkruar në ExecStart. Pra versioni që funksionon në terminalin tënd dhe versioni që dështon si shërbim mund të jenë programe vërtet të ndryshëm.

Krahaso të dyja para se të rindërtosh çfarëdo. Komanda e tretë është ajo që vendos argumentin.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Një tjetër ndryshim mjedisi fshihet në të njëjtin vend. Një unit i paketuar mbështetet në një direktori ekzekutimi nën /run që systemd krijon për të; një unit zëvendësues i shkruar me dorë që e lë jashtë atë cilësim mund të dështojë para se të hapë një skedar të vetëm, dhe dështimi duket si një refuzim i përgjithshëm pa asnjë mesazh OpenVPN.

Dështime që klienti nuk mund t’i raportojë

Disa rezultate vendosen në skajin e largët. Një portë që përgjigjet me një status HTTP dhe e mbyll lidhjen të ka thënë për gjendjen e vet, dhe hapi tjetër i dobishëm është log-u i saj ose llogaria pas kredencialit, jo skedarët e tu lokalë. Në atë skenar asgjë lokale nuk është e prishur, dhe redaktimi i profilit për kompensim e bën diagnozën tjetër më të vështirë. Lexo atë log para se të prekësh konfigurimin e klientit.

Një rast tjetër i heshtur është një klient që funksionon si duhet. Një tunel në modalitetin klient nuk dëgjon kurrë në një port, prandaj një kontroll që pret një dëgjues të hapur nuk raporton asgjë dhe duket si dështim. Konfirmo cilin modalitet nise para se të nxjerrësh një përfundim nga një listë portesh bosh.

Puno shtresat me radhë: a ekziston unit-i dhe a është i saktë emri i instancës, a arriti diçka në journal ose në skedarin --log, cili binare dhe profil ekzekutuan vërtet, dhe a është dështimi lokal apo i largët. Çdo përgjigje heq një shtresë. Të fillosh nga profili do të thotë të rishkruash një skedar që ndoshta nuk u hap kurrë.