Hindi umaandar ang OpenVPN nang walang error? Tingnan ang journal

Bumabalik ang utos, lumalabas na nabigo ang serbisyo, at walang anumang kahawig ng paliwanag na umaabot sa terminal. Ang katahimikang iyon ang sintomas na inilalarawan ng mga tao bilang «hindi umaandar ang OpenVPN», at halos hindi kailanman nangangahulugan na namatay ang programa nang walang sinabi. Ibig sabihin, ang mensahe ay napunta sa channel na hindi mo binabasa, o ang sinimulan mo ay hindi ang na-configure mo. Ang dalawang kaso ay masusuri sa loob ng wala pang isang minuto kapag tumigil ka sa pagturing sa profile bilang pinaghihinalaan.

Apat na lugar ang sumisipsip ng output: ang journal ng unit, ang plugin na nagmamay-ari ng koneksyon, ang kabilang dulo ng tunnel, at isang binary na iba sa inaakala mong tumatakbo. Bawat isa ay may sariling pagsusuri.

Ang katahimikan ay nangangahulugang hindi mo tiningnan ang tamang channel

Ang tawag sa foreground ay nagpi-print sa iyong terminal. Ang unit ay nagpi-print sa journal, at ang nabigong unit ay maaaring lumabas bago pa man ito magsulat ng anuman kung ang pagkabigo ay nasa paraan ng pag-start nito at hindi sa sinabi dito. Mahalaga ang pagkakaibang ito: walang entry sa journal ay nangangahulugang hindi kailanman talagang tumakbo ang proseso, samantalang isang entry na sinusundan ng paglabas ay nangangahulugang tumakbo ito at tinanggihan ang isang bagay.

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

Idagdag ang systemctl show -p Result -p ExecMainStatus openvpn-client@office para paghiwalayin ang malinis na paglabas sa signal. Ang status 1 na may Result=exit-code ay desisyon ng programa; Result=signal o timeout ay tumutukoy sa kapaligiran sa halip, at walang pag-edit ng profile ang makakabago niyon. Itala ang dalawang halaga bago i-restart ang anuman, dahil binubura ng restart ang pansamantalang kalagayan na lumikha sa kanila.

Bahagi ng landas ang pangalan ng instance

Ang naka-package na template unit ay hindi tumatanggap ng path ng file. Tumatanggap ito ng pangalan ng instance, at ang pangalang iyon ay idinadagdag sa isang direktoryo upang hanapin ang profile: office ay niresolba sa /etc/openvpn/client/office.conf sa packaging ng Debian at Ubuntu. Ang file na tinatawag na office-v2.conf, na sinimulan bilang @office ay hindi kailanman binabasa, at tahimik na lumalabas ang unit dahil sa pananaw nito ay wala namang gagawin. Naiiba ang direktoryo ng paghahanap sa client at server mode, kaya ang parehong pagkakamali ay tumuturo sa ibang lugar kapag pinalitan mo ang template.

Ang pagkakaibang iyon ang pinakakaraniwang pinagmumulan ng tahimik na pagkabigo, at hindi ito nakikita sa profile dahil maayos ang profile. Ilista ang talagang umiiral at ihambing ang dalawang pangalan karakter bawat karakter, kabilang ang anumang extension na inaasahan ng package.

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

Kung naka-enable ang unit ngunit walang instance na nakalista, ang pag-enable mismo ay maaaring tumukoy sa pangalang pinalitan ng pangalan mamaya. Karaniwang sapat ang muling pag-enable ng tamang instance, at sulit na tanggalin ang lumang unit file na naiwan upang hindi ito makalito sa susunod na tao. Ang naiwang unit file ay isang maliit na bagay na nagkakahalaga ng isang oras ng ibang tao mamaya.

Kapag pag-aari ng plugin ang tunnel, wala itong nakikitang anuman ang terminal

