OpenVPN starter ikke uden fejl? Se i journalen

Kommandoen vender tilbage, tjenesten vises som fejlet, og intet, der ligner en forklaring, når terminalen. Den stilhed er det symptom, folk beskriver som »OpenVPN starter ikke«, og det betyder næsten aldrig, at programmet døde uden at sige noget. Det betyder, at beskeden gik til en kanal, du ikke læste, eller at det, du startede, ikke var det, du konfigurerede. Begge tilfælde kan diagnosticeres på under et minut, når du holder op med at betragte profilen som den mistænkte.

Fire steder opsuger outputtet: unit’ens journal, pluginnet, der ejer forbindelsen, den anden ende af tunnelen og en anden binær end den, du tror kører. Hver har sit eget tjek.

Stilhed betyder, at du ikke så den rigtige kanal

Et kald i forgrunden udskriver til din terminal. En unit udskriver til journalen, og en fejlet unit kan afslutte, før den skriver noget som helst, hvis fejlen ligger i hvordan den blev startet snarere end i det, den fik at vide. Forskellen er vigtig: ingen journalpost betyder, at processen aldrig rigtig kørte, mens én post efterfulgt af en afslutning betyder, at den kørte og afviste noget.

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

Tilføj systemctl show -p Result -p ExecMainStatus openvpn-client@office for at skelne en ren afslutning fra et signal. En status på 1 med en Result=exit-code er en programbeslutning; Result=signal eller en timeout peger i stedet på miljøet, og ingen mængde profilredigering ændrer det. Notér begge værdier, før du genstarter noget, fordi en genstart sletter den forbigående tilstand, der frembragte dem.

Instansnavnet er en del af stien

Den pakkede skabelon-unit tager ikke en filsti. Den tager et instansnavn, og det navn føjes til en mappe for at finde profilen: office opløses til /etc/openvpn/client/office.conf i Debian- og Ubuntu-pakningen. En fil med navnet office-v2.conf startet som @office læses aldrig, og unit’en afslutter stille, fordi der fra dens synspunkt ikke var noget at gøre. Opslagsmappen er forskellig i klient- og servertilstand, så den samme fejl peger helt andre steder hen, når du skifter skabelon.

Den uoverensstemmelse er den mest almindelige kilde til den stille fejl, og den er usynlig i profilen, fordi profilen er i orden. List op, hvad der faktisk findes, og sammenlign de to navne tegn for tegn, inklusive enhver udvidelse, som pakningen forventer.

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

Hvis unit’en er aktiveret, men ingen instans er opført, kan aktiveringen selv henvise til et navn, der senere blev omdøbt. At genaktivere den korrekte instans er normalt nok, og den gamle unit-fil, der ligger tilbage, er værd at slette, så den ikke forvirrer den næste person. En efterladt unit-fil er en lille ting, der koster nogen en time senere.

Når pluginnet ejer tunnelen, ser terminalen intet

En forbindelse, der startes fra skrivebords-applet’en, ejes af NetworkManager, og dens OpenVPN-output går i den tjenestes journal i stedet for i en shell, du har åben. At køre klienten manuelt og ikke se noget er forventeligt i den ordning, fordi den manuelt kørte proces ikke er den, der bærer forbindelsen.

Søg i journalen efter den tjeneste, der ejer den, og genskab derefter parsingen med en detaljeringsgrad, du kan læse. De to kommandoer nedenfor ser på forskellige ejere af den samme fejl.

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

Den selvstændige kørsel er til at læse beskeder, ikke til at erstatte den administrerede forbindelse, og de to er forskellige bagefter: DNS-integration, ruter og levetid tilhører pluginnet. At rette en parse-fejl i den selvstændige kørsel retter ikke automatisk navneopløsningen, når applet’en overtager, så hold de to observationer adskilt.

To binære filer, én PATH

Et manuelt byg installeret under /usr/local vinder ved et shell-kald, fordi /usr/local/sbin kommer før /usr/sbin på den standard Ubuntu-PATH. En unit bruger ikke din PATH; den kører den absolutte sti, der er skrevet i ExecStart. Så den version, der virker i din terminal, og den version, der fejler som tjeneste, kan være virkelig forskellige programmer.

Sammenlign de to, før du genopbygger noget. Den tredje kommando er den, der afgør argumentet.

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

Endnu en miljøforskel gemmer sig samme sted. En pakket unit er afhængig af en runtime-mappe under /run som systemd opretter til den; en håndskrevet erstatnings-unit, der udelader den indstilling, kan fejle, før den åbner en enkelt fil, og fejlen ligner en generisk afvisning uden nogen OpenVPN-besked.

Fejl, som klienten ikke kan rapportere

Nogle udfald afgøres i den fjerne ende. En gateway, der svarer med en HTTP-status og lukker forbindelsen, har fortalt dig om sin egen tilstand, og det nyttige næste skridt er dens log eller kontoen bag legitimationsoplysningerne frem for dine lokale filer. Intet lokalt er i stykker i det scenarie, og at redigere profilen for at kompensere gør den næste diagnose sværere. Læs den log, før du rører klientkonfigurationen.

Et andet stille tilfælde er en klient, der fungerer korrekt. En tunnel i klienttilstand lytter aldrig på en port, så et tjek, der forventer en åben lytter, rapporterer intet og ser ud som en fejl. Bekræft, hvilken tilstand du startede, før du drager en konklusion ud fra en tom portliste.

Arbejd lagene i rækkefølge: findes unit’en, og er instansnavnet rigtigt, nåede noget journalen eller filen --log, hvilken binær og profil kørte faktisk, og er fejlen lokal eller fjern. Hvert svar fjerner et lag. At begynde med profilen betyder at genskrive en fil, der måske aldrig er blevet åbnet.