OpenVPN u nis por nuk shtypi asgjë: së pari kontrollo log-append

E nis OpenVPN nga një shell me një skedar konfigurimi, dhe terminali qëndron aty pa asnjë dalje. Asnjë banner, asnjë gabim, asnjë prompt. Instinkti thotë se nisja dështoi, kështu që nis një kopje tjetër, pastaj një tjetër, dhe makina përfundon me disa instanca gjysmë të konfiguruara. Para gjithë kësaj, kontrollo në profil një direktivë që e ka ridrejtuar tashmë regjistrin diku tjetër. Heshtja është veti e konsolës, jo e procesit.

Heshtja ka dy shpjegime shumë të ndryshme

E para është se procesi po punon mirë dhe po shkruan në një skedar që nuk po e vëzhgon. E dyta është se ai doli menjëherë me një gabim të regjistruar në të njëjtin skedar.

Të dyja lënë një terminal bosh, dhe një pyetje i ndan: a ka tani një proces, dhe çfarë është në skedarin që iu tha të shkruante. Përgjigju asaj përpara se të prekësh përsëri konfigurimin. Rinisja për të marrë dalje është mënyra se si dy instanca fillojnë të zihen për një pajisje tuneli dhe të njëjtin port, gjë që prodhon gabime që nuk kanë asnjë lidhje me problemin fillestar.

Gjej direktivën, pastaj gjej procesin.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Gjej destinacionin që përdor procesi që po punon

Lexo profilin me të cilin procesi u nis në të vërtetë, jo atë që redaktove. Një instancë e menaxhuar nga një shërbim zakonisht ngarkon një shteg tjetër dhe punon në një drejtori tjetër pune, kështu që një emër relativ skedari zgjidhet diku që nuk e prisje.

Një direktivë cd e qartë e bën atë dallim më të mprehtë, sepse shtegu relativ lëviz bashkë me ndryshimin e drejtorisë. Nëse e ke trashëguar këtë konfigurim, skedari mund të ndodhet diku ku tani askush nuk do të kërkonte.

Krahaso kohën e modifikimit të skedarit me momentin kur e nise. Një regjistër i javës së kaluar është provë për javën e kaluar. Më pas lexo rreshtat e fundit të skedarit që ndryshoi, dhe trajto çfarëdo që është atje si mesazhi i nisjes që të ka munguar.

log kundrejt log-append: provë dhe fshirje

log-append i shton asaj që është tashmë në skedar. log e hap skedarin për shkrim dhe e shkurtron, kështu që kalimi mes tyre mund të fshijë ekzekutimin që po bëheshe gati të lexoje.

Nëse dikush e ndryshoi direktivën gjatë korrigjimit, prova e mëparshme tashmë ka ikur dhe madhësia e skedarit do të duket dyshimtërisht e vogël. Ia vlen ta dish këtë përpara se të krahasosh dy ekzekutime dhe të përfundosh se diçka ndryshoi. Fshi një regjistër me qellim ose mbaje, por di cilin nga të dy bëre. Prova që e hoqe me dashje është më e lehtë për t'u arsyetuar sesa prova që humbe aksidentalisht.

Asnjëri opsion nuk krijon drejtori prindërore që mungojnë, dhe asnjëri nuk jep akses përmes lejeve të sistemit të skedarëve ose një sandbox shërbimi. Një shteg që duket i saktë në konfigurim mund të jetë prapë i pashkrueshëm nga llogaria nën të cilën punon daemoni, dhe atëherë daemoni mund të dështojë përpara se të raportojë gjë. Kontrollo nëse drejtoria ekziston dhe kush është pronari i saj përpara se të supozosh se emri i skedarit është problemi.

Kur një mbështjellës shërbimi e kap daljen

Nën systemd, dalja standarde dhe gabimet shkojnë në journal nëse një direktivë e qartë skedari nuk ka përparësi, dhe një mbështjellës i furnizuesit mund t'i kapë ato diku krejt tjetër.

Kjo është arsyeja pse i njëjti profil sillet ndryshe nga një shell dhe nga një unit. Mjedisi i unit, drejtoria e tij e punës dhe rrjedhat standarde të gjitha ndryshojnë nga shell-i yt interaktiv. Një shteg relativ mund të zgjidhet në një kontekst dhe nuk arrin askund në tjetrin. Lexo përkufizimin e unit kur të dy nuk pajtohen, jo profilin.

Krahaso dy mënyrat e nisjes në vend që të përfundosh se njëri prej tyre është i prishur. Lexo rreshtin e komandës së unit dhe mjedisin e tij, pastaj lexo journal për të njëjtën dritare kohe. Nëse mbështjellësi e ridrejton daljen në skedarin e vet, ai skedar tani është regjistri yt, dhe direktivat e OpenVPN janë të parëndësishme për atë se ku shkuan mesazhet.

Rrit shkallën e hollësisë vetëm pasi të mund ta lexosh

Rritja e hollësisë përpara se të gjendet destinacioni prodhon vetëm më shumë tekst në një vend që nuk po e shikon.

Pasi ta dish se ku zbret dalja, një nivel i moderuar tregon profilin duke u analizuar dhe lidhjen duke u provuar. Dy ose tre mjaftojnë për një problem nisjeje. Nivelet më të larta e fitojnë vendin e tyre kur dështimi është një detaj negocimi, dhe gjithashtu e rritin shpejt skedarin.

Më pas lexo gabimin e vërtetë. Një terminal i heshtur nuk provon asgjë për atë nëse tuneli u ngrit, dhe dështimi i regjistruar në skedar është ai që ia vlen të rregullohet.