OpenVPN-tsjinst mislearret op in profyl dat de GUI iepenet: fiif kontrôles

Twa starters iepenje itselde profyl op ien masine, en allinne de GUI makket ferbining. It bestân is hielendal yntakt en it ynstallaasjeprogramma is wierskynlik yn oarder; wat ferskilt is de kontekst dy’t elke starter openvpn.exe jout. Wurkmap, akkoartidentiteit en bestânsattributen reizgje allegear mei dy kontekst. Kontrolearje se yn dy folchoarder en stop by de earste dy’t de flater ferklearret.

Befêstigje hokker starter mislearret

Begjin mei it bewiis fan de splitsing. As de GUI ferbynt en de tsjinst net, mei deselde profylpaad, dan is it bestân foar immen lêsber en wurdt de fraach wa’t it lêst en wêrfan. As beide mislearje, is it profyl stikken en jildt neat hjirfan. Skriuw de tsjinstnamme op en it krekte profyl dat it laden wurde moast.

In tsjinst dy’t nei syn eigen autostart-map wiist, laden miskien it bestân net dat jo yn in editor iepen hawwe. Ferlykje it paad yn ’e tsjinstkonfiguraasje mei it paad yn ’e GUI, teken foar teken, want in oanhingjende mapnamme of in oare skiifletter is genôch om jo op ’e ferkearde tûke te stjoeren.

Wêr’t relative paden oplost wurde

In profyl dat nei ca.crt of in helperscript by keale namme ferwiist, freget in syktocht relatyf oan wêr’t it proses ek is. De GUI begjint yn ’e konfiguraasjemap, dus dy nammen wurde oplost. In tsjinst dy’t troch de tsjinstbehearder start wurdt, hat sa’n begjinpunt net, en de syktocht mislearret foardat der in sertifikaat lêzen wurdt. Dêrom wurket itselde profyl yn ’e iene starter wol en yn ’e oare net.

Jou de wrapper in map om yn te begjinnen, of meitsje elke ferwizing absolút. It kontekst fan ’e GUI op in kommando rigel werjaan sjocht der sa út:

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

It ferheegjen fan ’e detaillearringsgraad op dy opdracht lit it krekte paad sjen dat besocht is. Doch dat foardat jo tastimmingen feroarje, want in ûntbrekkend bestân en in wegere lêzing freegje ferskate reparaasjes. It standert loch ûnderskiedt se net. Ien ekstra flagge sparret in oere rieden.

Wannear’t de tsjinstidentiteit net lêze kin

In tsjinst rint as in systeemidentiteit, net as jo. In ACL dy’t jo brûker folsleine kontrôle jout en nimmen oars, mislearret dêr wylst it perfekt wurket yn jo sesje. In profyl dat op in ferbûn skiif of in autentisearre dieling holden wurdt, mislearret om deselde reden. Befêstigje de tastimmingen fan it bestân foardat jo nei wat oars sjogge.

De kontrôle is in lêzing fan ’e effektive tastimmingen plus in lêzing besocht as de tsjinstidentiteit. Rin it earste diel út in ferhege kommando rigel:

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

Besykje dan deselde lêzing as de tsjinstidentiteit, bygelyks mei psexec -s -i fan Sysinternals, en sjoch oft it bestân iepenet. As dat net sa is, helpt gjin paadreparaasje. Reparaasje de ACL of ferpleats it profyl nei in lokaasje dêr’t de tsjinstidentiteit lêze kin.

Bestânsnivo-fersifering is it twadde, seldsumere gefal. In profyl markearre mei it Encrypting File System-attribút wurdt transparant ûntsifere foar de brûker dy’t it fersifere hat en bliuwt ûnlêsber foar in tsjinstakkoart. Dêrom iepenet itselde bestân yn jo editor en net ûnder de tsjinst.

It attribút is sichtber fan in ferhege kommando rigel, en it kontrolearjen dêrfan iepenet it profyl net. Rin beide opdrachten út en lês de útfier:

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

It attribút wiskje makket it bestân lêsber, en it ferwideret ek de beskerming dy’t it droech. As it profyl beskerme bliuwe moat, set it geheim materiaal dêr’t de tsjinstidentiteit in útdruklike tastimming hat ynstee fan te fertrouwen op fersifering per brûker. Sa’n regeling oerlibbet in wachtwurdferoaring, en it makket de tagong kontrolearber troch immen oars as dejinge dy’t it bestân fersifere hat.

Beslute wa’t de tunnel besit

De GUI kin om in wachtwurd freegje en kin in sertifikaat lêze út jo brûkersopslach. De tsjinst kin gjin fan beide, dus in profyl dat fan in ynteraktive geheim ôfhinklik is sil nea sûnder tafersjoch starte, hoe’t de paden ek reparearre wurde. Dy limyt is in ûntwerpbeslút, net in defekt om omhinne te wurkjen. Kies ien eigner foardat jo wat oars feroarje.

As de tunnel foar it oanmelden omheech moat, jou dan de tsjinst in boarne fan oanmeldgegevens sûnder tafersjoch en syn eigen kopy fan it profyl. As it allinne bestean moat wylst jo by it buro binne, hâld it dan yn ’e GUI en ferwiderje de tsjinstkopy. Beide tagelyk is de konfiguraasje dy’t adapterkonflikten en dûbele rûtes produsearret.

Dy konflikt wurdt meastentiids diagnostearre as in konfiguraasjeflater ynstee fan twa eigners dy’t fjochtsje om ien adapter. It barrenloch sil ien proses sjen litte dat it TAP-apparaat net iepenet, wat op in tastimmingsprobleem liket en it net is. Tel de eigners earst.

Wat de tsjinstwrapper eins start

It yngongspunt fan ’e tsjinst is in lytse wrapper dy’t syn eigen bewarre parameters lêst en dan openvpn.exe start. Wannear’t de kommando rigel yn it barrenloch net oerienkomt mei jo ferwachting, binne dy wearden it ding om te ûndersykjen. It opnij ynstallearjen set se werom nei de standert en ferneatiget it bewiis. Lês se earst.

De wearden libje yn it register ûnder de eigen kaai fan ’e tsjinst, en sc qc lit it binêre paad sjen dat de tsjinstbehearder starte sil. Ferlykje dat paad mei de bewarre konfiguraasje fan ’e wrapper foardat jo ien fan beide bewurkje.

De wrapper ferfange troch in skript dat jo kontrolearje is mear yngeand, mar it foldet de effektive kommando rigel yn ien lêsber bestân. Einigje mei in werstart, lês dan it loch per profyl oant de earste suksesfolle startrigel ferskynt. In tsjinststatus fan rinnend betsjut allinne dat de wrapper net ôfsletten is, wat ek wier is as syn bern daliks stoar.