OpenVPN starter ikke: les den første linjen, ikke konfigurasjonen

En VPN som dør i det første sekundet er et annet dyr enn en som kobler til og deretter feiler, og den vanlige feilen er å behandle dem som det samme. Her er det ingen handshake, ingen sertifikatutveksling og ingen rute å undersøke. Én linje i journalen avgjør hvilken av flere urelaterte reparasjoner som gjelder, og å hoppe over den koster en ettermiddag med å redigere en konfigurasjon som aldri ble lest. Les den linjen først.

Tre skrivebeskyttede kommandoer får deg dit: først journalctl -u openvpn@server -b --no-pager, deretter systemctl status openvpn@server, og ss -lunp for UDP-lytterne og eierne deres.

Den første linjen velger grenen

En portkonflikt og en manglende binær dreper begge oppstarten innen et sekund, og de etterlater ulike første linjer. En melding om at adressen allerede er i bruk navngir porten; en manglende kjørbar fil navngir en sti som ikke lenger finnes; en mislykket betingelse eller en manglende konfigurasjonsfil navngir filen. De tre fører til ulike reparasjoner, og ingen av dem blir bedre av å installere klienten på nytt. Kopier den første feilen til notatene dine før du kjører noe annet.

Se opp for gjentakelsesløkken som skjuler den opprinnelige linjen. En enhet med en omstartspolicy kan begrave den første feilen under et dusin identiske, så journalctl -b filtrert på enheten og lest fra toppen slår halen.

Hvem ellers holder port 1194

Synderen er vanligvis ikke en annen server noen har konfigurert med vilje. Forvent en håndstartet klient som fortsatt lever i en annen terminal, en annen profil som tilfeldigvis valgte samme port, eller en leverandørpakke der den egne tunnelen holder 1194. Eieren av socketen vises i ss -lunp; gi den PID-en til systemctl status for å finne ut om en enhet er ansvarlig. Ta den ned gjennom dens egen kontrollvei i stedet for med et signal.

Et signal til en prosess som styres av en enhet utløser vanligvis en omstart, og den samme feilen dukker opp igjen øyeblikk senere som et nytt problem. Bruk systemctl stop for en enhet, pakkens egen tjenestekommando for en leverandørinstallasjon, og et signal bare for noe du selv startet i den shellen.

Gjenværende enheter etter en avinstallering

En avinstallering sletter binære filer; enhetsfiler skrevet for hånd, typisk under /etc/systemd/system, overlever den. Systemd prøver da på nytt en enhet som peker på en sti som ikke lenger finnes, og meldingen gjelder den manglende filen snarere enn gårsdagens fjerning. systemctl status viser enhetens fragmentsti nær toppen, så kontroller den med dpkg -S før du sletter noe. Når foreldreløsen er borte, rydder systemctl daemon-reload og systemctl reset-failed tilstanden; ellers arver hver senere statuskontroll den.

Når which openvpn svarer med noe under /usr/local, kom binæren i bruk fra en leverandørinstallatør og ikke fra apt. En slik installatør tar vanligvis med sin egen lytter, sin egen oppstartsføring og sin egen konfigurasjonskatalog, så å fjerne den synlige kommandoen lar socketen være opptatt.

Avinstaller den slik leverandøren dokumenterer, bekreft at porten er fri med ss -lunp, og legg til distribusjonens klient bare hvis du trenger den.

Få tilstanden i orden før du prøver igjen

Rydd den mislykkede tilstanden før du trekker konklusjoner fra den: systemctl reset-failed fjerner tellerne, og systemctl status rapporterer deretter enhetens nåværende tilstand i stedet for historikken. Start den én gang og les journalen for nettopp den kjøringen i stedet for maskinens samlede tilstand. En enhet som rapporterer at den er aktiv mens tunnelen ikke frakter noe, er et separat problem, og et langt vanligere. De to smelter sammen i feilrapporter fordi begge ender med at brukeren sier at VPN ikke virker.

Noter grenen du tok: portkonflikt, manglende binær, manglende konfigurasjon. Neste gang går det raskere å kjenne den igjen.