OpenVPN begin sonder foutboodskap? Kyk in die joernaal

Die opdrag keer terug, die diens wys misluk, en niks wat na ’n verduideliking lyk bereik die terminaal nie. Daardie stilte is die simptoom wat mense beskryf as “OpenVPN begin nie”, en dit beteken byna nooit dat die program dood is sonder om iets te sê nie. Dit beteken die boodskap het na ’n kanaal gegaan wat jy nie gelees het nie, of dat die ding wat jy begin het nie die ding was wat jy opgestel het nie. Beide gevalle is binne minder as ’n minuut diagnoseerbaar sodra jy ophou om die profiel as die verdagte te beskou.

Vier plekke absorbeer die uitset: die eenheid se joernaal, die inprop wat die verbinding besit, die ander kant van die tonnel, en ’n ander program as die een wat jy dink loop. Elkeen het sy eie kontrole.

Stilte beteken jy het nie die regte kanaal dopgehou nie

’n Voorgrondaanroep druk na jou terminaal. ’n Eenheid druk na die joernaal, en ’n mislukte eenheid kan uittree voordat dit enigiets skryf as die fout lê in hoe dit begin is eerder as in wat daaraan gesê is. Die onderskeid maak saak: geen joernaalinskrywing beteken die proses het nooit regtig geloop nie, terwyl een inskrywing gevolg deur ’n uittrede beteken dit het geloop en iets verwerp.

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

Voeg systemctl show -p Result -p ExecMainStatus openvpn-client@office by om ’n skoon uittrede van ’n sein te onderskei. ’n Status van 1 met ’n Result=exit-code is ’n programbesluit; Result=signal of ’n tydsverloop dui eerder op die omgewing, en geen hoeveelheid profielredigering sal dit verander nie. Teken albei waardes aan voordat jy enigiets herbegin, want ’n herbegin wis die tydelike toestand wat hulle voortgebring het.

Die instansienaam is deel van die pad

Die verpakte sjablooneenheid neem nie ’n lêerpad nie. Dit neem ’n instansienaam, en daardie naam word by ’n gids gevoeg om die profiel te vind: office los op na /etc/openvpn/client/office.conf op die Debian- en Ubuntu-verpakking. ’n Lêer met die naam office-v2.conf wat as @office begin is, word nooit gelees nie, en die eenheid tree stilweg uit omdat daar vanuit sy oogpunt niks te doen was nie. Die soekgids verskil tussen kliënt- en bediener-modus, so dieselfde fout wys heeltemal elders wanneer jy van sjabloon ruil.

Daardie wanpassing is die algemeenste oorsaak van die stille mislukking, en dit is onsigbaar in die profiel omdat die profiel in orde is. Lys wat werklik bestaan en vergelyk die twee name karakter vir karakter, insluitend enige uitbreiding wat die verpakking verwag.

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

As die eenheid geaktiveer is maar geen instansie gelys word nie, verwys die aktivering self dalk na ’n naam wat later herdoop is. Om die korrekte instansie weer te aktiveer is gewoonlik genoeg, en die ou eenheidslêer wat agterbly is die moeite werd om te verwyder sodat dit nie die volgende persoon verwar nie. ’n Oorblywende eenheidslêer is ’n klein dingetjie wat iemand ’n uur later kos.

Wanneer die inprop die tonnel besit, sien die terminaal niks

’n Verbinding wat vanaf die lessenaar-applet begin is, word deur NetworkManager besit, en sy OpenVPN-uitset gaan na daardie diens se joernaal eerder as na enige dop wat jy oop het. Om die kliënt met die hand te hardloop en niks te sien is in daardie reëling verwag, want die handgestarte proses is nie die een wat die verbinding dra nie.

Deursoek die joernaal vir die diens wat dit besit en reproduseer dan die ontleding met breedsprakigheid wat jy kan lees. Die twee opdragte hieronder kyk na verskillende eienaars van dieselfde mislukking.

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

Die losstaande lopie is om boodskappe te lees, nie om die bestuurde verbinding te vervang nie, en die twee verskil daarna: DNS-integrasie, roetes en leeftyd behoort aan die inprop. Om ’n ontledingsfout in die losstaande lopie reg te maak, maak nie outomaties naamresolusie reg sodra die applet oorneem nie, so hou die twee waarnemings apart.

Twee programme, een PATH

’n Handmatige bou wat onder /usr/local geïnstalleer is, wen vir ’n dopaanroep, want /usr/local/sbin kom voor /usr/sbin op die verstek Ubuntu-PATH. ’n Eenheid gebruik nie jou PATH nie; dit loop die absolute pad wat in ExecStart geskryf is. Dus kan die weergawe wat in jou terminaal werk en die weergawe wat as diens misluk, werklik verskillende programme wees.

Vergelyk die twee voordat jy enigiets herbou. Die derde opdrag is die een wat die argument beslis.

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

Nog een omgewingsverskil skuil op dieselfde plek. ’n Verpakte eenheid maak staat op ’n looptydgids onder /run wat systemd daarvoor skep; ’n handgeskrewe vervangingseenheid wat daardie instelling weglaat, kan misluk voordat dit ’n enkele lêer oopmaak, en die mislukking lyk soos ’n algemene weiering sonder enige OpenVPN-boodskap.

Mislukkings wat die kliënt nie kan rapporteer nie

Sommige uitkomste word aan die verre kant beslis. ’n Hek wat met ’n HTTP-status antwoord en die verbinding sluit, het jou van sy eie toestand vertel, en die nuttige volgende stap is sy log of die rekening agter die geloofsbrief eerder as jou plaaslike lêers. Niks plaasliks is in daardie scenario stukkend nie, en om die profiel te redigeer om dit te vergoed maak die volgende diagnose moeiliker. Lees daardie log voordat jy die kliëntkonfigurasie aanraak.

Nog ’n stille geval is ’n kliënt wat korrek werk. ’n Kliëntmodus-tonnel luister nooit op ’n poort nie, so ’n kontrole wat ’n oop luisteraar verwag, sal niks rapporteer nie en soos ’n mislukking lyk. Bevestig watter modus jy begin het voordat jy ’n gevolgtrekking maak uit ’n leë poortlys.

Werk die lae in volgorde deur: bestaan die eenheid en is die instansienaam reg, het enigiets die joernaal of die --log-lêer bereik, watter program en profiel het werklik geloop, en is die mislukking plaaslik of op afstand. Elke antwoord verwyder ’n laag. Om by die profiel te begin, beteken om ’n lêer te herskryf wat dalk nooit oopgemaak is nie.