OpenVPN se ne zažene brez napake? Poglejte v journal

Ukaz se vrne, storitev se prikaže kot neuspešna in v terminal ne prispe nič, kar bi spominjalo na razlago. Ta tišina je simptom, ki ga ljudje opisujejo kot «OpenVPN se ne zažene», in skoraj nikoli ne pomeni, da je program umrl, ne da bi karkoli povedal. Pomeni, da je sporočilo šlo v kanal, ki ga niste brali, ali da to, kar ste zagnali, ni bilo to, kar ste konfigurirali. Oba primera je mogoče diagnosticirati v manj kot minuti, ko prenehate obravnavati profil kot osumljenca.

Izhod vsrkajo štiri mesta: journal enote, vtičnik, ki ima povezavo, drugi konec tunela in druga binarna datoteka od tiste, za katero mislite, da teče. Vsako ima svoje preverjanje.

Tišina pomeni, da niste gledali pravega kanala

Klic v ospredju tiska v vaš terminal. Enota tiska v journal, neuspešna enota pa lahko izstopi, še preden karkoli zapiše, če je napaka v tem, kako je bila zagnana, in ne v tem, kar ji je bilo rečeno. Ta razlika je pomembna: brez vnosa v journalu pomeni, da proces nikoli ni res tekel, medtem ko en vnos in za njim izstop pomeni, da je tekel in nekaj zavrnil.

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

Dodajte systemctl show -p Result -p ExecMainStatus openvpn-client@office za ločevanje čistega izstopa od signala. Status 1 z Result=exit-code je odločitev programa; Result=signal ali časovna omejitev kažeta bolj na okolje in nobeno urejanje profila tega ne bo spremenilo. Zapišite obe vrednosti, preden karkoli znova zaženete, ker ponovni zagon izbriše prehodno stanje, ki ju je ustvarilo.

Ime instance je del poti

Pakirana predloga enote ne sprejme poti do datoteke. Sprejme ime instance, to ime pa se doda imeniku, da se profil najde: office se v paketih Debian in Ubuntu razreši v /etc/openvpn/client/office.conf. Datoteka z imenom office-v2.conf, zagnana kot @office se nikoli ne prebere in enota tiho izstopi, ker z njenega vidika ni bilo kaj početi. Imenik iskanja se razlikuje med načinom odjemalca in strežnika, zato ista napaka ob zamenjavi predloge kaže povsem drugam.

To neskladje je najpogostejši vir tihe napake in je v profilu nevidno, ker je profil v redu. Naštejte, kaj v resnici obstaja, in primerjajte imeni znak za znakom, vključno z vsako končnico, ki jo paket pričakuje.

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

Če je enota omogočena, a ni navedene nobene instance, lahko samo omogočanje sklicuje na ime, ki je bilo pozneje preimenovano. Ponovno omogočanje prave instance običajno zadostuje, staro preostalo datoteko enote pa je vredno izbrisati, da ne zmede naslednje osebe. Preostala datoteka enote je malenkost, ki nekoga pozneje stane eno uro.

Ko vtičnik poseduje tunel, terminal ne vidi ničesar

Povezavo, zagnano iz apleta na namizju, ima v lasti NetworkManager, njen izhod OpenVPN pa gre v journal te storitve in ne v lupino, ki jo imate odprto. Zaganjanje odjemalca ročno in ničesar ne videti je v tej ureditvi pričakovano, ker ročno zagnani proces ni tisti, ki nosi povezavo.

V journalu poiščite storitev, ki jo ima v lasti, nato ponovite razčlenjevanje s podrobnostjo, ki jo lahko preberete. Dva spodnja ukaza gledata različne lastnike iste napake.

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

Samostojni zagon je za branje sporočil, ne za zamenjavo upravljane povezave, in oba se nato razlikujeta: integracija DNS, poti in življenjska doba pripadajo vtičniku. Odprava napake razčlenjevanja v samostojnem zagonu ne odpravi samodejno razreševanja imen, ko aplet prevzame nadzor, zato imejte obe opažanji ločeni.

Dva binarna, en PATH

Ročno zgrajena namestitev pod /usr/local zmaga pri klicu iz lupine, ker /usr/local/sbin pride pred /usr/sbin v privzetem PATH Ubuntu. Enota ne uporablja vašega PATH; izvaja absolutno pot, zapisano v ExecStart. Različica, ki deluje v vašem terminalu, in različica, ki ne uspe kot storitev, sta lahko res različna programa.

Primerjajte oba, preden karkoli znova zgradite. Tretji ukaz je tisti, ki odloči spor.

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

Še ena razlika v okolju se skriva na istem mestu. Pakirana enota se zanaša na imenik za izvajanje pod /run, ki ga systemd ustvari zanjo; ročno napisana nadomestna enota, ki to nastavitev izpusti, lahko ne uspe, preden odpre eno samo datoteko, in napaka je videti kot splošna zavrnitev brez kakršnega koli sporočila OpenVPN.

Napake, ki jih odjemalec ne more prijaviti

Nekateri izidi se odločijo na oddaljenem koncu. Prehod, ki odgovori s statusom HTTP in zapre povezavo, vam je povedal o svojem stanju, naslednji koristen korak pa je njegov dnevnik ali račun za poverilnicami, ne vaše krajevne datoteke. V tem scenariju krajevno ni nič pokvarjeno in urejanje profila za kompenzacijo oteži naslednjo diagnostiko. Preberite ta dnevnik, preden se dotaknete konfiguracije odjemalca.

Drug tih primer je odjemalec, ki deluje pravilno. Tunel v načinu odjemalca nikoli ne posluša na vratih, zato preverjanje, ki pričakuje odprtega poslušalca, ne bo nič sporočilo in bo videti kot napaka. Potrdite, kateri način ste zagnali, preden iz praznega seznama vrat potegnete sklep.

Predelajte plasti po vrsti: ali enota obstaja in ali je ime instance pravilno, ali je kaj prispelo v journal ali datoteko --log, katera binarna datoteka in profil sta res tekla, in ali je napaka krajevna ali oddaljena. Vsak odgovor odstrani eno plast. Začeti pri profilu pomeni prepisati datoteko, ki morda ni bila nikoli odprta.