Nagsimula ang OpenVPN pero walang naiprinta: suriin muna ang log-append

Sinisimulan mo ang OpenVPN mula sa shell na may configuration file, at nakatayo lang doon ang terminal na walang anumang output. Walang banner, walang error, walang prompt. Sinasabi ng instinto na nabigo ang pagsisimula, kaya nagsisimula ka ng isa pang kopya, pagkatapos ng isa pa, at nauuwi ang makina sa ilang kalahating naka-configure na instance. Bago ang lahat ng iyon, suriin ang profile para sa isang direktiba na nag-redirect na ng log sa ibang lugar. Ang katahimikan ay katangian ng console, hindi ng proseso.

Ang katahimikan ay may dalawang magkaibang paliwanag

Ang una ay maayos na tumatakbo ang proseso at nagsusulat sa file na hindi mo binabantayan. Ang pangalawa ay agad itong lumabas na may error na naitala sa parehong file.

Parehong nag-iiwan ng blangkong terminal, at isang tanong ang naghihiwalay sa kanila: may proseso ba ngayon, at ano ang nasa file na inutusang sulatan. Sagutin iyon bago muling hawakan ang configuration. Ang muling pagsisimula para makakuha ng output ang paraan ng dalawang instance na mag-away sa isang tunnel device at parehong port, na gumagawa ng mga error na walang kaugnayan sa orihinal na problema.

Hanapin ang direktiba, pagkatapos hanapin ang proseso.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Hanapin ang destinasyon na ginagamit ng tumatakbong proseso

Basahin ang profile na aktwal na ginamit sa pag-start ng proseso, hindi ang na-edit mo. Ang instance na pinamamahalaan ng serbisyo ay karaniwang naglo-load ng ibang path at tumatakbo sa ibang working directory, kaya ang relative filename ay niresolba sa lugar na hindi mo inaasahan.

Ang tahasang cd direktiba ay ginagawang mas matalas ang pagkakaibang iyon, dahil gumagalaw ang relative path kasama ng pagbabago ng directory. Kung namana mo ang configuration na ito, maaaring nasa lugar ang file na wala nang hahanap doon ngayon.

Ihambing ang oras ng pagbabago ng file sa sandaling sinimulan mo. Ang log ng nakaraang linggo ay ebidensya tungkol sa nakaraang linggo. Pagkatapos basahin ang huling mga linya ng file na nagbago, at ituring ang anumang naroon bilang startup message na nawawala sa iyo.

log kumpara sa log-append: ebidensya at pagbura

log-append nagdadagdag sa kung ano ang nasa file na. log binubuksan ang file para sa pagsulat at pinuputol ito, kaya ang paglipat sa pagitan ng dalawa ay maaaring bumura ng run na babasahin mo na sana.

Kung may nagbago ng direktiba habang nagde-debug, wala na ang naunang ebidensya at magmumukhang kahina-hinalang maliit ang laki ng file. Sulit itong malaman bago mo ihambing ang dalawang run at tapusin na may nabago. Burahin ang log nang sadya o panatilihin ito, ngunit alamin kung alin ang ginawa mo. Ang ebidensyang sinadyang inalis ay mas madaling isipin kaysa ebidensyang aksidenteng nawala.

Wala sa mga opsyon ang gumagawa ng kulang na parent directory, at wala ring nagbibigay ng access sa pamamagitan ng permissions ng filesystem o sandbox ng serbisyo. Ang path na mukhang tama sa configuration ay maaari pa ring hindi masulatan ng account na pinapatakbo ng daemon, at kapag ganoon ay maaaring mabigo ang daemon bago pa ito makapag-ulat ng anuman. Suriin kung umiiral ang directory at kung sino ang may-ari nito bago ipagpalagay na ang filename ang problema.

Kapag hinuli ng service wrapper ang output

Sa ilalim ng systemd, ang standard output at mga error ay napupunta sa journal maliban kung may tahasang file directive na may priyoridad, at maaaring hulihin ng vendor wrapper ang mga ito sa ganap na ibang lugar.

Iyon ang dahilan kung bakit kakaiba ang pag-uugali ng parehong profile mula sa isang shell at mula sa isang unit. Ang environment ng unit, ang working directory nito at ang standard stream nito ay lahat naiiba sa iyong interactive na shell. Ang relative path ay maaaring maresolba sa isang konteksto at hindi makarating kahit saan sa isa. Basahin ang depinisyon ng unit kapag hindi sila magkasundo, hindi ang profile.

Ihambing ang dalawang paraan ng pagsisimula sa halip na tapusin na sira ang isa sa kanila. Basahin ang command line ng unit at ang environment nito, pagkatapos basahin ang journal para sa parehong time window. Kung ang wrapper ay nagre-redirect ng output sa sarili nitong file, ang file na iyon ang iyong log ngayon, at walang kaugnayan ang mga direktiba ng OpenVPN sa kung saan napunta ang mga mensahe.

Taasan ang verbosity pagkatapos mo lamang itong mabasa

Ang pagtaas ng verbosity bago mahanap ang destinasyon ay gumagawa lamang ng mas maraming teksto sa lugar na hindi mo tinitingnan.

Kapag alam mo na kung saan lumalapag ang output, ang katamtamang antas ay nagpapakita ng profile na pinaparse at ng koneksyon na sinusubukan. Dalawa o tatlo ay sapat para sa problema sa pagsisimula. Ang mas matataas na antas ay may halaga kapag ang pagkabigo ay detalye ng negosasyon, at mabilis din nilang pinapalaki ang file.

Pagkatapos basahin ang tunay na error. Walang pinapatunayan ang tahimik na terminal tungkol sa kung umangat ang tunnel, at ang pagkabigong naitala sa file ang karapat-dapat ayusin.