Serviciul OpenVPN eșuează pe un profil pe care GUI îl deschide: cinci verificări

Două lansatoare deschid același profil pe o singură mașină, și doar GUI se conectează. Fișierul este intact, iar instalatorul este probabil în regulă; ceea ce diferă este contextul pe care fiecare lansator îl dă lui openvpn.exe. Directorul de lucru, identitatea contului și atributele fișierului călătoresc toate cu acel context. Verificați-le în această ordine și opriți-vă la primul care explică eroarea.

Confirmați care lansator eșuează

Începeți prin a dovedi separarea. Dacă GUI se conectează și serviciul nu, cu aceeași cale a profilului, fișierul este lizibil pentru cineva și întrebarea devine cine îl citește și de unde. Dacă ambele eșuează, profilul este stricat și nimic din toate acestea nu se aplică. Notați numele serviciului și profilul exact pe care i s-a cerut să îl încarce.

Un serviciu îndreptat spre propriul director de pornire automată poate să nu încarce fișierul pe care îl aveți deschis într-un editor. Comparați calea din configurația serviciului cu calea din GUI, caracter cu caracter, pentru că un nume de folder la final sau o altă literă de unitate este suficient pentru a vă trimite pe ramura greșită.

Unde se rezolvă căile relative

Un profil care face referire la ca.crt sau la un script auxiliar doar după nume cere o căutare relativă la locul unde se află procesul. GUI pornește în folderul de configurare, așa că acele nume se rezolvă. Un serviciu pornit de managerul de servicii nu are un astfel de punct de plecare, iar căutarea eșuează înainte de a fi citit vreun certificat. De aceea același profil funcționează într-un lansator și nu în celălalt.

Dați wrapperului un director în care să pornească, sau faceți absolută fiecare referință. Reproducerea contextului GUI pe o linie de comandă arată astfel:

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

Creșterea verbositatii la acea comandă arată calea exactă care a fost încercată. Faceți asta înainte de a schimba permisiunile, pentru că un fișier lipsă și o citire refuzată necesită corecturi diferite. Jurnalul implicit nu le distinge. Un steag suplimentar economisește o oră de presupuneri.

Când identitatea serviciului nu poate citi

Un serviciu rulează ca identitate de sistem, nu ca dumneavoastră. Un ACL care îi dă utilizatorului dumneavoastră control complet și nimănui altcuiva eșuează acolo, deși funcționează perfect în sesiunea dumneavoastră. Un profil ținut pe o unitate mapată sau pe o partajare autentificată eșuează din același motiv. Confirmați permisiunile fișierului înainte de a vă uita la orice altceva.

Verificarea este o citire a permisiunilor efective plus o citire încercată ca identitatea serviciului. Rulați prima parte dintr-un prompt ridicat:

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

Apoi încercați aceeași citire ca identitatea serviciului, de exemplu cu psexec -s -i de la Sysinternals, și urmăriți dacă fișierul se deschide. Dacă nu, nicio corectură de cale nu va ajuta. Corectați ACL-ul sau mutați profilul într-o locație pe care identitatea serviciului o poate citi.

Criptarea la nivel de fișier este al doilea caz, mai rar. Un profil marcat cu atributul Encrypting File System este decriptat transparent pentru utilizatorul care l-a criptat și rămâne ilizibil pentru un cont de serviciu. De aceea același fișier se deschide în editorul dumneavoastră și nu sub serviciu.

Atributul este vizibil dintr-un prompt ridicat, iar verificarea lui nu deschide profilul. Rulați ambele comenzi și citiți ieșirea:

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

Ștergerea atributului face fișierul lizibil și elimină și protecția pe care o purta. Dacă profilul trebuie să rămână protejat, puneți materialul secret acolo unde identitatea serviciului are o concesiune explicită, în loc să vă bazați pe criptarea pe utilizator. O astfel de aranjare supraviețuiește unei schimbări de parolă și face accesul verificabil de către altcineva decât persoana care a criptat fișierul.

A decide cine deține tunelul

GUI poate cere o parolă și poate citi un certificat din magazinul dumneavoastră de utilizator. Serviciul nu poate nici una, nici alta, așa că un profil care depinde de un secret interactiv nu va porni niciodată nesupravegheat, oricum ar fi corectate căile. Această limită este o decizie de proiectare, nu un defect de ocolit. Alegeți un singur proprietar înainte de a schimba orice altceva.

Dacă tunelul trebuie să fie activ înainte de autentificare, dați serviciului o sursă de acreditări fără supraveghere și propria copie a profilului. Dacă trebuie să existe doar cât timp sunteți la birou, păstrați-l în GUI și eliminați copia serviciului. Ambele simultan este configurația care produce conflicte de adaptor și rute duplicate.

Acest conflict este de obicei diagnosticat ca o eroare de configurare, nu ca doi proprietari care se luptă pentru un adaptor. Jurnalul de evenimente va arăta un proces care nu reușește să deschidă dispozitivul TAP, ceea ce pare o problemă de permisiuni și nu este. Numărați mai întâi proprietarii.

Ce lansează de fapt wrapperul serviciului

Punctul de intrare al serviciului este un wrapper mic care își citește propriii parametri stocați și apoi lansează openvpn.exe. Când linia de comandă din jurnalul de evenimente nu corespunde așteptării dumneavoastră, acele valori sunt lucrul de inspectat. Reinstalarea le readuce la valorile implicite și distruge dovezile. Citiți-le mai întâi.

Valorile trăiesc în registru sub cheia proprie a serviciului, iar sc qc arată calea binarului pe care managerul de servicii îl va lansa. Comparați acea cale cu configurația stocată a wrapperului înainte de a edita oricare dintre ele.

Înlocuirea wrapperului cu un script pe care îl controlați este mai invazivă, dar pliază linia de comandă efectivă într-un singur fișier lizibil. Terminați cu o repornire, apoi citiți jurnalul pe profil până când apare prima linie de pornire reușită. O stare de serviciu în execuție înseamnă doar că wrapperul nu a ieșit, ceea ce este valabil și când copilul său a murit imediat.