OpenVPN start ved pålogging, men ikkje ved oppstart på Windows?

Tunnelar som berre dukkar opp etter at nokon loggar på, vert vanlegvis starta av økta til den personen, ikkje av den automatiske tenesta. Den vanlege årsaka er ei oppstartsnarvei som startar openvpn-gui.exe, og det er ikkje ein øydelagd installasjon. Snarvegen startar eit skrivebordsprogram inne i ei brukarøkt, med profilen til den brukaren, sertifikatlagra til den brukaren og evna til den brukaren til å svare på ein førespurnad. Ingenting ved han gjer tilkoplinga uavhengig av eit menneske som er logga på, og det er nettopp det ein tunnel før pålogging krev.

Symptomet har vanlegvis tre årsaker

Tre mønster ser like ut frå utsida og har ulike løysingar. Det første er ein utføringseigar som er ei brukarøkt i staden for tenesta, altså tilfellet med oppstartsnarvegen. Det andre er ein profil som ligg der tenesta ikkje ser, slik at tenesta startar, ikkje finn noko og avsluttar reint. Det tredje er ein profil som tenesta finn og startar, men der påloggingsinformasjonen krev ein interaksjon som ingen teneste kan levere.

Å finne ut kva tilfelle som gjeld krev to lesingar: kva tenesta er konfigurert til å køyre, og kva filer ho kan sjå. Båe er éin kommando kvar, og ingen av dei forstyrrar ei tilkopling som køyrer.

Kva den automatiske tenesta faktisk les

Den automatiske Community-tenesta er ei innpakning som skannar den konfigurerte autostart-katalogen, vanlegvis config-auto under installasjonen, og startar ein OpenVPN-prosess for kvar samsvarande profil ho finn. Ein profil som er synleg i GUI-menyen til ein brukar ligg i staden under roamingprofilen til den brukaren, i ein katalog som tenestekontoen ikkje les. Windows-tenesteguiden skildrar den oppdaginga, og han er verdt å lese før du kopierer noko, fordi målkatalogen er ein eigenskap ved installasjonen og ikkje ein fast konvensjon. Difor endrar det ingenting for tenesta å kopiere ei fil inn i GUI-mappa, og å kopiere ho inn i kvar mappe som heiter config lagar duplikat i staden for ei løysing.

Get-Service OpenVPNService | Select-Object Status, StartType
Get-CimInstance Win32_Service | Where-Object Name -eq 'OpenVPNService' | Select-Object PathName, StartName
gci 'C:\Program Files\OpenVPN\config-auto'

Den siste kommandoen listar opp kva innpakninga faktisk vil sjå, som er den raskaste måten å stadfeste at ein profil ligg på feil stad. Den andre linja viser òg kontoen tenesta køyrer som, og den kontoen avgjer kva filbanar og sertifikatlager som i det heile er tilgjengelege.

Kvifor pålogging på skrivebordet verkar og oppstart ved boot ikkje gjer det

Suksess på skrivebordet kan skjule ein inndataavhengigheit lenge. Eit GUI kan samle inn ein nøkkelpassfrase, eit kontopassord eller ein andre faktor i ein dialog, fordi det køyrer i ei interaktiv økt med eit synleg skrivebord. Ei teneste køyrer i ei økt utan skrivebord, så ein førespurnad om inndata har ingen stad å visast, og tilkoplinga feilar etter ein tidsavbrot som slett ikkje liknar eit påloggingsproblem.

Filtilgang følgjer same regel. Ein privat nøkkel som er lagra under brukarprofilen, eller eit sertifikat i den personlege lagringa til brukaren, er ikkje tilgjengeleg for ei teneste som køyrer som maskina. Samanlikn absolutte banar, løyve og sertifikatvalet kvar side gjer i staden for å anta at same profilfil betyr same miljø.

Ein planlagd oppgåve som er sett til å køyre uansett om ein brukar er logga på, arvar ei liknande avgrensing. Ho kan starte GUI-køyrbarfila med hell og likevel produsere ein prosess som aldri får påloggingsinformasjon, så tilstadeveret av ein prosess i oppgåvehandsamaren er ikkje prov på ein fungerande tunnel.

Vel éin eigar og test den verkelege livssyklusen

For ei tilkopling som høyrer til ein pålogga person, bruk den støtta autostart-åtferda til GUI-et og hald tenesta utanfor. For ein tunnel som må finnast før nokon loggar på, konfigurer tenesta, plasser profilen der innpakninga les han, og bruk ein støtta uovervaka påloggingsmekanisme som ein nøkkel utan interaktiv passfrase eller ei dokumentert påloggingsfil.

Get-Content 'C:\Program Files\OpenVPN\log\openvpn.log' -Tail 40
Get-WinEvent -LogName Application -MaxEvents 20 | Where-Object ProviderName -like '*OpenVPN*'

Test livssyklusen som betyr noko: ein omstart der ingen loggar på, deretter ei ny tilkopling etter ei nettverksendring. Hald éin eigar for tilkoplinga, fordi to konkurrerande oppstartsmekanismar vanlegvis produserer to førekomstar som kjempar om dei same rutene og den same tenarsesjonen, noko som er vanskelegare å diagnostisere enn kvar mekanisme åleine.