OpenVPN ei käivitu ja veateadet pole? Vaadake journalit

Käsk naaseb, teenus kuvatakse nurjununa ja terminali ei jõua midagi seletust meenutavat. See vaikus on sümptom, mida inimesed kirjeldavad kui «OpenVPN ei käivitu», ja see ei tähenda peaaegu kunagi, et programm suri ilma midagi ütlemata. See tähendab, et teade läks kanalisse, mida te ei lugenud, või et see, mida käivitasite, ei olnud see, mida konfigureerisite. Mõlemat juhtumit saab diagnoosida vähem kui minutiga, kui lõpetate profiili kahtlustatavana kohtlemise.

Väljundit neelavad neli kohta: uniti journal, ühendust omav plugin, tunneli teine ots ja teine binaar kui see, mis teie arvates töötab. Igal on oma kontroll.

Vaikus tähendab, et te ei jälginud õiget kanalit

Esiplaanil kutse prindib teie terminali. Unit prindib journalisse ja nurjunud unit võib väljuda enne, kui üldse midagi kirjutab, kui viga on selles, kuidas see käivitati, mitte selles, mida sellele öeldi. Vahe on oluline: journalis pole ühtegi kannet, mis tähendab, et protsess ei töötanud kunagi päriselt, samas kui üks kanne, millele järgneb väljumine, tähendab, et see töötas ja lükkas midagi tagasi.

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

Lisage systemctl show -p Result -p ExecMainStatus openvpn-client@office puhta väljumise eristamiseks signaalist. Olek 1 koos Result=exit-code on programmi otsus; Result=signal või ajapiirang viitavad hoopis keskkonnale, ja ükski profiili redigeerimine ei muuda seda. Kirjutage mõlemad väärtused üles enne millegi taaskäivitamist, sest taaskäivitamine kustutab nende tekitanud mööduva oleku.

Instantsi nimi on osa teest

Pakendatud mall-unit ei võta failiteed. See võtab instantsi nime ja see nimi lisatakse kataloogile profiili leidmiseks: office lahendatakse /etc/openvpn/client/office.conf Debiani ja Ubuntu pakendis. Fail nimega office-v2.conf käivitatuna kui @office ei loeta kunagi ja unit väljub vaikselt, sest selle vaatenurgast polnud midagi teha. Otsingukataloog erineb kliendi- ja serverirežiimis, seega sama viga osutab mallivahetusel hoopis mujale.

See lahknevus on vaikse nurjumise kõige tavalisem allikas ja profiilis nähtamatu, sest profiil on korras. Loetlege, mis tegelikult olemas on, ja võrrelge kahte nime märk märgi haaval, sealhulgas iga laiend, mida pakend eeldab.

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

Kui unit on lubatud, aga ühtegi instantsi pole loetletud, võib lubamine ise viidata nimele, mis hiljem ümber nimetati. Õige instantsi uuesti lubamisest tavaliselt piisab, ja maha jäänud vana unit-fail tasub kustutada, et see järgmist inimest ei segaks. Mahajäänud unit-fail on väike asi, mis maksab kellelegi hiljem tunni.

Kui plugin omab tunnelit, ei näe terminal midagi

Töölaua apletist käivitatud ühendust omab NetworkManager ja selle OpenVPN-väljund läheb selle teenuse journalisse, mitte üheski avatud shellis. Kliendi käsitsi käivitamine ja mitte millegi nägemine on selles korralduses ootuspärane, sest käsitsi käivitatud protsess ei ole see, mis ühendust kannab.

Otsige journalist teenust, mis seda omab, ja korrake seejärel parsitöötlust teile loetava detailsusega. Kaks allolevat käsku vaatavad sama nurjumise eri omanikke.

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

Eraldiseisev käivitus on sõnumite lugemiseks, mitte hallatava ühenduse asendamiseks, ja need kaks erinevad hiljem: DNS-integratsioon, marsruudid ja eluiga kuuluvad pluginile. Parsimisvea parandamine eraldiseisvas käivituses ei paranda automaatselt nimede lahendamist, kui aplet üle võtab, seega hoidke kaks tähelepanekut eraldi.

Kaks binaari, üks PATH

Käsitsi ehitatud paigaldus all /usr/local võidab shelli kutse puhul, sest /usr/local/sbin eelneb /usr/sbin-le Ubuntu vaikimisi PATH-is. Unit ei kasuta sinu PATH-i; see käivitab absoluutse tee, mis on kirjutatud ExecStart. Nii võivad terminalis töötav versioon ja teenusena nurjuv versioon olla tõesti erinevad programmid.

Võrrelge neid kahte enne millegi ümberehitamist. Kolmas käsk on see, mis otsustab vaidluse.

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

Veel üks keskkonnaerinevus peitub samas kohas. Pakendatud unit toetub /run all olevale käituskataloogile, mille systemd selle jaoks loob; käsitsi kirjutatud asendusunit, mis selle seade välja jätab, võib nurjuda enne ühegi faili avamist, ja nurjumine näeb välja nagu üldine keeldumine ilma ühegi OpenVPN-sõnumita.

Nurjumised, mida klient ei saa teatada

Osa tulemustest otsustatakse kaugemas otsas. Lüüs, mis vastab HTTP-staatusega ja sulgeb ühenduse, on teile oma olekust teatanud, ja kasulik järgmine samm on selle logi või identimisandmete taga olev konto, mitte teie kohalikud failid. Selles stsenaariumis ei ole miski kohalik katki, ja profiili kompenseeriv redigeerimine teeb järgmise diagnoosi raskemaks. Lugege seda logi enne, kui puudutate kliendi konfiguratsiooni.

Teine vaikne juhtum on klient, mis töötab korrektselt. Kliendirežiimis tunnel ei kuula kunagi porti, nii et avatud kuulajat ootav kontroll ei teatagi millestki ja näeb välja nagu nurjumine. Kinnitage, millise režiimi käivitasite, enne kui teete tühjast pordiloendist järelduse.

Töötage kihid järjekorras: kas unit on olemas ja kas instantsi nimi on õige, kas midagi jõudis journalisse või faili --log, milline binaar ja profiil tegelikult töötasid, ja kas nurjumine on kohalik või kaugemal. Iga vastus eemaldab ühe kihi. Profiilist alustamine tähendab faili ümberkirjutamist, mida ei pruugitud kunagi avada.