OpenVPN startar ikkje utan feil? Sjå i journalen

Kommandoen kjem tilbake, tenesta viser seg som mislukka, og ingenting som liknar ei forklaring når terminalen. Den stilla er symptomet folk skildrar som «OpenVPN startar ikkje», og det tyder nesten aldri at programmet døydde utan å seie noko. Det tyder at meldinga gjekk til ein kanal du ikkje las, eller at det du starta ikkje var det du konfigurerte. Begge tilfella kan diagnostiserast på under eitt minutt når du sluttar å handsame profilen som den mistenkte.

Fire stader absorberer utdata: journalen til eininga, programtillegget som eig tilkoplinga, den andre enden av tunnelen og ei anna binærfil enn den du trur køyrer. Kvar har si eiga sjekk.

Stillheit tyder at du ikkje såg på rett kanal

Ein køyring i forgrunnen skriv til terminalen din. Ei eining skriv til journalen, og ei mislukka eining kan avslutte før ho skriv noko i det heile teke dersom feilen ligg i korleis ho vart starta og ikkje i det ho fekk beskjed om. Forskjellen er viktig: inga journaloppføring tyder at prosessen aldri eigentleg køyrde, medan éi oppføring etterfølgd av ei avslutning tyder at han køyrde og avviste noko.

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 å skilje ei rein avslutning frå eit signal. Ein status på 1 med ein Result=exit-code er ei programavgjerd; Result=signal eller ein timeout peikar i staden på miljøet, og inga mengd profilredigering endrar det. Noter begge verdiane før du startar noko på nytt, fordi ein omstart slettar den forbigåande tilstanden som produserte dei.

Instansnamnet er ein del av banen

Den pakka maleininga tek ikkje ein filbane. Ho tek eit instansnamn, og det namnet vert lagt til ein katalog for å finne profilen: office vert løyst til /etc/openvpn/client/office.conf i Debian- og Ubuntu-pakken. Ei fil som heiter office-v2.conf, starta som @office vert aldri lesen, og eininga avsluttar stille fordi det frå hennar synsstad ikkje var noko å gjere. Oppslagsmappa er ulik i klient- og servermodus, så den same feilen peikar heilt andre stader når du byter mal.

Det avviket er den vanlegaste kjelda til den stille feilen, og det er usynleg i profilen fordi profilen er i orden. List opp kva som faktisk finst, og samanlikn dei to namna teikn for teikn, inkludert kva utviding pakken ventar.

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

Viss eininga er aktivert men ingen instans er oppført, kan aktiveringa sjølv vise til eit namn som seinare vart omdøypt. Å aktivere rett instans på nytt er vanlegvis nok, og den gamle eininga-fila som blir liggjande er verdt å slette så ho ikkje forvirrar neste person. Ei attverande eining-fil er ei lita sak som kostar nokon ein time seinare.

Når programtillegget eig tunnelen, ser terminalen ingenting

Ei tilkopling starta frå skrivebordsappletten er eigd av NetworkManager, og OpenVPN-utdata går til journalen til den tenesta i staden for til eit skal du har ope. Å køyre klienten for hand og ikkje sjå noko er venta i den ordninga, fordi prosessen som vert køyrd for hand ikkje er den som ber tilkoplinga.

Søk i journalen etter tenesta som eig han, og gjer så parseringa på nytt med ein detaljrikdom du kan lese. Dei to kommandoane nedanfor ser på ulike eigarar av same 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åande køyringa er for å lese meldingar, ikkje for å erstatte den styrte tilkoplinga, og dei to er ulike etterpå: DNS-integrering, ruter og levetid høyrer til programtillegget. Å rette ein parsefeil i den frittståande køyringa rettar ikkje automatisk namneoppslag når appletten overtek, så hald dei to observasjonane åtskilde.

To binærfiler, éin PATH

Ein manuelt bygd installasjon under /usr/local vinn ved ei skal-køyring, fordi /usr/local/sbin kjem før /usr/sbin på standard Ubuntu-PATH. Ei eining brukar ikkje PATH-en din; ho køyrer den absolutte banen som er skriven i ExecStart. Så versjonen som verkar i terminalen din og versjonen som feilar som teneste kan vere verkeleg ulike program.

Samanlikn dei to før du byggjer noko på nytt. Den tredje kommandoen er den som avgjer argumentet.

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

Ein annan miljøforskjell gøymer seg på same stad. Ei pakka eining er avhengig av ei køyretidsmappe under /run som systemd opprettar for ho; ei handskriven erstatningseining som utelèt den innstillinga kan feile før ho opnar ei einaste fil, og feilen ser ut som ei generell avvising utan noka OpenVPN-melding.

Feil klienten ikkje kan rapportere

Nokre utfall vert avgjorde i den fjerne enden. Ein gateway som svarar med ein HTTP-status og lukkar tilkoplinga har fortalt deg om sin eigen tilstand, og det nyttige neste steget er loggen hans eller kontoen bak legitimasjonen i staden for dei lokale filene dine. Ingenting lokalt er øydelagt i det scenariet, og å redigere profilen for å kompensere gjer neste diagnose vanskelegare. Les den loggen før du rører klientkonfigurasjonen.

Eit anna stille tilfelle er ein klient som fungerer rett. Ein tunnel i klientmodus lyttar aldri på ein port, så ein sjekk som ventar ein open lyttar vil ikkje rapportere noko og sjå ut som ein feil. Stadfest kva modus du starta før du dreg ei slutning frå ei tom portliste.

Arbeid laga i rekkjefølgje: finst eininga og er instansnamnet rett, nådde noko journalen eller fila --log , kva binærfil og profil køyrde faktisk, og er feilen lokal eller ekstern. Kvart svar fjernar eit lag. Å byrje med profilen tyder å skrive om ei fil som kanskje aldri vart opna.