OpenVPN-diens misluk op ’n profiel wat die GUI oopmaak: vyf kontroles

Twee lanseerders open dieselfde profiel op een masjien, en net die GUI maak verbinding. Die lêer is ongeskonde en die installeerder is waarskynlik in orde; wat verskil, is die konteks wat elke lanseerder aan openvpn.exe gee. Werkmap, rekeningidentiteit en lêerattribute reis almal saam met daardie konteks. Kontroleer hulle in daardie volgorde en stop by die eerste een wat die fout verklaar.

Bevestig watter lanseerder misluk

Begin deur die skeiding te bewys. As die GUI verbind en die diens nie, met dieselfde profielpad, dan is die lêer vir iemand leesbaar en die vraag word wie dit lees en van waar. As albei misluk, is die profiel stukkend en geld niks hiervan nie. Skryf die diensnaam neer en die presiese profiel wat dit gevra is om te laai.

’n Diens wat na sy eie outostart-gids wys, laai dalk nie die lêer wat jy in ’n redigeerder oop het nie. Vergelyk die pad in die dienskonfigurasie met die pad in die GUI, karakter vir karakter, want ’n bykomende gidsnaam of ’n ander skyfletter is genoeg om jou op die verkeerde tak te stuur.

Waar relatiewe paaie oplos

’n Profiel wat ca.crt of ’n hulpskrip by kaal naam verwys, vra ’n soektog relatief tot waar die proses ook al is. Die GUI begin in die konfigurasiegids, so daardie name los op. ’n Diens wat deur die diensbestuurder begin is, het nie so ’n beginpunt nie, en die soektog misluk voordat enige sertifikaat gelees word. Dit is waarom dieselfde profiel in een lanseerder werk en nie in die ander nie.

Gee die wapper ’n gids om in te begin, of maak elke verwysing absoluut. Om die GUI se konteks op ’n opdragreël te reproduseer, lyk so:

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

Om die breedsprakigheid op daardie opdrag te verhoog, wys die presiese pad wat probeer is. Doen dit voordat jy toestemmings verander, want ’n ontbrekende lêer en ’n geweierde lees het verskillende regstellings nodig. Die versteklog onderskei hulle nie. Een ekstra vlag spaar ’n uur se raai.

Wanneer die diensidentiteit nie kan lees nie

’n Diens loop as ’n stelselidentiteit, nie as jy nie. ’n ACL wat jou gebruiker volle beheer gee en niemand anders nie, misluk daar terwyl dit perfek in jou sessie werk. ’n Profiel wat op ’n gekarteerde skyf of ’n gemagtigde deel gehou word, misluk om dieselfde rede. Bevestig die lêer se toestemmings voordat jy na enigiets anders kyk.

Die kontrole is ’n lees van die effektiewe toestemmings plus ’n lees wat as die diensidentiteit probeer word. Voer die eerste deel uit ’n verhoogde opdrag uit:

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

Probeer dan dieselfde lees as die diensidentiteit, byvoorbeeld met psexec -s -i van Sysinternals, en kyk of die lêer oopmaak. As dit nie doen nie, sal geen padregstelling help nie. Regstel die ACL of skuif die profiel na ’n plek waar die diensidentiteit kan lees.

Lêervlak-versleuteling is die tweede, skaarser geval. ’n Profiel gemerk met die Encrypting File System-attribute ontsleutel deursigtig vir die gebruiker wat dit versleutel het en bly onleesbaar vir ’n diensrekening. Dit is waarom dieselfde lêer in jou redigeerder oopmaak en nie onder die diens nie.

Die attribute is sigbaar uit ’n verhoogde opdrag, en om dit te kontroleer maak nie die profiel oop nie. Voer albei opdragte uit en lees die uitset:

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

Om die attribute te verwyder maak die lêer leesbaar, en dit verwyder ook die beskerming wat dit gedra het. As die profiel beskerm moet bly, plaas die geheime materiaal waar die diensidentiteit ’n uitdruklike toekenning het in plaas daarvan om op per-gebruiker-versleuteling te staatmaak. Daardie reëling oorleef ’n wagwoordverandering, en dit maak die toegang hersienbaar deur iemand anders as die persoon wat die lêer versleutel het.

Besluit wie die tonnel besit

Die GUI kan om ’n wagwoord vra en kan ’n sertifikaat uit jou gebruikersbewaarplek lees. Die diens kan nie een van die twee nie, so ’n profiel wat van ’n interaktiewe geheim afhang, sal nooit onbewaak begin nie, maak nie saak hoe die paaie reggemaak word nie. Daardie beperking is ’n ontwerpbesluit, nie ’n gebrek om omheen te werk nie. Kies een eienaar voordat jy enigiets anders verander.

As die tonnel voor aanmelding op moet wees, gee die diens ’n onbewaakte geloofsbriewebron en sy eie kopie van die profiel. As dit net hoef te bestaan terwyl jy by die lessenaar is, hou dit in die GUI en verwyder die dienskopie. Albei gelyktydig is die konfigurasie wat adapterkonflikte en duplikaatroetes veroorsaak.

Daardie konflik word gewoonlik as ’n konfigurasiefout gediagnoseer eerder as twee eienaars wat oor een adapter veg. Die gebeurtenislog sal een proses wys wat misluk om die TAP-toestel oop te maak, wat soos ’n toestemmingsprobleem lyk en nie een is nie. Tel die eienaars eerste.

Wat die dienswapper werklik lanseer

Die diens se ingangspunt is ’n klein wapper wat sy eie gestoorde parameters lees en dan openvpn.exe begin. Wanneer die opdragreël in die gebeurtenislog nie met jou verwagting ooreenstem nie, is daardie waardes die ding om te ondersoek. Herinstallasie stel hulle na verstek terug en vernietig die bewyse. Lees hulle eerste.

Die waardes woon in die register onder die diens se eie sleutel, en sc qc wys die binêre pad wat die diensbestuurder sal lanseer. Vergelyk daardie pad met die wapper se gestoorde konfigurasie voordat jy enigeen wysig.

Om die wapper met ’n skrip te vervang wat jy beheer, is meer indringend, maar dit vou die effektiewe opdragreël in een leesbare lêer saam. Eindig met ’n herbegin en lees dan die per-profiel-log totdat die eerste suksesvolle opstartreël verskyn. ’n Diensstatus wat as lopend gerapporteer word, beteken net dat die wapper nie afgesluit het nie, wat ook waar is wanneer sy kind dadelik gesterf het.