OpenVPN-tjänsten misslyckas med en profil som GUI:t öppnar: fem kontroller

Två startare öppnar samma profil på en dator, och bara GUI:t ansluter. Filen är intakt och installationsprogrammet är förmodligen okej; det som skiljer är den kontext varje startare ger openvpn.exe. Arbetskatalog, kontots identitet och filattribut följer alla med den kontexten. Kontrollera dem i den ordningen och stanna vid den första som förklarar felet.

Bekräfta vilken startare som misslyckas

Börja med att bevisa uppdelningen. Om GUI:t ansluter och tjänsten inte gör det med samma profilsökväg, är filen läsbar för någon och frågan blir vem som läser den och varifrån. Om båda misslyckas är profilen trasig och inget av detta gäller. Skriv ner tjänstens namn och den exakta profil den ombads läsa in.

En tjänst som pekar på sin egen autostartkatalog läser kanske inte filen du har öppen i en editor. Jämför sökvägen i tjänstekonfigurationen med sökvägen i GUI:t, tecken för tecken, för ett efterföljande mappnamn eller en annan enhetsbeteckning räcker för att skicka dig in på fel gren.

Var relativa sökvägar löses upp

En profil som refererar till ca.crt eller ett hjälpskript med bara namnet begär en uppslagning relativt var processen råkar befinna sig. GUI:t startar i konfigurationsmappen, så de namnen löses upp. En tjänst som startas av tjänstehanteraren har ingen sådan startpunkt, och uppslagningen misslyckas innan något certifikat läses. Det är därför samma profil fungerar i den ena startaren men inte i den andra.

Ge omslutningen en katalog att starta i, eller gör varje referens absolut. Att återskapa GUI:ts kontext på en kommandorad ser ut så här:

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

Att höja detaljnivån på det kommandot visar den exakta sökväg som försöktes. Gör det innan du ändrar behörigheter, för en saknad fil och en nekad läsning kräver olika åtgärder. Standardloggen skiljer dem inte. En extra flagga sparar en timme av gissningar.

När tjänstens identitet inte kan läsa

En tjänst körs som en systemidentitet, inte som du. En ACL som ger din användare full kontroll och ingen annan misslyckas där medan den fungerar perfekt i din session. En profil som ligger på en mappad enhet eller en autentiserad delning misslyckas av samma skäl. Bekräfta filens behörigheter innan du tittar på något annat.

Kontrollen är en läsning av de effektiva behörigheterna plus en läsning som försöks som tjänstens identitet. Kör den första delen från en förhöjd kommandotolk:

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

Försök sedan med samma läsning som tjänstens identitet, till exempel med psexec -s -i från Sysinternals, och se om filen öppnas. Om den inte gör det hjälper ingen sökvägsändring. Åtgärda ACL:n eller flytta profilen till en plats som tjänstens identitet kan läsa.

Kryptering på filnivå är det andra, ovanligare fallet. En profil märkt med attributet Encrypting File System dekrypteras transparent för användaren som krypterade den och förblir oläsbar för ett tjänstekonto. Det är därför samma fil öppnas i din editor men inte under tjänsten.

Attributet syns från en förhöjd kommandotolk, och att kontrollera det öppnar inte profilen. Kör båda kommandona och läs utdata:

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

Att rensa attributet gör filen läsbar, och det tar också bort det skydd den bar. Om profilen måste förbli skyddad, lägg det hemliga materialet där tjänstens identitet har ett uttryckligt beviljande i stället för att förlita dig på kryptering per användare. Ett sådant arrangemang överlever ett lösenordsbyte och gör åtkomsten granskningsbar för någon annan än personen som krypterade filen.

Att avgöra vem som äger tunneln

GUI:t kan fråga efter ett lösenord och läsa ett certifikat från ditt användarlager. Tjänsten kan inget av dem, så en profil som är beroende av en interaktiv hemlighet kommer aldrig att starta obevakat, hur sökvägarna än fixas. Den gränsen är ett designbeslut, inte en defekt att kringgå. Välj en ägare innan du ändrar något annat.

Om tunneln måste vara uppe före inloggning, ge tjänsten en obevakad källa för autentiseringsuppgifter och en egen kopia av profilen. Om den bara behöver finnas medan du sitter vid skrivbordet, behåll den i GUI:t och ta bort tjänstens kopia. Båda samtidigt är den konfiguration som ger adapterkonflikter och dubbla rutter.

Den konflikten diagnostiseras oftast som ett konfigurationsfel i stället för som två ägare som slåss om en adapter. Händelseloggen visar en process som misslyckas med att öppna TAP-enheten, vilket ser ut som ett behörighetsproblem och inte är det. Räkna ägarna först.

Vad tjänstens omslutning faktiskt startar

Tjänstens startpunkt är en liten omslutning som läser sina egna lagrade parametrar och sedan startar openvpn.exe. När kommandoraden i händelseloggen inte stämmer med din förväntan är det de värdena du ska granska. En ominstallation återställer dem till standard och förstör bevisen. Läs dem först.

Värdena ligger i registret under tjänstens egen nyckel, och sc qc visar den binära sökväg som tjänstehanteraren kommer att starta. Jämför den sökvägen med omslutningens lagrade konfiguration innan du redigerar någon av dem.

Att ersätta omslutningen med ett skript du styr är mer invasivt, men det pressar ihop den effektiva kommandoraden till en läsbar fil. Avsluta med en omstart och läs sedan profilloggen tills den första lyckade startraden dyker upp. Ett tjänstetillstånd som ”igång” betyder bara att omslutningen inte har avslutats, vilket också gäller när dess barn dog direkt.