Dalawang launcher ang nagbubukas ng parehong profile sa isang makina, at ang GUI lang ang kumokonekta. Maayos ang file at malamang ayos din ang installer; ang pagkakaiba ay ang kontekstong ibinibigay ng bawat launcher sa openvpn.exe. Ang working directory, pagkakakilanlan ng account at mga attribute ng file ay kasama sa kontekstong iyon. Suriin sila sa ganoong pagkakasunod-sunod at huminto sa unang makapagpapaliwanag ng error.

Tiyakin kung aling launcher ang nabibigo

Magsimula sa pagpapatunay ng hati. Kung kumokonekta ang GUI at hindi ang serbisyo sa parehong landas ng profile, may nakakabasa ng file at ang tanong ay kung sino ang nagbabasa nito at mula saan. Kung parehong nabigo, sira ang profile at wala sa mga ito ang naaangkop. Isulat ang pangalan ng serbisyo at ang eksaktong profile na inutusang i-load nito.

Ang serbisyong nakaturo sa sarili nitong auto-start directory ay maaaring hindi naglo-load ng file na bukas mo sa isang editor. Ihambing ang landas sa configuration ng serbisyo sa landas sa GUI, titik por titik, dahil sapat na ang isang pangalan ng folder sa dulo o ibang letra ng drive para dalhin ka sa maling sangay.

Saan nare-resolve ang mga relatibong landas

Ang profile na tumutukoy sa ca.crt o sa isang helper script sa bare na pangalan ay humihingi ng paghahanap na relatibo sa kung saan naroon ang proseso. Nagsisimula ang GUI sa folder ng configuration, kaya nagre-resolve ang mga pangalang iyon. Ang serbisyong sinimulan ng service manager ay walang gayong panimulang punto, at nabibigo ang paghahanap bago pa mabasa ang anumang certificate. Iyon ang dahilan kung bakit gumagana ang parehong profile sa isang launcher at hindi sa isa.

Bigyan ang wrapper ng directory na pagsisimulan, o gawing absolute ang bawat reference. Ganito ang paggaya sa konteksto ng GUI sa isang command line:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Ang pagtaas ng verbosity sa command na iyon ay nagpapakita ng eksaktong landas na sinubukan. Gawin ito bago baguhin ang mga permission, dahil ang nawawalang file at ang tinanggihang pagbasa ay nangangailangan ng magkaibang pagwawasto. Hindi sila pinag-iiba ng default na log. Isang dagdag na flag ang nakakatipid ng isang oras ng hula.

Kapag hindi makabasa ang pagkakakilanlan ng serbisyo

Tumakbo ang serbisyo bilang isang system identity, hindi bilang ikaw. Ang isang ACL na nagbibigay sa user mo ng buong kontrol at wala sa iba ay nabibigo doon habang perpektong gumagana sa session mo. Ang profile na nasa isang mapped drive o authenticated share ay nabibigo sa parehong dahilan. Tiyakin ang mga permission ng file bago tumingin sa anupamang bagay.

Ang pagsusuri ay isang pagbasa ng epektibong mga permission at isang pagbasang sinubukan bilang pagkakakilanlan ng serbisyo. Patakbuhin ang unang bahagi mula sa elevated prompt:

icacls "C:\VPN\profiles\office\office.ovpn"

Pagkatapos ay subukan ang parehong pagbasa bilang pagkakakilanlan ng serbisyo, halimbawa gamit ang psexec -s -i mula sa Sysinternals, at tingnan kung bumubukas ang file. Kung hindi, wala nang makakatulong na pagwawasto ng landas. Ayusin ang ACL o ilipat ang profile sa lokasyong kayang basahin ng pagkakakilanlan ng serbisyo.

Ang encryption sa antas ng file ang pangalawa, mas bihirang kaso. Ang profile na may attribute ng Encrypting File System ay transparent na dinedekripto para sa user na nag-encrypt nito at nananatiling hindi mabasa ng service account. Iyon ang dahilan kung bakit bumubukas ang parehong file sa editor mo at hindi sa ilalim ng serbisyo.

Nakikita ang attribute mula sa elevated prompt, at hindi binubuksan ng pagsusuri nito ang profile. Patakbuhin ang dalawang command at basahin ang output:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Ang pag-alis ng attribute ay nagpapabasa ng file, at tinatanggal din nito ang proteksyong dala nito. Kung kailangang manatiling protektado ang profile, ilagay ang lihim na materyal kung saan may tahasang grant ang pagkakakilanlan ng serbisyo sa halip na umasa sa per-user encryption. Ang ganitong kaayusan ay nakakalampas sa pagbabago ng password, at ginagawa nitong masusuri ang access ng iba maliban sa taong nag-encrypt ng file.

Pagpapasya kung sino ang may-ari ng tunnel

Maaaring magtanong ng password ang GUI at makabasa ng certificate mula sa user store mo. Hindi kaya ng serbisyo ang alinman sa dalawa, kaya ang profile na umaasa sa interactive na lihim ay hindi kailanman magsisimula nang walang nagbabantay, gaano man ayusin ang mga landas. Ang hangganang iyon ay isang desisyon sa disenyo, hindi isang depektong dapat dayain. Pumili ng isang may-ari bago magbago ng anupaman.

Kung kailangang nakabukas ang tunnel bago mag-login, bigyan ang serbisyo ng pinagmumulan ng kredensyal na walang nagbabantay at sariling kopya ng profile. Kung kailangan lang nitong umiral habang nasa desk ka, itago ito sa GUI at alisin ang kopya ng serbisyo. Ang pareho nang sabay ang configuration na lumilikha ng mga conflict sa adapter at doble ang ruta.

Ang conflict na iyon ay kadalasang na-diagnose bilang error sa config sa halip na dalawang may-ari na nag-aagawan sa isang adapter. Ipapakita ng event log ang isang prosesong nabigong buksan ang TAP device, na mukhang problema sa permission at hindi naman. Bilangin muna ang mga may-ari.

Ano ang talagang inilulunsad ng service wrapper

Ang entry point ng serbisyo ay isang maliit na wrapper na nagbabasa ng sarili nitong nakaimbak na mga parameter at pagkatapos ay inilulunsad ang openvpn.exe. Kapag hindi tugma ang command line sa event log sa inaasahan mo, ang mga value na iyon ang dapat suriin. Ang muling pag-install ay nagbabalik sa kanila sa default at sinisira ang ebidensya. Basahin muna sila.

Nabubuhay ang mga value sa registry sa ilalim ng sariling key ng serbisyo, at ipinapakita ng sc qc ang binary path na ilulunsad ng service manager. Ihambing ang landas na iyon sa nakaimbak na configuration ng wrapper bago i-edit ang alinman sa kanila.

Ang pagpapalit ng wrapper ng isang script na kontrolado mo ay mas invasive, pero pinipiga nito ang epektibong command line sa isang basahang file. Tapusin sa isang restart, pagkatapos basahin ang per-profile log hanggang lumitaw ang unang matagumpay na startup line. Ang service state na “running” ay nangangahulugan lang na hindi pa umalis ang wrapper, na totoo rin kapag agad namatay ang anak nito.

Kaugnay na mga artikulo