Ang koneksyong sinimulan mula sa desktop applet ay pag-aari ng NetworkManager, at ang OpenVPN output nito ay napupunta sa journal ng serbisyong iyon at hindi sa anumang shell na bukas ka. Ang pagpapatakbo ng client nang manu-mano at wala kang nakikitang anuman ay inaasahan sa ayos na iyon, dahil ang prosesong pinatakbo nang manu-mano ay hindi ang nagdadala ng koneksyon.

Hanapin sa journal ang serbisyong may-ari nito, pagkatapos ay ulitin ang pag-parse nang may antas ng detalye na mababasa mo. Ang dalawang utos sa ibaba ay tumitingin sa magkaibang may-ari ng parehong pagkabigo.

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

Ang hiwalay na pagpapatakbo ay para sa pagbasa ng mga mensahe, hindi para palitan ang pinamamahalaang koneksyon, at magkaiba ang dalawa pagkatapos: ang integrasyon ng DNS, mga ruta at tagal ay pag-aari ng plugin. Ang pag-aayos ng error sa pag-parse sa hiwalay na pagpapatakbo ay hindi awtomatikong nag-aayos ng resolusyon ng pangalan kapag kinuha ng applet ang kontrol, kaya panatilihing hiwalay ang dalawang obserbasyon.

Dalawang binary, isang PATH

Ang manu-manong build na naka-install sa ilalim ng /usr/local ay nananalo sa shell na tawag, dahil ang /usr/local/sbin ay nauuna sa /usr/sbin sa default na PATH ng Ubuntu. Hindi ginagamit ng unit ang iyong PATH; pinapatakbo nito ang absolute na landas na nakasulat sa ExecStart. Kaya ang bersyong gumagana sa iyong terminal at ang bersyong nabibigo bilang serbisyo ay maaaring tunay na magkaibang programa.

Ihambing ang dalawa bago muling buuin ang anuman. Ang ikatlong utos ang nagpapasya sa argumento.

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

Isa pang pagkakaiba sa kapaligiran ang nagtatago sa parehong lugar. Ang naka-package na unit ay umaasa sa isang runtime directory sa ilalim ng /run, na nilikha ng systemd para dito; ang manu-manong isinulat na kapalit na unit na nag-iiwan sa setting na iyon ay maaaring mabigo bago pa man ito magbukas ng isang file, at ang pagkabigo ay mukhang pangkalahatang pagtanggi na walang anumang mensahe ng OpenVPN.

Mga pagkabigong hindi maaaring iulat ng client

Ang ilang resulta ay pinagpapasyahan sa malayong dulo. Ang gateway na tumutugon sa status ng HTTP at nagsasara ng koneksyon ay nagsabi na sa iyo tungkol sa sarili nitong kalagayan, at ang susunod na kapaki-pakinabang na hakbang ay ang log nito o ang account sa likod ng kredensyal at hindi ang iyong mga lokal na file. Walang lokal na sira sa senaryong iyon, at ang pag-edit ng profile para mabayaran iyon ay nagpapahirap sa susunod na pagsusuri. Basahin ang log na iyon bago mo hawakan ang configuration ng client.

Isa pang tahimik na kaso ay ang client na gumagana nang tama. Ang tunnel sa client mode ay hindi kailanman nakikinig sa isang port, kaya ang pagsusuring umaasa sa bukas na listener ay wala ring iuulat at magmumukhang pagkabigo. Kumpirmahin kung aling mode ang sinimulan mo bago ka gumawa ng konklusyon mula sa walang laman na listahan ng port.

Isa-isahin ang mga layer sa tamang pagkakasunod-sunod: may unit ba at tama ba ang pangalan ng instance, may umabot ba sa journal o sa file --log, aling binary at profile ang talagang tumakbo, at lokal ba o malayo ang pagkabigo. Bawat sagot ay nag-aalis ng isang layer. Ang pagsisimula sa profile ay nangangahulugang muling pagsusulat ng file na maaaring hindi kailanman nabuksan.