OpenVPN starter ikke uten feil? Se i journalen

Kommandoen kommer tilbake, tjenesten vises som mislykket, og ingenting som ligner en forklaring når terminalen. Den stillheten er symptomet folk beskriver som «OpenVPN starter ikke», og det betyr nesten aldri at programmet døde uten å si noe. Det betyr at meldingen gikk til en kanal du ikke leste, eller at det du startet ikke var det du konfigurerte. Begge tilfellene kan diagnostiseres på under ett minutt når du slutter å behandle profilen som den mistenkte.

Fire steder absorberer utdataene: journalen til uniten, programtillegget som eier tilkoblingen, den andre enden av tunnelen og en annen binærfil enn den du tror kjører. Hver har sin egen sjekk.

Stillhet betyr at du ikke så på riktig kanal

En kjøring i forgrunnen skriver til terminalen din. En unit skriver til journalen, og en mislykket unit kan avslutte før den skriver noe i det hele tatt hvis feilen ligger i hvordan den ble startet og ikke i det den fikk beskjed om. Forskjellen er viktig: ingen journaloppføring betyr at prosessen aldri egentlig kjørte, mens én oppføring etterfulgt av en avslutning betyr at den kjørte og avviste noe.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Legg til systemctl show -p Result -p ExecMainStatus openvpn-client@office for å skille en ren avslutning fra et signal. En status på 1 med en Result=exit-code er en programavgjørelse; Result=signal eller en timeout peker i stedet på miljøet, og ingen mengde profilredigering endrer det. Noter begge verdiene før du starter noe på nytt, fordi en omstart sletter den forbigående tilstanden som produserte dem.

Instansnavnet er en del av banen

Den pakkede malenheten tar ikke en filbane. Den tar et instansnavn, og det navnet legges til en katalog for å finne profilen: office løses til /etc/openvpn/client/office.conf i Debian- og Ubuntu-pakken. En fil som heter office-v2.conf, startet som @office leses aldri, og uniten avslutter stille fordi det fra dens synspunkt ikke var noe å gjøre. Oppslagsmappen er forskjellig i klient- og servermodus, så den samme feilen peker helt andre steder når du bytter mal.

Det avviket er den vanligste kilden til den stille feilen, og det er usynlig i profilen fordi profilen er i orden. List opp hva som faktisk finnes, og sammenlign de to navnene tegn for tegn, inkludert enhver utvidelse pakken forventer.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Hvis uniten er aktivert men ingen instans er oppført, kan aktiveringen selv referere til et navn som senere ble omdøpt. Å aktivere riktig instans på nytt er vanligvis nok, og den gamle unit-filen som blir liggende er verdt å slette så den ikke forvirrer neste person. En gjenglemt unit-fil er en liten ting som koster noen en time senere.

Når programtillegget eier tunnelen, ser terminalen ingenting

En tilkobling startet fra skrivebordsappletten eies av NetworkManager, og OpenVPN-utdataene går til journalen til den tjenesten i stedet for til et shell du har åpent. Å kjøre klienten for hånd og ikke se noe er forventet i den ordningen, fordi prosessen som kjøres for hånd ikke er den som bærer tilkoblingen.

Søk i journalen etter tjenesten som eier den, og gjenskap deretter parsingen med en detaljrikdom du kan lese. De to kommandoene nedenfor ser på forskjellige eiere av samme feil.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Den frittstående kjøringen er for å lese meldinger, ikke for å erstatte den administrerte tilkoblingen, og de to er forskjellige etterpå: DNS-integrasjon, ruter og levetid tilhører programtillegget. Å rette en parsefeil i den frittstående kjøringen retter ikke automatisk navneoppslag når appletten overtar, så hold de to observasjonene atskilt.

To binærfiler, én PATH

En manuelt bygget installasjon under /usr/local vinner ved en shell-kjøring, fordi /usr/local/sbin kommer før /usr/sbin på standard Ubuntu-PATH. En unit bruker ikke PATH-en din; den kjører den absolutte banen som er skrevet i ExecStart. Så versjonen som virker i terminalen din og versjonen som feiler som tjeneste kan være virkelig forskjellige programmer.

Sammenlign de to før du bygger noe på nytt. Den tredje kommandoen er den som avgjør argumentet.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

En annen miljøforskjell gjemmer seg på samme sted. En pakket unit er avhengig av en kjøretidsmappe under /run som systemd oppretter for den; en håndskrevet erstatningsunit som utelater den innstillingen kan feile før den åpner en eneste fil, og feilen ser ut som en generell avvisning uten noen OpenVPN-melding.

Feil klienten ikke kan rapportere

Noen utfall avgjøres i den fjerne enden. En gateway som svarer med en HTTP-status og lukker tilkoblingen har fortalt deg om sin egen tilstand, og det nyttige neste steget er loggen dens eller kontoen bak legitimasjonen i stedet for dine lokale filer. Ingenting lokalt er ødelagt i det scenariet, og å redigere profilen for å kompensere gjør neste diagnose vanskeligere. Les den loggen før du rører klientkonfigurasjonen.

Et annet stille tilfelle er en klient som fungerer riktig. En tunnel i klientmodus lytter aldri på en port, så en sjekk som forventer en åpen lytter vil ikke rapportere noe og se ut som en feil. Bekreft hvilken modus du startet før du trekker en konklusjon fra en tom portliste.

Arbeid lagene i rekkefølge: finnes uniten og er instansnavnet riktig, nådde noe journalen eller filen --log, hvilken binærfil og profil kjørte faktisk, og er feilen lokal eller ekstern. Hvert svar fjerner et lag. Å begynne med profilen betyr å skrive om en fil som kanskje aldri ble åpnet.