OpenVPN-service faalt op een profiel dat de GUI opent: vijf controles

Twee launchers openen hetzelfde profiel op één machine, en alleen de GUI maakt verbinding. Het bestand is intact en het installatieprogramma is waarschijnlijk in orde; wat verschilt is de context die elke launcher aan openvpn.exe geeft. Werkmap, accountidentiteit en bestandsattributen reizen allemaal mee met die context. Controleer ze in die volgorde en stop bij de eerste die de fout verklaart.

Bevestig welke launcher faalt

Begin met het bewijzen van de splitsing. Als de GUI verbinding maakt en de service niet, met hetzelfde profielpad, is het bestand voor iemand leesbaar en wordt de vraag wie het leest en van waar. Als beide falen, is het profiel kapot en geldt niets hiervan. Noteer de servicenaam en het exacte profiel dat geladen moest worden.

Een service die naar zijn eigen autostartmap wijst, laadt mogelijk niet het bestand dat u in een editor hebt openstaan. Vergelijk het pad in de serviceconfiguratie met het pad in de GUI, teken voor teken, want een mapnaam aan het eind of een andere stationsletter is genoeg om u naar de verkeerde tak te sturen.

Waar relatieve paden worden opgelost

Een profiel dat ca.crt of een hulpscript alleen bij naam noemt, vraagt om een zoekactie relatief aan waar het proces zich bevindt. De GUI start in de configuratiemap, dus die namen worden opgelost. Een service die door de servicemanager wordt gestart heeft zo’n startpunt niet, en de zoekactie mislukt voordat er een certificaat wordt gelezen. Daarom werkt hetzelfde profiel in de ene launcher wel en in de andere niet.

Geef de wrapper een map om in te starten, of maak elke verwijzing absoluut. De context van de GUI op een opdrachtregel nabootsen ziet er zo uit:

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

Meer uitvoerigheid op die opdracht toont het exacte pad dat is geprobeerd. Doe dat voordat u machtigingen wijzigt, want een ontbrekend bestand en een geweigerde leesactie vragen om verschillende oplossingen. Het standaardlogboek onderscheidt ze niet. Eén extra vlag bespaart een uur gissen.

Wanneer de service-identiteit niet kan lezen

Een service draait als systeemidentiteit, niet als u. Een ACL die uw gebruiker volledige controle geeft en niemand anders faalt daar, terwijl hij in uw sessie perfect werkt. Een profiel op een gekoppelde schijf of een geverifieerde share faalt om dezelfde reden. Bevestig de machtigingen van het bestand voordat u naar iets anders kijkt.

De controle is een leesactie van de effectieve machtigingen plus een leesactie die als de service-identiteit wordt geprobeerd. Voer het eerste deel uit vanaf een verhoogde opdrachtprompt:

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

Probeer daarna dezelfde leesactie als de service-identiteit, bijvoorbeeld met psexec -s -i van Sysinternals, en kijk of het bestand opent. Zo niet, dan helpt geen enkele padcorrectie. Corrigeer de ACL of verplaats het profiel naar een locatie die de service-identiteit kan lezen.

Bestandsversleuteling is het tweede, zeldzamere geval. Een profiel met het attribuut Encrypting File System wordt transparant ontsleuteld voor de gebruiker die het heeft versleuteld en blijft onleesbaar voor een serviceaccount. Daarom opent hetzelfde bestand in uw editor en niet onder de service.

Het attribuut is zichtbaar vanaf een verhoogde opdrachtprompt, en het controleren ervan opent het profiel niet. Voer beide opdrachten uit en lees de uitvoer:

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

Het attribuut wissen maakt het bestand leesbaar, en het verwijdert ook de bescherming die het droeg. Als het profiel beschermd moet blijven, plaats het geheime materiaal dan waar de service-identiteit een uitdrukkelijke toekenning heeft in plaats van te vertrouwen op versleuteling per gebruiker. Zo’n regeling overleeft een wachtwoordwijziging, en ze maakt de toegang controleerbaar door iemand anders dan de persoon die het bestand heeft versleuteld.

Bepalen wie de tunnel bezit

De GUI kan om een wachtwoord vragen en kan een certificaat uit uw gebruikersopslag lezen. De service kan geen van beide, dus een profiel dat van een interactief geheim afhangt, start nooit onbeheerd, hoe de paden ook worden gecorrigeerd. Die grens is een ontwerpbeslissing, geen defect om te omzeilen. Kies één eigenaar voordat u iets anders wijzigt.

Als de tunnel vóór het aanmelden omhoog moet, geef de service dan een onbeheerde bron van inloggegevens en zijn eigen kopie van het profiel. Als hij alleen hoeft te bestaan terwijl u aan het bureau zit, houd hem dan in de GUI en verwijder de servicekopie. Beide tegelijk is de configuratie die adapterconflicten en dubbele routes oplevert.

Dat conflict wordt meestal gediagnosticeerd als een configuratiefout in plaats van als twee eigenaren die om één adapter vechten. Het gebeurtenislogboek toont één proces dat het TAP-apparaat niet kan openen, wat op een machtigingsprobleem lijkt en het niet is. Tel eerst de eigenaren.

Wat de servicewrapper werkelijk start

Het toegangspunt van de service is een kleine wrapper die zijn eigen opgeslagen parameters leest en dan openvpn.exe start. Wanneer de opdrachtregel in het gebeurtenislogboek niet overeenkomt met uw verwachting, zijn die waarden het ding om te onderzoeken. Herinstallatie zet ze terug naar de standaard en vernietigt het bewijs. Lees ze eerst.

De waarden leven in het register onder de eigen sleutel van de service, en sc qc toont het binaire pad dat de servicemanager zal starten. Vergelijk dat pad met de opgeslagen configuratie van de wrapper voordat u een van beide bewerkt.

De wrapper vervangen door een script dat u beheert is ingrijpender, maar het vouwt de effectieve opdrachtregel in één leesbaar bestand. Eindig met een herstart en lees dan het logboek per profiel tot de eerste geslaagde opstartregel verschijnt. Een servicestatus van actief betekent alleen dat de wrapper niet is afgesloten, wat ook geldt wanneer het kind meteen stierf.