OpenVPN-tenesta feilar på ein profil GUI-et opnar: fem kontrollar

To startarar opnar same profil på éin maskin, og berre GUI-et koplar til. Fila er intakt og installasjonsprogrammet er truleg i orden; det som er ulikt, er konteksten kvar startar gjev openvpn.exe. Arbeidskatalog, kontoidentitet og filattributt følgjer alle med den konteksten. Kontroller dei i den rekkjefølgja, og stopp ved den første som forklarar feilen.

Stadfest kva startar som feilar

Byrja med å prova delinga. Viss GUI-et koplar til og tenesta ikkje, med same profilbane, er fila lesbar for nokon, og spørsmålet vert kven som les ho og kvarfrå. Viss begge feilar, er profilen øydelagd, og ingenting av dette gjeld. Skriv ned tenestnamnet og den nøyaktige profilen ho vart bedd om å lasta.

Ei teneste som peikar på sin eigen autostart-katalog lastar kanskje ikkje fila du har open i ein editor. Samanlikn banen i tenestekonfigurasjonen med banen i GUI-et, teikn for teikn, fordi eit mappenamn på slutten eller ein annan stasjonsbokstav er nok til å senda deg ned i feil grein.

Kvar relative banar vert løyste

Ein profil som viser til ca.crt eller eit hjelpeskript ved bart namn, ber om eit oppslag relativt til kvar prosessen held til. GUI-et startar i konfigurasjonsmappa, så dei namna vert løyste. Ei teneste som tenestestyraren startar har ikkje eit slikt utgangspunkt, og oppslaget feilar før noko sertifikat vert lese. Difor verkar same profil i den eine startaren og ikkje i den andre.

Gje innpakkinga ein katalog å starta i, eller gjer kvar referanse absolutt. Å gjenskapa konteksten til GUI-et på ei kommandolinje ser slik ut:

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

Å auka detaljnivået på den kommandoen viser den nøyaktige banen som vart freista. Gjer det før du endrar løyve, fordi ei manglande fil og ei avvist lesing treng ulike rettingar. Standarprotokollen skil dei ikkje. Eitt ekstra flagg sparar ein time med gissing.

Når tenesteidentiteten ikkje kan lesa

Ei teneste køyrer som ein systemidentitet, ikkje som deg. Ein ACL som gjev brukaren din full kontroll og ingen andre, feilar der medan han fungerer perfekt i økta di. Ein profil som vert halden på ein tilordna stasjon eller ei autentisert deling, feilar av same grunn. Stadfest løyva til fila før du ser på noko anna.

Kontrollen er ei lesing av dei effektive løyva pluss ei lesing freista som tenesteidentiteten. Køyr første del frå ei forhøgd kommandolinje:

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

Freist deretter den same lesinga som tenesteidentiteten, til dømes med psexec -s -i frå Sysinternals, og sjå om fila opnar seg. Viss ikkje, hjelper inga baneretting. Rett ACL-en eller flytt profilen til ein stad tenesteidentiteten kan lesa.

Filkryptering er det andre, sjeldnare tilfellet. Ein profil merkt med attributtet Encrypting File System vert dekryptert gjennomsiktig for brukaren som krypterte han, og vert verande uleseleg for ein tenestekonto. Difor opnar same fil i editoren din og ikkje under tenesta.

Attributtet er synleg frå ei forhøgd kommandolinje, og å kontrollera det opnar ikkje profilen. Køyr båe kommandoane og les utdata:

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

Å fjerna attributtet gjer fila lesbar, og det fjernar òg vernet ho bar. Viss profilen må vera verna, legg det hemmelege materialet der tenesteidentiteten har ei uttrykkeleg tildeling, i staden for å stola på kryptering per brukar. Ei slik ordning overlever ei passordendring, og ho gjer tilgangen reviderbar for nokon andre enn personen som krypterte fila.

Å avgjera kven som eig tunnelen

GUI-et kan spørja om eit passord og kan lesa eit sertifikat frå brukarlageret ditt. Tenesta kan ingen av delane, så ein profil som er avhengig av ein interaktiv hemmelegheit startar aldri utan tilsyn, uansett korleis banane vert retta. Den grensa er eit designval, ikkje ei mangel som skal omgåast. Vel éin eigar før du endrar noko anna.

Viss tunnelen må vera oppe før innlogging, gje tenesta ei kjelde til uovervaka påloggingsdata og si eiga kopi av profilen. Viss han berre treng å finnast medan du er ved skrivebordet, hald han i GUI-et og fjern tenestekopien. Begge samstundes er konfigurasjonen som gjev adapterkonfliktar og dupliserte ruter.

Den konflikten vert vanlegvis diagnostisert som ein konfigurasjonsfeil i staden for som to eigarar som slåst om éin adapter. Hendingsloggen vil visa éin prosess som ikkje klarar å opna TAP-eininga, noko som ser ut som eit løyveproblem og ikkje er det. Tel eigarane først.

Kva tenesteinnpakkinga faktisk startar

Inngangspunktet til tenesta er ei lita innpakking som les sine eigne lagra parametrar og deretter startar openvpn.exe. Når kommandolinja i hendingsloggen ikkje stemmer med forventninga di, er det dei verdiane som skal granskast. Reinstallasjon set dei tilbake til standard og øydelegg prova. Les dei først.

Verdiane bur i registeret under tenesta sin eigen nøkkel, og sc qc viser den binære banen tenestestyraren vil starta. Samanlikn den banen med den lagra konfigurasjonen til innpakkinga før du redigerer nokon av dei.

Å erstatta innpakkinga med eit skript du kontrollerer er meir inngripande, men det legg den effektive kommandolinja saman i éi lesbar fil. Avslutt med ein omstart, og les deretter loggen per profil til den første vellukka oppstartslinja viser seg. Ein tenestestatus på køyrande tyder berre at innpakkinga ikkje har avslutta, noko som òg er sant når barnet døydde med ein gong.