May paulit-ulit na nagpapatakbo ng OpenVPN unit: hanapin ang pinagmulan

May OpenVPN instance na lumalabas sa boot sa ilalim ng pangalang hindi mo kilala, at gumagana ang paghinto nito hanggang sa susunod na reboot. Ang pattern na iyon ay nangangahulugang inalis mo ang proseso pero hindi ang activation. Dalawang magkaibang bagay ang mga ito, at isa lamang sa kanila ang nakikita sa status screen. Ang paghahanap ng activation ay nangangailangan ng apat na read-only na utos at isang desisyon.

Pangalanan muna ang eksaktong unit

Magsimula sa pangalan ng unit sa journal, hindi sa pangalan ng profile file. Maaaring tinatawag ang instance na openvpn@, openvpn-client@, openvpn-server@ o isang bagay na partikular sa distribution, at ang paghula sa pangalan ay magdadala sa iyo sa maling template. Binabanggit ng status output ang unit na talagang tumakbo, at iyon ang tanging pangalan na mahalaga dito. Kopyahin ito nang eksakto, kasama ang anumang suffix.

Inilalarawan ng mga sumusunod na utos ang unit na iyon nang walang binabago. Iniulat ng systemctl show ang fragment path, ang source path, ang unit file state, anumang drop-ins at kung ano ang nag-trigger nito. Ipinapakita ng list-dependencies --reverse kung aling mga load na unit ang tumuturo dito. Parehong read-only ang mga ito, kaya patakbuhin ang mga ito bago bumuo ng teorya.

Palitan ang naobserbahang pangalan sa lahat ng dako. Ang nakopyang halimbawang pangalan ay ang pinakakaraniwang paraan ng pagsisiyasat sa maling serbisyo, at nagbibigay ito ng matatag na sagot tungkol sa unit na hindi kailanman tumakbo.

Basahin ang template para malaman ang pangalan ng file

Ang instance unit ay pagpapalawak ng isang template, at ang template ang nagpapasya kung aling configuration file ang binabasa nito. Ang command line na nagtatapos sa placeholder na partikular sa instance ay nireresolba sa pangalan ng instance kasama ang suffix. Kung ang suffix ay .conf at ang instance ay tinatawag na old, ang file ay old.conf. Kung pangalanan mo ang instance na old.conf, hihingin ng parehong template ang old.conf.conf.

Ipinapaliwanag ng detalyeng iyon ang isang klase ng duplicate. May nagdaragdag ng pangalawang instance sa maling pangalan, patuloy na tumatakbo ang una, at nauuwi ang host sa dalawang tunnel at isang nakakalitong log.

Basahin ang epektibong template kaysa sa file na naaalala mong in-edit mo. Maaaring palitan ng drop-in ang command line, at ang kapalit ang tumatakbo sa boot.

Sundan kung paano ito pumapasok sa boot transaction

Tatlong ruta ang karaniwan: isang wants link mula sa isang target, isang requirement mula sa ibang unit, o isang generated unit mula sa package generator. Sinasaklaw ng listahan ng reverse dependencies ang unang dalawa bilang mga load na graph entry. Hindi nito sinasaklaw ang isang timer, hook o external na kahilingan, kaya ang listahan ay ebidensya at hindi kumpletong audit.

Ang generated output sa ilalim ng /run/systemd/generator ay produkto, hindi pinagmulan. Ang pag-edit nito ay tumatagal lamang hanggang sa susunod na generation, kaya ang pagbabagong inilapat doon ay mukhang matagumpay at pagkatapos ay bumabalik.

Suriin ang dokumentadong input ng package bago ipagpalagay kung saan nagbabasa ang generator. Ang hindi dokumentadong pag-scan ng isang directory ang karaniwang dahilan kung bakit lumalabas ang isang unit nang walang activation link.

Alisin ang activation, hindi lamang ang proseso

Kung ang instance ay direktang naka-enable at talagang lipas na, hinihinto ito ng systemctl disable --now at inaalis ang boot link sa isang hakbang. Suriin muna na ang tunnel na ito ay hindi ang tanging administratibong landas mo patungo sa host. Ang utos ay halimbawa ng lifecycle, hindi mungkahi na ihinto ang bawat VPN sa makina. Patakbuhin ang pagsusuri bago ang utos, hindi pagkatapos.

Ang dalawang kalahati ay mapaghihiwalay at madalas napagkakamalan. Ang pag-disable ay hindi naghihinto ng tumatakbong serbisyo, at ang paghinto ay hindi nag-aalis ng enablement, kaya ang bahagyang utos ay nagpapaliwanag ng problemang bumabalik sa boot.

Ang naka-disable na unit ay maaari pa ring simulan ng ibang unit o ng tahasang kahilingan. Kapag ang generator ang may-ari ng activation, ayusin ang input ng generator sa halip na i-disable ang output nito. Hinaharangan ng masking ang mas maraming landas pero maaaring makasira ng dependencies, kaya hindi ito kapalit ng pag-unawa.

I-verify sa reboot, hindi sa status screen

I-reload ang systemd kung nagbago ang unit definitions o generator inputs, pagkatapos suriin ang resultang state. Ang daemon reload ay hindi nagtutulak ng bagong profile sa tumatakbong tunnel, kaya magkahiwalay ang dalawang pagsusuri. Mag-iskedyul ng reboot at kumpirmahin na nananatiling wala ang instance habang gumagana pa rin ang nilalayong tunnel.

Panatilihin ang lumang profile hanggang maunawaan ang pagmamay-ari nito, pagkatapos ay alisin ito sa pamamagitan ng nilalayong proseso. Ang tagumpay ay isang wala na unit at gumaganang access path, hindi isang nabigong unit na kulang sa isang screen.