OpenVPN neįsijungia be klaidos? Pažiūrėkite į journal

Komanda grįžta, paslauga rodoma kaip nepavykusi, ir niekas, kas primena paaiškinimą, nepasiekia terminalo. Ta tyla yra simptomas, kurį žmonės apibūdina kaip „OpenVPN neįsijungia“, ir tai beveik niekada nereiškia, kad programa mirė nieko nesakiusi. Tai reiškia, kad pranešimas nuėjo į kanalą, kurio neskaitėte, arba kad tai, ką paleidote, nebuvo tai, ką sukonfigūravote. Abiem atvejais diagnozę galima nustatyti per mažiau nei minutę, kai nustojate laikyti profilį įtariamuoju.

Išvestį sugeria keturios vietos: unit journal, jungtį valdantis papildinys, kitas tunelio galas ir kitas dvejetainis failas nei tas, kuris, jūsų manymu, veikia. Kiekvienas turi savo patikrinimą.

Tyla reiškia, kad stebėjote ne tą kanalą

Kvietimas priekiniame plane spausdina į jūsų terminalą. Unit spausdina į journal, o nepavykęs unit gali išeiti dar nieko neparašęs, jei gedimas yra tame, kaip jis buvo paleistas, o ne tame, kas jam buvo pasakyta. Šis skirtumas svarbus: nėra įrašo journal reiškia, kad procesas niekada iš tikrųjų neveikė, o vienas įrašas ir po jo išėjimas reiškia, kad jis veikė ir kažką atmetė.

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

Pridėkite systemctl show -p Result -p ExecMainStatus openvpn-client@office kad atskirtumėte švarų išėjimą nuo signalo. Būsena 1 su Result=exit-code yra programos sprendimas; Result=signal arba laiko limitas nurodo aplinką, ir joks profilio redagavimas to nepakeis. Užsirašykite abi reikšmes prieš ką nors paleisdami iš naujo, nes paleidimas iš naujo ištrina laikiną būseną, kuri jas sukūrė.

Instancijos pavadinimas yra kelio dalis

Supakuotas šablono unit nepriima failo kelio. Jis priima instancijos pavadinimą, ir tas pavadinimas pridedamas prie katalogo, kad būtų rastas profilis: office Debian ir Ubuntu paketuose išsprendžiamas į /etc/openvpn/client/office.conf. Failas pavadinimu office-v2.conf, paleistas kaip @office niekada neskaitomas, ir unit tyliai išeina, nes jo požiūriu nebuvo ką veikti. Paieškos katalogas skiriasi kliento ir serverio režimu, todėl ta pati klaida keičiant šabloną nurodo visai kitą vietą.

Tas neatitikimas yra dažniausia tylios nesėkmės priežastis, ir jis profilyje nematomas, nes profilis tvarkingas. Išvardykite, kas iš tiesų egzistuoja, ir palyginkite du pavadinimus po ženklą, įskaitant bet kokį plėtinį, kurio tikisi paketas.

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

Jei unit įjungtas, bet nė viena instancija nenurodyta, pats įjungimas gali nurodyti pavadinimą, kuris vėliau buvo pervadintas. Pakanka paprastai iš naujo įjungti teisingą instanciją, o likusį seną unit failą verta ištrinti, kad jis nesupainiotų kito žmogaus. Likęs unit failas yra smulkmena, kuri vėliau kam nors kainuoja valandą.

Kai papildinys valdo tunelį, terminalas nieko nemato

Ryšį, pradėtą iš darbalaukio applet, valdo NetworkManager, ir jo OpenVPN išvestis eina į tos paslaugos journal, o ne į jūsų atidarytą shell. Paleisti klientą rankiniu būdu ir nieko nematyti šioje struktūroje yra normalu, nes rankiniu būdu paleistas procesas nėra tas, kuris neša ryšį.

Journal ieškokite paslaugos, kuri jį valdo, tada atkurkite analizę tokiu išsamumu, kurį galite perskaityti. Dvi žemiau esančios komandos žiūri į skirtingus tos pačios nesėkmės savininkus.

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

Savarankiškas paleidimas skirtas pranešimams skaityti, o ne valdomam ryšiui pakeisti, ir abu po to skiriasi: DNS integracija, maršrutai ir gyvavimo trukmė priklauso papildiniui. Analizės klaidos ištaisymas savarankiškame paleidime automatiškai neištaiso vardų skyrimo, kai applet perima valdymą, todėl laikykite abu stebėjimus atskirai.

Du dvejetainiai failai, vienas PATH

Rankiniu būdu sukurtas diegimas po /usr/local laimi shell kvietime, nes /usr/local/sbin eina prieš /usr/sbin numatytajame Ubuntu PATH. Unit nenaudoja jūsų PATH; jis vykdo absoliutų kelią, įrašytą ExecStart. Taigi versija, kuri veikia jūsų terminale, ir versija, kuri nepavyksta kaip paslauga, gali būti tikrai skirtingos programos.

Palyginkite abu prieš ką nors perstatydami. Trečioji komanda yra ta, kuri nusprendžia ginčą.

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

Dar vienas aplinkos skirtumas slepiasi toje pačioje vietoje. Supakuotas unit remiasi vykdymo katalogu po /run , kurį systemd jam sukuria; ranka rašytas pakaitinis unit, kuris praleidžia tą nustatymą, gali nepavykti dar neatvėręs nė vieno failo, ir gedimas atrodo kaip bendras atmetimas be jokio OpenVPN pranešimo.

Gedimai, apie kuriuos klientas negali pranešti

Kai kurie rezultatai nusprendžiami tolimame gale. Vartai, kurie atsako HTTP būsena ir uždaro ryšį, jums papasakojo apie savo būseną, ir naudingas kitas žingsnis yra jų žurnalas arba paskyra už kredencialų, o ne jūsų vietiniai failai. Tame scenarijuje vietiškai niekas nesugedę, o profilio redagavimas kompensacijai apsunkina kitą diagnozę. Perskaitykite tą žurnalą prieš liesdami kliento konfigūraciją.

Kitas tylus atvejis yra teisingai veikiantis klientas. Kliento režimo tunelis niekada neklauso prievado, todėl patikra, kuri tikisi atviro klausytojo, nieko nepraneš ir atrodys kaip gedimas. Patvirtinkite, kurį režimą paleidote, prieš darydami išvadą iš tuščio prievadų sąrašo.

Dirbkite sluoksnius iš eilės: ar unit egzistuoja ir ar instancijos pavadinimas teisingas, ar kas nors pasiekė journal ar failą --log , kuris dvejetainis failas ir profilis iš tikrųjų veikė, ir ar gedimas vietinis, ar nuotolinis. Kiekvienas atsakymas pašalina sluoksnį. Pradėti nuo profilio reiškia perrašyti failą, kuris galbūt niekada nebuvo atidarytas.