OpenVPN rodo active (exited)? Raskite egzempliorių, kurį paleidote

Tikrinate tunelį, vykdote systemctl status openvpn ir gaunate active (exited) be Main PID ir su tuščiu procesų sąrašu. Natūralus skaitymas yra toks, kad paslauga paleista ir mirė, todėl atidarote unit, randate /bin/true ir darote išvadą, kad paketas sugedęs. Debian pakete ši būsena yra wrapper, veikiantis taip, kaip suprojektuota, o tunelis gyvena viename iš instance unit, kuriuos jis paleidžia. Bendras unit niekada nepasakys, kuris egzempliorius jį pastatė.

Ką active (exited) iš tikrųjų reiškia šiame unite

Supakuotas unit yra vienkartinė užduotis: jo ExecStart yra /bin/true, o RemainAfterExit=yes yra tai, kas baigtą unit palaiko praneštą kaip active (exited). Pašalinkite tą direktyvą ir ta pati sėkminga /bin/true užduotis baigiasi inactive (dead), o tai yra būtent ta būsena, kurios žmonės tikisi ir kurią neteisingai perskaito priešinga kryptimi. Komanda yra tik vietos žymeklis, o unit praneša apie darbą, kurį atlieka kiti unit. Šioje tvarkoje niekas nesugedę, o /bin/true pakeitimas keičia pakavimo sutartį, o ne tunelį.

Wrapper deleguoja. Jis paleidžia instance unit, kuriuos pateikia paketo konfigūracija arba jos systemd generatorius, todėl tuščias procesų sąrašas nieko neįrodo apie tunelį. Kai nepasirinktas nė vienas egzempliorius, wrapper vis tiek pavyksta ir vis tiek nieko nepaleidžia. Būsena atsako, ar wrapper veikė, o ne ar yra tunelis.

Skaitykite tris status išvesties eilutes, o ne žodį skliausteliuose. Loaded nurodo unit failą, kurį perskaitė systemd, Active turi paskutinio sėkmingo paleidimo laiko žymą, o trūkstamas Main PID atitinka baigtą vienkartinę užduotį. Tos trys eilutės taip pat yra būdas atskirti šį wrapper nuo paslaugos, kuri subyrėjo praėjus sekundei po paleidimo.

Išvardykite unit prieš dar kartą skaitydami status

Paklauskite systemd, kas egzistuoja, prieš klausdami, kas veikia. Šablonas gali būti įdiegtas, kol nesukurtas nė vienas egzempliorius, ir tik sukurtas unit turi tunelį. Pradėkite nuo įkeltos aibės:

systemctl list-units 'openvpn*'

Tas sąrašas yra tai, ką systemd įkėlė šiuo metu, ir tai yra artimiausia tunelių inventorizacijai. Įdiegti unit failai atsako į kitą klausimą, o tas sąrašas vis tiek rodo šabloną, kai nieko nesukurta:

systemctl list-unit-files 'openvpn*'

Skaitykite abu sąrašus kartu, nes šablonas antrajame ir egzempliorius pirmajame yra skirtingi atsakymai. Egzistuojantis šablonas ir veikiantis egzempliorius nėra tas pats faktas, ir tik antrasis reiškia tunelį. Paketų išdėstymai skiriasi ir tarp distribucijų bei OpenVPN versijų. Senesnis openvpn@ šablonas, atskira client ir server pora bei distribucijos wrapper gali būti teisėti savo pakavime.

Prisitaikykite prie savo mašinos, o ne prie rasto vadovo. Egzemplioriaus pavadinimas kito žmogaus išvestyje gali būti office, o jūsų - home arba work. Perduodamas metodas, o ne eilutė.

Sekite egzemplioriaus pavadinimą iki failo, kurį jis skaito

Upstream client šablone unit darbo katalogas yra /etc/openvpn/client ir jo komanda iš ten ima %i.conf, todėl openvpn-client@office skaito /etc/openvpn/client/office.conf. Patvirtinkite šį atitikimą įdiegtame unite, o ne pasitikėkite pavyzdžiu, nes jūsų šablonas gali būti senesnis arba distribucijos perrašytas:

systemctl cat [email protected]

Skaitykite drop-in, kurie pasirodo tos išvesties apačioje, nes failas po .d/ gali pakeisti ExecStart, darbo katalogą arba konfigūracijos kelią. Profilis, kurį atsisiuntėte kaip office.ovpn, nėra failas, kurį atidaro egzempliorius. Šis tarpas yra įprasta priežastis, kodėl klaida nurodo kelią, kurio niekada nekeitėte.

Santykiniai keliai profilio viduje yra kita spąsta. Perkeliant pagrindinį failą, kai ca, cert ir key nuorodos lieka santykinės, dingusio failo klaida pakeičiama kita dingusio failo klaida. Antroji nurodo failą, kuris, buvote tikri, egzistuoja, todėl profilio katalogas svarbesnis už failo pavadinimą.

Paleiskite jį ir tada skaitykite to egzemplioriaus žurnalą

Paleiskite egzempliorių, kurį ką tik patikrinote, nes bendro unit žurnale nebus tunelio klaidų. Tada skaitykite šio paleidimo žurnalą ir šia tvarka ieškokite konfigūracijos klaidos, failo prieigos klaidos ir ryšio klaidos, nes kiekviena iš jų nepavyksta skirtingame paleidimo etape.

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

Paleidimas ir įjungimas yra atskiri sprendimai: start vykdo unit dabar, enable tvarko kitą paleidimą, o enable --now daro abu vienu žingsniu. daemon-reload iš naujo skaito unit apibrėžimus ir nepaleidžia iš naujo veikiančio proceso bei netaiko pakeisto profilio. Pakeitę profilį, paleiskite egzempliorių iš naujo, nes būtent tai iš naujo skaito failą.

Nedėkite antro valdytojo į tą patį tunelį

NetworkManager ir OpenVPN 3 sesijų valdytojai turi savo ryšio būseną, o systemd egzempliorius šalia vieno jų padeda du savininkus ant to paties tunelio. Simptomas yra tunelis, kuris pakyla ir po kelių sekundžių pakeičiamas, arba toks, kuris atsisako likti sustabdytas. Pasirinkite valdytoją, kurį jūsų distribucija dokumentuoja darbalaukiui, ir serveryje sąmoningai naudokite systemd.

Prieš paleisdami egzempliorių patikrinkite, ar jau yra savininkas. Kai darbalaukio applet rodo ryšį, paleistas egzempliorius su juo konkuruoja, o ne jį papildo. Išjunkite nenaudojamą valdytoją, o ne paleiskite abu ir tikėkitės, kad tvarka išsilaikys. Tas konfliktas taip pat paaiškina žurnalus, kuriuose tunelis sukuriamas, o paskui sugriaunamas proceso, kurio niekada nepaleidote.

Atsakykite į pradinį klausimą egzemplioriaus pavadinimu, jo perskaitytu failu ir nepavykusia žurnalo eilute. OpenVPN pastabos apie systemd integraciją aprašo šablono išdėstymą ir failo atitikimą, per kurį išsprendžiamas egzemplioriaus pavadinimas.