OpenVPN starter ikke: læs den første linje, ikke konfigurationen

En VPN, der dør i det første sekund, er et andet dyr end en, der forbinder og derefter fejler, og den sædvanlige fejl er at behandle dem som det samme. Her er ingen handshake, ingen certifikatudveksling og ingen rute at undersøge. Én linje i journalen afgør, hvilken af flere ubeslægtede reparationer der gælder, og at springe den over koster en eftermiddag med at redigere en konfiguration, der aldrig blev læst. Læs den linje først.

Tre skrivebeskyttede kommandoer bringer dig derhen: journalctl -u openvpn@server -b --no-pager først, systemctl status openvpn@server derefter, og ss -lunp for UDP-lytterne og deres ejere.

Den første linje vælger grenen

En portkonflikt og en manglende binær dræber begge opstarten inden for et sekund, og de efterlader forskellige første linjer. En meddelelse om, at adressen allerede er i brug, nævner porten; en manglende eksekverbar fil nævner en sti, der ikke længere findes; en mislykket betingelse eller en manglende konfigurationsfil nævner filen. De tre fører til forskellige reparationer, og ingen af dem bliver bedre af at geninstallere klienten. Kopier den første fejl til dine noter, før du kører noget andet.

Hold øje med gentagelsesløkken, der skjuler den oprindelige linje. En unit med en genstartsstrategi kan begrave den første fejl under et dusin identiske, så journalctl -b filtreret på unit og læst fra toppen slår halen.

Hvem ellers holder port 1194

Synderen er normalt ikke en anden server, nogen bevidst har konfigureret. Forvent en håndstartet klient, der stadig lever i en anden terminal, en anden profil, der tilfældigvis valgte samme port, eller en leverandørpakke, hvis egen tunnel holder 1194. Socketens ejer vises i ss -lunp; giv det PID til systemctl status for at finde ud af, om en unit er ansvarlig. Tag den ned gennem dens egen kontrolvej i stedet for med et signal.

Et signal til en unit-styret proces udløser typisk en genstart, og den samme fejl dukker op igen øjeblikke senere som et nyt problem. Brug systemctl stop til en unit, pakkens egen servicekommando til en leverandørinstallation, og et signal kun til noget, du selv startede i den shell.

Resterende units efter en afinstallation

En afinstallation sletter binære filer; unitfiler skrevet i hånden, typisk under /etc/systemd/system, overlever den. Systemd prøver derefter igen en unit, der peger på en sti, der ikke længere findes, og meddelelsen handler om den manglende fil snarere end om gårsdagens fjernelse. systemctl status viser unitens fragmentsti nær toppen, så kontroller den med dpkg -S, før du sletter noget. Når det forældreløse er væk, rydder systemctl daemon-reload og systemctl reset-failed tilstanden; ellers arver enhver senere statuskontrol den.

Når which openvpn svarer med noget under /usr/local, kom binæren i spil fra en leverandørinstallatør og ikke fra apt. Sådan en installatør bringer typisk sin egen lytter, sin egen opstartspost og sit eget konfigurationsbibliotek, så fjernelse af den synlige kommando efterlader socketen optaget.

Afinstaller den med det, leverandøren dokumenterer, bekræft at porten er fri med ss -lunp, og tilføj distributionens klient kun, hvis du har brug for den.

Bring tilstanden i orden, før du prøver igen

Ryd den mislykkede tilstand, før du drager konklusioner ud fra den: systemctl reset-failed fjerner tællerne, og systemctl status rapporterer derefter unitens aktuelle tilstand i stedet for dens historie. Start den én gang og læs netop den kørsels journal i stedet for maskinens samlede tilstand. En unit, der rapporterer aktiv, mens tunnelen ikke bærer noget, er et separat problem og et langt mere almindeligt. De to bliver slået sammen i fejlrapporter, fordi begge ender med, at brugeren siger, at VPN ikke virker.

Noter den gren, du tog: portkonflikt, manglende binær, manglende konfiguration. Næste gang bliver den hurtigere at genkende.