OpenVPN sier active (exited)? Finn instansen du startet

Du sjekker tunnelen, kjører systemctl status openvpn og får active (exited) uten Main PID og med en tom prosessliste. Den naturlige lesningen er at tjenesten startet og døde, så du åpner unit-filen, finner /bin/true og konkluderer med at pakken er ødelagt. I Debian-pakken er den tilstanden wrapperen som jobber som designet, og tunnelen bor i en av instans-unitene den starter. Den samlede unit-en vil aldri fortelle deg hvilken instans som bygde den.

Hva active (exited) egentlig betyr på denne unit-en

Den pakkede unit-en er en engangsoppgave: ExecStart er /bin/true, og RemainAfterExit=yes er det som holder en fullført unit rapportert som active (exited). Fjern den direktivet, og den samme vellykkede /bin/true-oppgaven ender i inactive (dead), som nettopp er tilstanden folk forventer og leser feil i motsatt retning. Kommandoen er en plassholder, og unit-en rapporterer om arbeid som andre unit-er utfører. Ingenting i denne ordningen er ødelagt, og å erstatte /bin/true endrer pakkekontrakten, ikke tunnelen.

Wrapperen delegerer. Den starter instans-unitene som pakkekonfigurasjonen eller systemd-generatoren leverer, og derfor beviser en tom prosessliste ingenting om tunnelen. Når ingen instans er valgt, lykkes wrapperen fortsatt og starter fortsatt ingenting. Tilstanden svarer på om wrapperen kjørte, ikke om det finnes en tunnel.

Les de tre linjene i status-utskriften i stedet for ordet i parentesen. Loaded navngir unit-filen systemd leste, Active bærer tidsstempelet for siste vellykkede kjøring, og den manglende Main PID passer til en fullført engangsoppgave. De tre linjene er også måten å skille denne wrapperen fra en tjeneste som krasjet et sekund etter start.

List unit-ene før du leser status igjen

Spør systemd hva som finnes før du spør hva som kjører. En mal kan være installert mens ingen instans er opprettet, og bare en opprettet unit bærer en tunnel. Start med det innlastede settet:

systemctl list-units 'openvpn*'

Den listen er det systemd har lastet inn i dette øyeblikket, og det er det nærmeste man kommer en tunneloversikt. Installerte unit-filer svarer på et annet spørsmål, og den listen viser fortsatt en mal når ingenting er opprettet:

systemctl list-unit-files 'openvpn*'

Les de to listene sammen, fordi en mal i den andre og en instans i den første er forskjellige svar. En mal som finnes og en instans som kjører er ikke det samme faktum, og bare det andre betyr en tunnel. Pakkeoppsett varierer også mellom distribusjoner og OpenVPN-versjoner. En eldre openvpn@-mal, et delt client- og serverpar og en distribusjonswrapper kan alle være legitime i sin egen pakking.

Tilpass deg din maskin i stedet for veiledningen du fant. Instansnavnet i andres utskrift kan være office mens ditt er home eller work. Det som overføres er metoden, ikke strengen.

Følg instansnavnet til filen den leser

I upstream client-malen er unit-ens arbeidskatalog /etc/openvpn/client, og kommandoen tar %i.conf derfra, så openvpn-client@office leser /etc/openvpn/client/office.conf. Bekreft den koblingen på den installerte unit-en i stedet for å stole på eksempelet, fordi malen du har kan være eldre eller en omskriving fra distribusjonen:

systemctl cat [email protected]

Les drop-in-filene nederst i den utskriften, fordi en fil under .d/ kan endre ExecStart, arbeidskatalogen eller konfigurasjonsstien. En profil du lastet ned som office.ovpn er ikke filen instansen åpner. Det gapet er den vanlige grunnen til at en feil nevner en sti du aldri har redigert.

Relative stier inne i profilen er den neste fellen. Å flytte hovedfilen mens ca-, cert- og key-referansene forblir relative bytter en manglende-fil-feil mot en annen manglende-fil-feil. Den andre peker på en fil du var sikker på fantes, og derfor betyr profilmappen mer enn filnavnet.

Start den, og les deretter journalen for den instansen

Start instansen du nettopp undersøkte, fordi loggen til den samlede unit-en ikke vil inneholde tunnelens feil. Les deretter journalen for denne oppstarten og se i den rekkefølgen etter en konfigurasjonsfeil, en filtilgangsfeil og en tilkoblingsfeil, fordi hver av dem feiler på et ulikt tidspunkt av oppstarten.

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

Start og aktivering er separate beslutninger: start kjører unit-en nå, enable ordner neste oppstart, og enable --now gjør begge i ett trinn. daemon-reload leser unit-definisjoner på nytt og starter ikke en kjørende prosess på nytt og bruker ikke en redigert profil. Når du har endret profilen, start instansen på nytt, fordi det er det som leser filen på nytt.

Ikke sett en andre behandler på samme tunnel

NetworkManager og OpenVPN 3-sesjonsbehandlerne eier sin egen tilkoblingstilstand, og en systemd-instans ved siden av en av dem setter to eiere på samme tunnel. Symptomet er en tunnel som kommer opp og blir erstattet sekunder senere, eller en som nekter å forbli stoppet. Velg behandleren distribusjonen din dokumenterer for skrivebordet, og bruk systemd bevisst på en server.

Sjekk om det allerede finnes en eier før du starter en instans. Når et skrivebordsapplet viser tilkoblingen, konkurrerer instansen du starter med det i stedet for å fullføre det. Deaktiver behandleren du ikke bruker i stedet for å kjøre begge og håpe at rekkefølgen holder. Den konflikten forklarer også journaler der en tunnel etableres og deretter rives ned av en prosess du aldri startet.

Svar på det opprinnelige spørsmålet med instansnavnet, filen den leste og journal-linjen som feilet. OpenVPNs notater om systemd-integrasjon beskriver maloppsettet og filkoblingen som instansnavnet løses gjennom.