OpenVPN startar inte utan fel? Titta i journalen

Kommandot återvänder, tjänsten visas som misslyckad, och ingenting som liknar en förklaring når terminalen. Den tystnaden är symtomet som folk beskriver som «OpenVPN startar inte», och det betyder nästan aldrig att programmet dog utan att säga något. Det betyder att meddelandet gick till en kanal du inte läste, eller att det du startade inte var det du konfigurerade. Båda fallen kan diagnosticeras på under en minut när du slutar behandla profilen som den misstänkte.

Fyra platser absorberar utdata: unitens journal, insticksmodulen som äger anslutningen, andra änden av tunneln och en annan binärfil än den du tror körs. Var och en har sin egen kontroll.

Tystnad betyder att du inte tittade på rätt kanal

Ett anrop i förgrunden skriver till din terminal. En unit skriver till journalen, och en misslyckad unit kan avsluta innan den skriver något alls om felet ligger i hur den startades och inte i vad den fick veta. Skillnaden är viktig: ingen journalpost betyder att processen aldrig egentligen körde, medan en post följd av ett avslut betyder att den körde och avvisade något.

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

Lägg till systemctl show -p Result -p ExecMainStatus openvpn-client@office för att skilja ett rent avslut från en signal. En status på 1 med en Result=exit-code är ett programbeslut; Result=signal eller en timeout pekar i stället på miljön, och ingen mängd profilredigering ändrar det. Anteckna båda värdena innan du startar om något, eftersom en omstart raderar det övergående tillstånd som skapade dem.

Instansnamnet är en del av sökvägen

Den paketerade mall-enheten tar inte en filsökväg. Den tar ett instansnamn, och det namnet läggs till en katalog för att hitta profilen: office löses upp till /etc/openvpn/client/office.conf i Debian- och Ubuntu-paketet. En fil som heter office-v2.conf, startad som @office läses aldrig, och enheten avslutas tyst eftersom det från dess synvinkel inte fanns något att göra. Sökkatalogen skiljer sig mellan klient- och serverläge, så samma fel pekar helt någon annanstans när du byter mall.

Den diskrepansen är den vanligaste orsaken till det tysta felet, och den är osynlig i profilen eftersom profilen är i ordning. Lista vad som faktiskt finns och jämför de två namnen tecken för tecken, inklusive varje filändelse som paketet förväntar sig.

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

Om enheten är aktiverad men ingen instans listas kan aktiveringen själv hänvisa till ett namn som senare döptes om. Att aktivera rätt instans igen räcker oftast, och den gamla enhetsfilen som blir kvar är värd att ta bort så att den inte förvirrar nästa person. En kvarglömd enhetsfil är en liten sak som kostar någon en timme senare.

När insticksmodulen äger tunneln ser terminalen ingenting

En anslutning som startas från skrivbordsappletten ägs av NetworkManager, och dess OpenVPN-utdata går till journalen för den tjänsten i stället för till ett skal du har öppet. Att köra klienten för hand och inte se något är förväntat i den ordningen, eftersom processen som körs för hand inte är den som bär anslutningen.

Sök i journalen efter tjänsten som äger den, och återskapa sedan parsningen med en detaljnivå du kan läsa. De två kommandona nedan tittar på olika ägare av samma fel.

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

Den fristående körningen är för att läsa meddelanden, inte för att ersätta den hanterade anslutningen, och de två skiljer sig efteråt: DNS-integrering, rutter och livstid tillhör insticksmodulen. Att åtgärda ett parsningsfel i den fristående körningen åtgärdar inte automatiskt namnuppslagningen när appletten tar över, så håll de två observationerna åtskilda.

Två binärfiler, en PATH

En manuellt byggd installation under /usr/local vinner vid ett skal-anrop, eftersom /usr/local/sbin kommer före /usr/sbin i Ubuntus standard-PATH. En unit använder inte din PATH; den kör den absoluta sökväg som står i ExecStart. Så versionen som fungerar i din terminal och versionen som misslyckas som tjänst kan vara verkligen olika program.

Jämför de två innan du bygger om något. Det tredje kommandot är det som avgör argumentet.

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

Ännu en miljöskillnad gömmer sig på samma ställe. En paketerad enhet förlitar sig på en körtidskatalog under /run, som systemd skapar för den; en handskriven ersättningsenhet som utelämnar den inställningen kan misslyckas innan den öppnar en enda fil, och felet ser ut som en allmän vägran utan något OpenVPN-meddelande.

Fel som klienten inte kan rapportera

Vissa utfall avgörs i den bortre änden. En gateway som svarar med en HTTP-status och stänger anslutningen har berättat om sitt eget tillstånd, och nästa användbara steg är dess logg eller kontot bakom inloggningsuppgifterna i stället för dina lokala filer. Inget lokalt är trasigt i det scenariot, och att redigera profilen för att kompensera gör nästa diagnos svårare. Läs den loggen innan du rör klientkonfigurationen.

Ett annat tyst fall är en klient som fungerar korrekt. En tunnel i klientläge lyssnar aldrig på en port, så en kontroll som väntar sig en öppen lyssnare rapporterar ingenting och ser ut som ett fel. Bekräfta vilket läge du startade innan du drar en slutsats från en tom portlista.

Arbeta igenom lagren i ordning: finns enheten och är instansnamnet rätt, nådde något journalen eller filen --log, vilken binärfil och profil körde faktiskt, och är felet lokalt eller avlägset. Varje svar tar bort ett lager. Att börja med profilen innebär att skriva om en fil som kanske aldrig öppnades.