OpenVPN nepasileidžia: skaitykite pirmą eilutę, o ne konfigūraciją

VPN, kuris miršta pirmą sekundę, yra kitas gyvūnas nei tas, kuris prisijungia ir tada sugenda, ir įprasta klaida – elgtis su jais kaip su tuo pačiu. Čia nėra jokio handshake, jokio sertifikatų keitimosi ir jokio maršruto, kurį būtų galima apžiūrėti. Viena žurnalo eilutė nusprendžia, kuri iš kelių nesusijusių taisymų galioja, o jos praleidimas kainuoja pusdienį, redaguojant konfigūraciją, kuri niekada nebuvo perskaityta. Pirmiausia perskaitykite tą eilutę.

Trys tik skaitymo komandos nuves jus ten: pirmiausia journalctl -u openvpn@server -b --no-pager, po to systemctl status openvpn@server, ir ss -lunp UDP klausytojams bei jų savininkams.

Pirmoji eilutė parenka šaką

Porto konfliktas ir trūkstamas dvejetainis failas abu nužudo paleidimą per sekundę ir palieka skirtingas pirmąsias eilutes. Pranešimas, kad adresas jau naudojamas, įvardija portą; trūkstamas vykdomasis failas įvardija kelią, kurio nebėra; nepavykusi sąlyga arba trūkstamas konfigūracijos failas įvardija failą. Šie trys veda prie skirtingų taisymų, ir nė vieno iš jų nepagerina kliento perdiegimas. Nukopijuokite pirmąją klaidą į savo užrašus prieš paleisdami ką nors kita.

Atkreipkite dėmesį į kartojimo kilpą, kuri paslepia pradinę eilutę. Įrenginys su pakartotinio paleidimo politika gali palaidoti pirmąją klaidą po keliolika identiškų, todėl journalctl -b, filtruojamas pagal įrenginį ir skaitomas iš viršaus, nugali uodegą.

Kas dar laiko 1194 portą

Kaltininkas paprastai būna ne antras serveris, kurį kas nors sąmoningai sukonfigūravo. Tikėkitės rankiniu būdu paleisto kliento, vis dar gyvo kitame terminale, antro profilio, kuris atsitiktinai pasirinko tą patį portą, arba tiekėjo paketo, kurio nuosavas tunelis laiko 1194. Lizdo savininkas rodomas ss -lunp; perduokite tą PID į systemctl status, kad sužinotumėte, ar atsakingas įrenginys. Išjunkite jį per jo paties valdymo kelią, o ne signalu.

Signalas įrenginio valdomam procesui paprastai sukelia pakartotinį paleidimą, ir ta pati klaida po akimirkos vėl pasirodo kaip nauja problema. Naudokite systemctl stop įrenginiui, paties paketo paslaugos komandą tiekėjo diegimui, o signalą – tik tam, ką patys paleidote toje shell aplinkoje.

Likusieji įrenginiai po pašalinimo

Pašalinimas ištrina dvejetainius failus; rankiniu būdu rašyti įrenginio failai, paprastai esantys /etc/systemd/system, tai išgyvena. Tada Systemd vėl bando įrenginį, nurodantį kelią, kurio nebėra, ir pranešimas susijęs su tuo trūkstamu failu, o ne su vakariniu pašalinimu. systemctl status rodo įrenginio fragmento kelią viršuje, todėl patikrinkite jį su dpkg -S prieš ką nors trindami. Kai našlaitis dingsta, systemctl daemon-reload ir systemctl reset-failed išvalo būseną; priešingu atveju kiekvienas vėlesnis būsenos tikrinimas ją paveldi.

Kai which openvpn atsako kuo nors, esančiu po /usr/local, naudojamas dvejetainis failas atėjo iš tiekėjo diegėjo, o ne iš apt. Toks diegėjas paprastai atsineša savo klausytoją, savo paleidimo įrašą ir savo konfigūracijos katalogą, todėl pašalinus matomą komandą lizdas lieka užimtas.

Pašalinkite jį taip, kaip dokumentuoja tiekėjas, patvirtinkite, kad portas laisvas, su ss -lunp, ir pridėkite distribucijos klientą tik jei jo reikia.

Sutvarkykite būseną prieš bandydami dar kartą

Išvalykite nepavykusią būseną prieš darydami išvadas: systemctl reset-failed pašalina skaitiklius, o systemctl status tada praneša dabartinę įrenginio būseną, o ne jo istoriją. Paleiskite jį vieną kartą ir skaitykite to paleidimo žurnalą, o ne bendrą mašinos būseną. Įrenginys, kuris praneša esąs aktyvus, nors tunelis nieko neperduoda, yra atskira problema ir daug dažnesnė. Abi susilieja klaidų ataskaitose, nes abi baigiasi tuo, kad vartotojas sako, jog VPN neveikia.

Užsirašykite, kurią šaką pasirinkote: porto konfliktas, trūkstamas dvejetainis failas, trūkstama konfigūracija. Kitą kartą atpažinti bus greičiau.