OpenVPN nuk niset: lexo rreshtin e parë, jo konfigurimin

Një VPN që vdes në sekondën e parë është një kafshë tjetër nga ajo që lidhet dhe pastaj dështon, dhe gabimi i zakonshëm është t'i trajtosh njësoj. Këtu nuk ka shtrëngim duarsh, as shkëmbim certifikatash e as rrugë për të shqyrtuar. Një rresht në regjistër vendos cila nga disa riparime të palidhura zbatohet, dhe kalimi i tij kushton një pasdite duke redaktuar një konfigurim që nuk u lexua kurrë. Lexoje atë rresht së pari.

Tre komanda vetëm për lexim të çojnë atje: journalctl -u openvpn@server -b --no-pager së pari, systemctl status openvpn@server së dyti dhe ss -lunp për dëgjuesit UDP dhe pronarët e tyre.

Rreshti i parë zgjedh degën

Një konflikt porti dhe një binar që mungon e vrasin nisjen brenda një sekonde, dhe lënë rreshta të parë të ndryshëm. Një mesazh për adresë tashmë në përdorim emërton portin; një ekzekutues që mungon emërton një shteg që nuk ekziston më; një kusht i dështuar ose një skedar konfigurimi që mungon emërton skedarin. Këto tre çojnë në riparime të ndryshme dhe asnjëra prej tyre nuk përmirësohet duke reinstaluar klientin. Kopjoje dështimin e parë në shënimet e tua përpara se të ekzekutosh çdo gjë tjetër.

Ki kujdes për ciklin e përsëritjes që fsheh rreshtin origjinal. Një njësi me politikë rinisjeje mund ta varrosë dështimin e parë nën një duzinë të njëjtë, prandaj journalctl -b i filtruar sipas njësisë dhe i lexuar nga fillimi është më i mirë se fundi.

Kush tjetër e mban portin 1194

Fajtori zakonisht nuk është një server i dytë që dikush e konfiguroi me qëllim. Prit një klient të nisur me dorë që është ende gjallë në një terminal tjetër, një profil të dytë që rastësisht zgjodhi të njëjtin port, ose një paketë shitësi tunneli i së cilës mban 1194. Pronari i socket-it shfaqet në ss -lunp; jepjani atë PID systemctl status për të mësuar nëse një njësi është përgjegjëse. Hiqe përmes rrugës së vetë kontrollit të saj, jo me një sinjal.

Një sinjal për një proces të menaxhuar nga njësia zakonisht shkakton një rinisje, dhe i njëjti dështim rishfaqet pas disa çastesh si një problem i ri. Përdor systemctl stop për një njësi, komandën e shërbimit të vetë paketës për një instalim shitësi dhe një sinjal vetëm për diçka që e nise me dorë në atë shell.

Njësi të mbetura pas një pastrimi

Një pastrim fshin binarët; skedarët e njësive të shkruar me dorë, zakonisht nën /etc/systemd/system, i mbijetojnë atij. Systemd pastaj riprovon një njësi që tregon një shteg që nuk ekziston më, dhe mesazhi ka të bëjë me atë skedar që mungon, jo me heqjen e djeshme. systemctl status shfaq shtegun fragment të njësisë pranë kryes, prandaj kontrolloje me dpkg -S përpara se të fshish çdo gjë. Pasi jetima të jetë larguar, systemctl daemon-reload dhe systemctl reset-failed pastrojnë gjendjen; përndryshe çdo kontroll i mëvonshëm i statusit e trashëgon atë.

Kur which openvpn përgjigjet me diçka nën /usr/local, binari në lojë erdhi nga një instalues shitësi dhe jo nga apt. Një instalues i tillë zakonisht sjell dëgjuesin e vet, hyrjen e vet të nisjes dhe drejtorinë e vet të konfigurimit, prandaj heqja e komandës së dukshme e lë socket-in të zënë.

Çinstaloje me çfarëdo që dokumenton shitësi, konfirmo që porti është i lirë me ss -lunp dhe shto klientin e shpërndarjes vetëm nëse të duhet.

Qetëso gjendjen përpara se të riprovosh

Pastro gjendjen e dështuar përpara se të nxjerrësh përfundime prej saj: systemctl reset-failed heq numëruesit dhe systemctl status pastaj raporton gjendjen aktuale të njësisë, jo historinë e saj. Nise një herë dhe lexo regjistrin e vetë asaj instance, jo gjendjen e përgjithshme të kutisë. Një njësi që raporton aktive ndërsa tuneli nuk mbart asgjë është një problem i veçantë, dhe një shumë më i zakonshëm. Të dyja bashkohen në raportet e defekteve sepse të dyja përfundojnë me përdoruesin që thotë se VPN-ja nuk punon.

Shëno degën që more: konflikt porti, binar që mungon, konfigurim që mungon. Dukuri tjetër do të njihet më shpejt.