Diçka nis vazhdimisht një njësi OpenVPN: gjeni burimin

Një instancë OpenVPN shfaqet në nisje me një emër që nuk e njihni, dhe ndalimi i saj funksionon deri në rinisjen tjetër. Ky model do të thotë që keni hequr procesin, por jo aktivizimin. Janë dy objekte të ndryshme, dhe vetëm njëri prej tyre është i dukshëm në një ekran statusi. Gjetja e aktivizimit kërkon katër komanda vetëm-lexim dhe një vendim.

Fillimisht emërtoni njësinë e saktë

Nisni nga emri i njësisë në journal, jo nga emri i një skedari profili. Instanca mund të quhet openvpn@, openvpn-client@, openvpn-server@ ose diçka specifike për shpërndarjen, dhe hamendësimi i emrit ju çon te shablloni i gabuar. Dalja e statusit emërton njësinë që ekzekutohej në të vërtetë, dhe ky është emri i vetëm që ka rëndësi këtu. Kopjojeni saktësisht, duke përfshirë çdo prapashtesë.

Komandat e mëposhtme përshkruajnë atë njësi pa ndryshuar asgjë. systemctl show raporton shtegun e fragmentit, shtegun e burimit, gjendjen e skedarit të njësisë, çdo drop-in dhe çfarë e aktivizoi. list-dependencies --reverse tregon cilat njësi të ngarkuara tregojnë drejt saj. Të dyja janë vetëm-lexim, prandaj ekzekutojini përpara se të formoni një teori.

Zëvendësoni emrin e vëzhguar kudo. Një emër shembulli i kopjuar është mënyra më e zakonshme për të hetuar shërbimin e gabuar, dhe jep përgjigje të sigurta për një njësi që nuk ekzekutohej kurrë.

Lexoni shabllonin për të mësuar emrin e skedarit

Një njësi instance është një zgjerim i një shablloni, dhe shablloni vendos cilin skedar konfigurimi lexon. Një rresht komande që përfundon me një vendmbajtës specifik për instancën zgjidhet në emrin e instancës plus prapashtesën. Nëse prapashtesa është .conf dhe instanca quhet old, skedari është old.conf. Nëse e quani instancën old.conf, i njëjti shabllon kërkon old.conf.conf.

Ky detaj shpjegon një klasë dublikatash. Dikush shton një instancë të dytë me emrin e gabuar, e para vazhdon të ekzekutohet, dhe hosti përfundon me dy tunele dhe një regjistër konfuz.

Lexoni shabllonin efektiv në vend të skedarit që mendoni se keni redaktuar. Një drop-in mund të zëvendësojë rreshtin e komandës, dhe zëvendësimi është ai që ekzekutohet në nisje.

Ndiqni si hyn në transaksionin e nisjes

Tre rrugë janë të zakonshme: një lidhje wants nga një objektiv, një kërkesë nga një njësi tjetër, ose një njësi e gjeneruar nga një gjenerator pakete. Lista e varësive të anasjella mbulon dy të parat si zëra të ngarkuar të grafikut. Nuk mbulon një kohëmatës, një goditës apo një kërkesë të jashtme, prandaj lista është provë dhe jo një auditim i plotë.

Dalja e gjeneruar nën /run/systemd/generator është produkt, jo burim. Redaktimi i saj mbijeton vetëm deri në gjenerimin tjetër, prandaj një korrigjim i aplikuar atje duket i suksesshëm dhe pastaj kthehet.

Kontrolloni hyrjen e dokumentuar të paketës përpara se të supozoni nga lexon gjeneratori. Një skanim i padokumentuar i një direktorie është arsyeja e zakonshme pse një njësi shfaqet pa një lidhje aktivizimi.

Hiqni aktivizimin, jo vetëm procesin

Nëse instanca është aktivizuar drejtpërdrejt dhe është vërtet e vjetruar, systemctl disable --now e ndalon dhe heq lidhjen e nisjes në një hap. Kontrolloni së pari që ky tunel nuk është rruga juaj e vetme administrative drejt hostit. Komanda është shembull i ciklit të jetës, jo sugjerim për të ndaluar çdo VPN në makinë. Ekzekutoni kontrollin para komandës, jo pas saj.

Dy gjysmat janë të ndashme dhe shpesh ngatërrohen. Çaktivizimi nuk ndalon një shërbim në punë, dhe ndalimi nuk heq aktivizimin, prandaj një komandë e pjesshme shpjegon një problem që kthehet në nisje.

Një njësi e çaktivizuar mund të niset ende nga një njësi tjetër ose nga një kërkesë e shprehur. Kur gjeneratori zotëron aktivizimin, rregulloni hyrjen e gjeneratorit në vend që të çaktivizoni daljen e tij. Maskimi bllokon më shumë rrugë, por mund të thyejë varësitë, prandaj nuk zëvendëson kuptimin.

Verifikoni me një rinisje, jo me një ekran statusi

Ringarkoni systemd nëse kanë ndryshuar përkufizimet e njësive ose hyrjet e gjeneratorit, pastaj inspektoni gjendjen që rezulton. Ringarkimi i daemon-it nuk shtyn një profil të ri në një tunel në punë, prandaj dy kontrollet janë të ndara. Planifikoni një rinisje dhe konfirmoni që instanca mbetet e papranishme ndërsa tuneli i synuar vazhdon të funksionojë.

Mbajeni profilin e vjetër derisa të kuptohet pronësia e tij, pastaj tërhiqeni përmes procesit të synuar. Suksesi është një njësi e papranishme dhe një rrugë aksesi që funksionon, jo një njësi e dështuar që mungon në një ekran.