OpenVPN siger active (exited)? Find den instans, du startede

Du tjekker tunnelen, kører systemctl status openvpn og får active (exited) uden Main PID og med en tom procesliste. Den naturlige læsning er, at tjenesten startede og døde, så du åbner unit-filen, finder /bin/true og konkluderer, at pakken er i stykker. I Debian-pakken er den tilstand wrapperen, der arbejder som designet, og tunnelen bor i et af de instans-units, den starter. Det samlede unit vil aldrig fortælle dig, hvilken instans der byggede det.

Hvad active (exited) egentlig betyder på dette unit

Det pakkede unit er en engangsopgave: dets ExecStart er /bin/true, og RemainAfterExit=yes er det, der holder et afsluttet unit rapporteret som active (exited). Fjern den direktiv, og den samme vellykkede /bin/true-opgave ender i inactive (dead), som netop er den tilstand, folk forventer og læser forkert i den anden retning. Kommandoen er en pladsholder, og unitet rapporterer om arbejde, som andre units udfører. Intet i den ordning er i stykker, og at erstatte /bin/true ændrer pakkekontrakten snarere end tunnelen.

Wrapperen delegerer. Den starter de instans-units, som pakkekonfigurationen eller dens systemd-generator leverer, og derfor beviser en tom procesliste intet om tunnelen. Når ingen instans er valgt, lykkes wrapperen stadig og starter stadig intet. Tilstanden svarer på, om wrapperen kørte, ikke om der findes en tunnel.

Læs de tre linjer i status-outputtet frem for ordet i parentes. Loaded angiver den unit-fil, systemd læste, Active bærer tidsstemplet for den sidste vellykkede kørsel, og den manglende Main PID passer til en afsluttet engangsopgave. De tre linjer er også måden at skelne denne wrapper fra en tjeneste, der styrtede et sekund efter start.

List units, før du læser status igen

Spørg systemd, hvad der findes, før du spørger, hvad der kører. En skabelon kan være installeret, mens ingen instans er oprettet, og kun et oprettet unit bærer en tunnel. Start med det indlæste sæt:

systemctl list-units 'openvpn*'

Den liste er, hvad systemd har indlæst i dette øjeblik, og det er det nærmeste, man kommer en tunnelbeholdning. Installerede unit-filer svarer på et andet spørgsmål, og den liste viser stadig en skabelon, når intet er oprettet:

systemctl list-unit-files 'openvpn*'

Læs de to lister sammen, fordi en skabelon i den anden og en instans i den første er forskellige svar. En skabelon, der findes, og en instans, der kører, er ikke det samme faktum, og kun det andet betyder en tunnel. Pakkeopbygninger varierer også mellem distributioner og OpenVPN-versioner. En ældre openvpn@-skabelon, et opdelt client- og serverpar og en distributionswrapper kan alle være legitime i deres egen pakke.

Tilpas til din maskine frem for den vejledning, du fandt. Instansnavnet i en andens output kan være office, mens dit er home eller work. Det, der overføres, er metoden, ikke strengen.

Følg instansnavnet til den fil, den læser

I upstream-client-skabelonen er unitets arbejdsmappe /etc/openvpn/client, og dets kommando tager %i.conf derfra, så openvpn-client@office læser /etc/openvpn/client/office.conf. Bekræft den mapping på det installerede unit i stedet for at stole på eksemplet, fordi den skabelon, du har, kan være ældre eller en omskrivning fra distributionen:

systemctl cat [email protected]

Læs de drop-in-filer, der vises nederst i det output, fordi en fil under .d/ kan ændre ExecStart, arbejdsmappen eller konfigurationsstien. En profil, du downloadede som office.ovpn, er ikke den fil, instansen åbner. Det gab er den sædvanlige grund til, at en fejl nævner en sti, du aldrig har redigeret.

Relative stier inde i profilen er den næste fælde. At flytte hovedfilen, mens ca-, cert- og key-referencer forbliver relative, bytter en manglende-fil-fejl ud med en anden manglende-fil-fejl. Den anden peger på en fil, du var sikker på eksisterede, og derfor betyder profilmappen mere end filnavnet.

Start den, og læs derefter den instans' journal

Start den instans, du netop har undersøgt, fordi det samlede units log ikke vil indeholde tunnelens fejl. Læs derefter journalen for denne opstart og led i den rækkefølge efter en konfigurationsfejl, en filadgangsfejl og en forbindelsesfejl, fordi hver af dem fejler på et forskelligt tidspunkt af opstarten.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Start og aktivering er separate beslutninger: start kører unitet nu, enable arrangerer næste opstart, og enable --now gør begge i ét trin. daemon-reload genlæser unit-definitioner og genstarter ikke en kørende proces og anvender ikke en redigeret profil. Efter du har ændret profilen, genstart instansen, fordi det er det, der genlæser filen.

Sæt ikke en anden manager på den samme tunnel

NetworkManager og OpenVPN 3-sessionsmanagerne ejer deres egen forbindelsestilstand, og en systemd-instans ved siden af en af dem sætter to ejere på den samme tunnel. Symptomet er en tunnel, der kommer op og bliver erstattet få sekunder efter, eller en, der nægter at forblive stoppet. Vælg den manager, din distribution dokumenterer til skrivebordet, og brug systemd bevidst på en server.

Tjek for en eksisterende ejer, før du starter en instans. Når et skrivebordsapplet viser forbindelsen, konkurrerer den instans, du starter, med det i stedet for at fuldende det. Deaktiver den manager, du ikke bruger, i stedet for at køre begge og håbe på, at rækkefølgen holder. Den konflikt forklarer også journaler, hvor en tunnel etableres og derefter rives ned af en proces, du aldrig startede.

Svar på det oprindelige spørgsmål med instansnavnet, den fil, den læste, og den journal-linje, der fejlede. OpenVPNs noter om systemd-integration beskriver skabelonopbygningen og den filmapping, som instansnavnet opløses igennem.