OpenVPN-tjenesten feiler på en profil GUI-et åpner: fem kontroller

To startere åpner samme profil på én maskin, og bare GUI-et kobler til. Filen er intakt og installasjonsprogrammet er sannsynligvis i orden; det som er forskjellig, er konteksten hver starter gir openvpn.exe. Arbeidskatalog, kontoidentitet og filattributter følger alle med den konteksten. Kontroller dem i den rekkefølgen, og stopp ved den første som forklarer feilen.

Bekreft hvilken starter som feiler

Begynn med å bevise delingen. Hvis GUI-et kobler til og tjenesten ikke, med samme profilbane, er filen lesbar for noen, og spørsmålet blir hvem som leser den og hvorfra. Hvis begge feiler, er profilen ødelagt, og ingenting av dette gjelder. Skriv ned tjenestnavnet og den nøyaktige profilen den ble bedt om å laste.

En tjeneste som peker på sin egen autostart-katalog, laster kanskje ikke filen du har åpen i en editor. Sammenlign banen i tjenestekonfigurasjonen med banen i GUI-et, tegn for tegn, fordi et mappenavn på slutten eller en annen stasjonsbokstav er nok til å sende deg ned i feil gren.

Hvor relative baner løses opp

En profil som refererer til ca.crt eller et hjelpeskript ved bart navn, ber om et oppslag relativt til hvor prosessen befinner seg. GUI-et starter i konfigurasjonsmappen, så de navnene løses opp. En tjeneste startet av tjenestebehandleren har ikke et slikt utgangspunkt, og oppslaget feiler før noe sertifikat leses. Derfor virker samme profil i den ene starteren og ikke i den andre.

Gi innpakningen en katalog å starte i, eller gjør hver referanse absolutt. Å gjenskape GUI-ets kontekst på en kommandolinje ser slik ut:

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

Å øke detaljnivået på den kommandoen viser den nøyaktige banen som ble forsøkt. Gjør det før du endrer tillatelser, fordi en manglende fil og en avvist lesing trenger forskjellige rettelser. Standardloggen skiller dem ikke. Én ekstra bryter sparer en time med gjetting.

Når tjenesteidentiteten ikke kan lese

En tjeneste kjører som en systemidentitet, ikke som deg. En ACL som gir brukeren din full kontroll og ingen andre, feiler der mens den fungerer perfekt i økten din. En profil som holdes på en tilordnet stasjon eller en autentisert deling, feiler av samme grunn. Bekreft filens tillatelser før du ser på noe annet.

Kontrollen er en lesing av de effektive tillatelsene pluss en lesing forsøkt som tjenesteidentiteten. Kjør første del fra en forhøyet kommandoprompt:

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

Forsøk deretter den samme lesingen som tjenesteidentiteten, for eksempel med psexec -s -i fra Sysinternals, og se om filen åpnes. Hvis ikke, hjelper ingen banerettelse. Rett ACL-en eller flytt profilen til et sted tjenesteidentiteten kan lese.

Filkryptering er det andre, sjeldnere tilfellet. En profil merket med attributtet Encrypting File System dekrypteres gjennomsiktig for brukeren som krypterte den, og forblir uleselig for en tjenestekonto. Derfor åpnes samme fil i editoren din og ikke under tjenesten.

Attributtet er synlig fra en forhøyet kommandoprompt, og å kontrollere det åpner ikke profilen. Kjør begge kommandoene og les utdataene:

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

Å fjerne attributtet gjør filen lesbar, og det fjerner også beskyttelsen den bar. Hvis profilen må forbli beskyttet, legg det hemmelige materialet der tjenesteidentiteten har en uttrykkelig tildeling, i stedet for å stole på kryptering per bruker. En slik ordning overlever en passordendring, og den gjør tilgangen reviderbar for noen andre enn personen som krypterte filen.

Å avgjøre hvem som eier tunnelen

GUI-et kan spørre om et passord og kan lese et sertifikat fra brukerlageret ditt. Tjenesten kan ingen av delene, så en profil som avhenger av en interaktiv hemmelighet starter aldri uten tilsyn, uansett hvordan banene rettes. Den grensen er et designvalg, ikke en mangel som skal omgås. Velg én eier før du endrer noe annet.

Hvis tunnelen må være oppe før innlogging, gi tjenesten en kilde til uovervåkede påloggingsdata og sin egen kopi av profilen. Hvis den bare trenger å eksistere mens du er ved skrivebordet, hold den i GUI-et og fjern tjenestekopien. Begge samtidig er konfigurasjonen som gir adapterkonflikter og dupliserte ruter.

Den konflikten blir vanligvis diagnostisert som en konfigurasjonsfeil i stedet for som to eiere som slåss om én adapter. Hendelsesloggen vil vise én prosess som ikke klarer å åpne TAP-enheten, noe som ser ut som et tillatelsesproblem og ikke er det. Tell eierne først.

Hva tjenesteinnpakningen faktisk starter

Tjenestens inngangspunkt er en liten innpakning som leser sine egne lagrede parametere og deretter starter openvpn.exe. Når kommandolinjen i hendelsesloggen ikke stemmer med forventningen din, er det de verdiene som skal undersøkes. Reinstallasjon tilbakestiller dem til standard og ødelegger bevisene. Les dem først.

Verdiene bor i registeret under tjenestens egen nøkkel, og sc qc viser den binære banen tjenestebehandleren vil starte. Sammenlign den banen med innpakningens lagrede konfigurasjon før du redigerer noen av dem.

Å erstatte innpakningen med et skript du kontrollerer er mer inngripende, men det folder den effektive kommandolinjen sammen i én lesbar fil. Avslutt med en omstart, og les deretter loggen per profil til den første vellykkede oppstartslinjen vises. En tjenestestatus på kjører betyr bare at innpakningen ikke har avsluttet, noe som også er sant når barnet døde umiddelbart.