OpenVPN startar ikkje: les den første linja, ikkje konfigurasjonen

Ein VPN som døyr i det første sekundet er eit anna dyr enn ein som koplar til og deretter feilar, og den vanlege feilen er å handsame dei som det same. Her er det ingen handshake, ingen sertifikatutveksling og ingen rute å undersøkje. Éi linje i journalen avgjer kva av fleire urelaterte reparasjonar som gjeld, og å hoppe over henne kostar ein ettermiddag med å redigere ein konfigurasjon som aldri vart lesen. Les den linja først.

Tre skriveverna kommandoar får deg dit: først journalctl -u openvpn@server -b --no-pager, deretter systemctl status openvpn@server, og ss -lunp for UDP-lyttarane og eigarane deira.

Den første linja vel greina

Ein portkonflikt og ein manglande binær drep begge oppstarten innan eit sekund, og dei etterlet ulike første linjer. Ei melding om at adressa alt er i bruk nemner porten; ei manglande køyrbar fil nemner ein stig som ikkje finst lenger; eit mislukka vilkår eller ei manglande konfigurasjonsfil nemner fila. Dei tre leier til ulike reparasjonar, og ingen av dei blir betre av å installere klienten på nytt. Kopier den første feilen til notata dine før du køyrer noko anna.

Sjå etter gjentakingsløkka som skjuler den opphavlege linja. Ei eining med ein omstartspolicy kan grave ned den første feilen under eit dusin identiske, så journalctl -b filtrert på eininga og lesen frå toppen slår halen.

Kven elles held port 1194

Syndaren er vanlegvis ikkje ein annan tenar nokon har konfigurert med vilje. Vent ein handstarta klient som framleis lever i ein annan terminal, ein annan profil som tilfeldigvis valde same port, eller ein leverandørpakke der den eigne tunnelen held 1194. Eigaren av socketen visest i ss -lunp; gje den PID-en til systemctl status for å finne ut om ei eining er ansvarleg. Ta han ned gjennom sin eigen kontrollveg i staden for med eit signal.

Eit signal til ein prosess som blir styrt av ei eining utløyser vanlegvis ein omstart, og den same feilen dukkar opp att augneblink seinare som eit nytt problem. Bruk systemctl stop for ei eining, den eigne tenestekommandoen til pakken for ein leverandørinstallasjon, og eit signal berre for noko du sjølv starta i den shellen.

Einingar som blir att etter ein avinstallering

Ein avinstallering slettar binære filer; einingfiler skrivne for hand, typisk under /etc/systemd/system, overlever henne. Systemd prøver då på nytt ei eining som peikar på ein stig som ikkje finst lenger, og meldinga gjeld den manglande fila snarare enn fjerninga i går. systemctl status viser fragmentstigen til eininga nær toppen, så kontroller han med dpkg -S før du slettar noko. Når den foreldrelause er borte, ryddar systemctl daemon-reload og systemctl reset-failed tilstanden; elles arvar kvar seinare statuskontroll han.

Når which openvpn svarar med noko under /usr/local, kom binæren i bruk frå ein leverandørinstallatør og ikkje frå apt. Ein slik installatør tek vanlegvis med sin eigen lyttar, sin eigen oppstartsføring og sin eigen konfigurasjonskatalog, så å fjerne den synlege kommandoen lèt socketen vere oppteken.

Avinstaller han slik leverandøren dokumenterer, stadfest at porten er fri med ss -lunp, og legg til klienten frå distribusjonen berre om du treng han.

Få tilstanden i orden før du prøver på nytt

Rydd den mislukka tilstanden før du dreg konklusjonar frå han: systemctl reset-failed fjernar teljarane, og systemctl status rapporterer då den noverande tilstanden til eininga i staden for historia. Start henne éin gong og les journalen for nettopp den køyringa i staden for den samla tilstanden til maskinen. Ei eining som rapporterer at ho er aktiv medan tunnelen ikkje fraktar noko, er eit separat problem, og eit langt vanlegare. Dei to smeltar saman i feilrapportar fordi begge endar med at brukaren seier at VPN ikkje verkar.

Noter greina du tok: portkonflikt, manglande binær, manglande konfigurasjon. Neste gong går det raskare å kjenne henne att.