OpenVPN start net sûnder flater? Sjoch yn it journal

It kommando komt werom, de tsjinst stiet op mislearre, en neat dat op in ferklearring liket berikt de terminal. Dat stilte is it symptoom dat minsken beskriuwe as »OpenVPN start net«, en it betsjut hast nea dat it programma stoar sûnder eat te sizzen. It betsjut dat it berjocht nei in kanaal gie dat jo net liesen, of dat wat jo starten net wie wat jo konfigurearren. Beide gefallen binne yn minder as in minút te diagnostisearjen sadra jo ophâlde it profyl as de fertochte te behanneljen.

Fjouwer plakken absorbearje de útfier: it journal fan de unit, de plugin dy't de ferbining besit, de oare kant fan de tunnel en in oar binêr as dat jo tinke dat rint. Elk hat syn eigen kontrôle.

Stilte betsjut dat jo it juste kanaal net folgen

In oanrop op de foargrûn prints nei jo terminal. In unit prints nei it journal, en in mislearre unit kin útgean foardat it hokker dan ek skriuwt as de flater sit yn hoe't it start is, net yn wat der tsjin sein is. It ûnderskie is wichtich: gjin journal-ynskriuwing betsjut dat it proses nea echt rûn, wylst ien ynskriuwing folge troch in útgong betsjut dat it rûn en eat wegere.

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

Foegje systemctl show -p Result -p ExecMainStatus openvpn-client@office ta om in skjinne útgong fan in sinjaal te skieden. In status fan 1 mei in Result=exit-code is in programma-beslút; Result=signal of in timeout wize earder op de omjouwing, en gjin hoemannichte profylbewurking sil dat feroarje. Skriuw beide wearden op foardat jo wat dan ek opnij starte, want in werstart wisket de tydlike tastân dy't se makke hat.

De ynstânsjenamme is diel fan it paad

De ferpakte sjabloan-unit nimt gjin bestânspaad. It nimt in ynstânsjenamme, en dy namme wurdt by in map foege om it profyl te finen: office lost op nei /etc/openvpn/client/office.conf yn de Debian- en Ubuntu-ferpakking. In bestân mei de namme office-v2.conf dat as @office start, wurdt nea lêzen, en de unit giet stil wei omdat der fanút syn eachpunt neat te dwaan wie. De sykmap ferskilt tusken klant- en servermodus, dat deselde flater wiist hiel earne oars as jo fan sjabloan wikselje.

Dy misferstân is de meast foarkommende oarsaak fan de stille mislearring, en it is ûnsichtber yn it profyl om't it profyl goed is. List op wat eins bestiet en fergelykje de beide nammen teken foar teken, ynklusyf elke útwreiding dy't de ferpakking ferwachtet.

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

As de unit ynskeakele is mar gjin inkelde ynstânsje neamd, dan kin de ynskeakeling sels ferwize nei in namme dy't letter omdoopt is. It krekte ynstânsje wer ynskeakelje is meast genôch, en it âlde unit-bestân dat oerbliuwt is it wurdich te wiskjen sadat it de folgjende persoan net yn 'e war bringt. In oerbliuwend unit-bestân is in lyts ding dat immen letter in oere kostet.

As de plugin de tunnel besit, sjocht de terminal neat

In ferbining dy't fan de buroblêd-applet start is, wurdt besit troch NetworkManager, en syn OpenVPN-útfier giet yn it journal fan dy tsjinst ynstee fan yn in shell dy't jo iepen hawwe. De klant mei de hân rinne litte en neat sjen is ferwachte yn dy regeling, om't it mei de hân rûne proses net dejinge is dy't de ferbining draacht.

Sykje yn it journal nei de tsjinst dy't it besit, reprodusearje dan de parsing mei in detailnivo dat jo lêze kinne. De beide kommando's hjirûnder sjogge nei ferskillende eigners fan deselde mislearring.

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

De selsstannige run is om berjochten te lêzen, net om de behearde ferbining te ferfangen, en de beide ferskille dêrnei: DNS-yntegraasje, rûtes en libbensdoer hearre by de plugin. It reparearjen fan in parseflater yn de selsstannige run reparearret net automatysk nammeoplossing sadra de applet oernimt, dus hâld de beide observaasjes apart.

Twa binaries, ien PATH

In hânmjittich boud ynstallaasje ûnder /usr/local wint by in shell-oanrop, om't /usr/local/sbin foar /usr/sbin komt op de standert Ubuntu-PATH. In unit brûkt jo PATH net; it rint it absolute paad dat yn ExecStart skreaun is. Sa kin de ferzje dy't yn jo terminal wurket en de ferzje dy't as tsjinst mist, wier ferskillende programma's wêze.

Fergelykje de beide foardat jo wat dan ek wer opbouwe. It tredde kommando is dejinge dy't it argumint beslist.

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

Noch ien omjouwingsferskil ferstoppet him op itselde plak. In ferpakte unit fertrout op in runtime-map ûnder /run dy't systemd derfoar oanmakket; in hânskreaun ferfangings-unit dy't dy ynstelling weilitten, kin mislearje foardat it ien bestân iepenet, en de mislearring liket op in generike wegering sûnder in OpenVPN-berjocht.

Mislearrings dy't de klant net rapportearje kin

Guon útkomsten wurde oan de fiere kant besletten. In gateway dy't mei in HTTP-status antwurdet en de ferbining slút, hat jo oer syn eigen tastân ferteld, en de nuttige folgjende stap is syn log of it akkount efter de legitimisaasje ynstee fan jo lokale bestannen. Neat lokaals is yn dat senario stikken, en it profyl bewurkje om it te kompensearjen makket de folgjende diagnoaze hurder. Lês dat log foardat jo de klantkonfiguraasje oanreitsje.

In oare stille gefal is in klant dy't korrekt wurket. In tunnel yn klantmodus harket nea op in poarte, dat in kontrôle dy't in iepen harker ferwachtet rapportearret neat en liket op in mislearring. Befêstigje hokker modus jo starten foardat jo in konklúzje lûke út in lege poartelist.

Wurkje de lagen yn folchoarder: bestiet de unit en is de ynstânsjenamme goed, berikte eat it journal of it bestân --log, hokker binêre en profyl rûnen eins, en is de mislearring lokaal of fier. Elk antwurd hellet in laach fuort. By it profyl begjinne betsjut in bestân oerskriuwe dat miskien nea iepene is.