OpenVPN haiwaki bila hitilafu? Angalia journal

Amri inarudi, huduma inaonekana imeshindwa, na hakuna kitu kinachofanana na maelezo kinachofika kwenye terminal. Ukimya huo ni dalili ambayo watu wanaelezea kama «OpenVPN haiwaki», na karibu kamwe haimaanishi programu ilikufa bila kusema chochote. Inamaanisha ujumbe ulikwenda kwenye kituo ambacho hukuwa ukisoma, au kile ulichokianzisha hakikuwa kile ulichokisanidi. Kesi zote mbili zinaweza kutambuliwa kwa chini ya dakika moja pindi uache kuchukulia profile kama mtuhumiwa.

Maeneo manne hunyonya matokeo: journal ya unit, plugini inayomiliki muunganisho, upande mwingine wa handaki, na binary tofauti na ile unayofikiri inaendeshwa. Kila moja ina ukaguzi wake.

Ukimya unamaanisha hukuwa ukiangalia kituo sahihi

Wito wa mbele huchapisha kwenye terminal yako. Unit huchapisha kwenye journal, na unit iliyoshindwa inaweza kutoka kabla ya kuandika chochote ikiwa hitilafu iko katika jinsi ilivyoanzishwa na si katika kile ilichoambiwa. Tofauti hii ni muhimu: hakuna kumbukumbu kwenye journal inamaanisha mchakato haukuwa ukifanya kazi kwa kweli, wakati kumbukumbu moja ikifuatiwa na kutoka inamaanisha ulifanya kazi na ulikataa kitu.

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

Ongeza systemctl show -p Result -p ExecMainStatus openvpn-client@office ili kutenganisha kutoka safi na ishara. Hali 1 na Result=exit-code ni uamuzi wa programu; Result=signal au muda wa kumaliza huonyesha mazingira badala yake, na hakuna kiasi cha uhariri wa profile kitakachobadilisha hilo. Andika thamani zote mbili kabla ya kuanzisha tena kitu chochote, kwa sababu kuanzisha tena hufuta hali ya muda iliyozalisha.

Jina la instance ni sehemu ya njia

Unit ya kiolezo iliyofungashwa haichukui njia ya faili. Inachukua jina la instance, na jina hilo huongezwa kwenye saraka ili kupata profile: office katika Debian na Ubuntu hutatuliwa kuwa /etc/openvpn/client/office.conf. Faili inayoitwa office-v2.conf, iliyoanzishwa kama @office haisomwi kamwe, na unit hutoka kimya kwa sababu kwa mtazamo wake hakuna kitu cha kufanya. Saraka ya utafutaji inatofautiana kati ya hali ya client na server, kwa hiyo kosa lile lile huelekeza mahali pengine kabisa unapobadilisha kiolezo.

Tofauti hiyo ndiyo chanzo cha kawaida cha kushindwa kimya, na haionekani kwenye profile kwa sababu profile iko sawa. Orodhesha kilicho kweli na ulinganishe majina mawili herufi kwa herufi, pamoja na kiendelezi chochote ambacho kifurushi kinatarajia.

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

Ikiwa unit imewezeshwa lakini hakuna instance iliyoorodheshwa, uwezeshaji wenyewe unaweza kurejelea jina ambalo lilipatiwa jina jingine baadaye. Kuwezesha tena instance sahihi kwa kawaida kunatosha, na faili ya unit ya zamani iliyobaki inafaa kufutwa ili isimchanganye mtu anayefuata. Faili ya unit iliyobaki ni kitu kidogo kinachomgharimu mtu saa moja baadaye.

Wakati plugini inamiliki handaki, terminal haioni chochote

Muunganisho unaoanzishwa kutoka applet ya desktop unamilikiwa na NetworkManager, na matokeo yake ya OpenVPN yanakwenda kwenye journal ya huduma hiyo na si kwenye shell yoyote uliyofungua. Kuendesha client kwa mkono na kutoona chochote kunatarajiwa katika mpangilio huo, kwa sababu mchakato ulioendeshwa kwa mkono si ule unaobeba muunganisho.

Tafuta kwenye journal huduma inayomiliki, kisha uzae tena uchanganuzi kwa kiwango cha maelezo unachoweza kusoma. Amri mbili hapa chini zinaangalia wamiliki tofauti wa kushindwa kulekule.

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

Kuendesha kwa kujitegemea ni kwa kusoma ujumbe, si kwa kubadilisha muunganisho unaosimamiwa, na vyote viwili vinatofautiana baadaye: ujumuishaji wa DNS, njia na muda wa uhai ni vya plugini. Kurekebisha hitilafu ya uchanganuzi katika kuendesha kwa kujitegemea hakuwezi kwa moja kurekebisha utatuzi wa majina applet inapochukua udhibiti, kwa hiyo weka uchunguzi mbili tofauti.

Binary mbili, PATH moja

Ujengaji wa mikono uliosakinishwa chini ya /usr/local hushinda kwenye wito wa shell, kwa sababu /usr/local/sbin huja kabla ya /usr/sbin kwenye PATH ya kawaida ya Ubuntu. Unit haitumii PATH yako; inaendesha njia kamili iliyoandikwa kwenye ExecStart. Kwa hiyo toleo linalofanya kazi kwenye terminal yako na toleo linaloshindwa kama huduma zinaweza kuwa programu tofauti kabisa.

Linganisha mbili kabla ya kujenga upya kitu chochote. Amri ya tatu ndiyo inayoamua hoja.

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

Tofauti nyingine ya mazingira imejificha mahali pale pale. Unit iliyofungashwa inategemea saraka ya muda wa uendeshaji chini ya /run, ambayo systemd inaitengeneza kwa ajili yake; unit mbadala iliyoandikwa kwa mkono inayoacha mpangilio huo inaweza kushindwa kabla ya kufungua faili moja, na kushindwa kunaonekana kama kukataliwa kwa jumla bila ujumbe wowote wa OpenVPN.

Kushindwa ambako client hawezi kuripoti

Baadhi ya matokeo huamuliwa upande wa mbali. Lango linalojibu kwa hali ya HTTP na kufunga muunganisho limekuambia kuhusu hali yake yenyewe, na hatua inayofuata yenye manufaa ni log yake au akaunti iliyo nyuma ya kitambulisho na si faili zako za ndani. Katika hali hiyo hakuna kitu cha ndani kilichovunjika, na kuhariri profile ili kufidia kunafanya utambuzi unaofuata kuwa mgumu zaidi. Soma log hiyo kabla ya kugusa usanidi wa client.

Kesi nyingine ya kimya ni client inayofanya kazi vizuri. Handaki ya hali ya client haisikilizi kamwe kwenye port, kwa hiyo ukaguzi unaotarajia msikilizaji wazi hautaripoti chochote na utaonekana kama kushindwa. Thibitisha ni hali gani uliyoanzisha kabla ya kutoa hitimisho kutoka kwenye orodha tupu ya port.

Fanyia kazi tabaka kwa mpangilio: unit ipo na jina la instance ni sahihi, kuna kitu kilifika kwenye journal au faili --log, binary na profile gani ziliendeshwa kweli, na kushindwa ni kwa ndani au kwa mbali. Kila jibu huondoa tabaka moja. Kuanzia na profile inamaanisha kuandika upya faili ambalo huenda halikufunguliwa kamwe.