Perché OpenVPN parte all'accesso ma non all'avvio di Windows?

I tunnel che compaiono solo dopo che qualcuno ha effettuato l'accesso sono di solito avviati dalla sessione di quella persona, non dal servizio automatico. Il colpevole abituale è una scorciatoia di avvio che lancia openvpn-gui.exe, e non è un'installazione rotta. La scorciatoia avvia un'applicazione desktop all'interno di una sessione utente, con il profilo di quell'utente, i suoi archivi di certificati e la sua capacità di rispondere a una richiesta. Nulla di ciò rende la connessione indipendente da un umano che ha effettuato l'accesso, ed è esattamente ciò che richiede un tunnel prima dell'accesso.

Il sintomo di solito ha tre cause

Tre schemi sembrano uguali dall'esterno e hanno correzioni diverse. Il primo è un proprietario di esecuzione che è una sessione utente invece del servizio, cioè il caso della scorciatoia di avvio. Il secondo è un profilo che risiede dove il servizio non guarda, così il servizio parte, non trova nulla ed esce in modo pulito. Il terzo è un profilo che il servizio trova e avvia, ma le cui credenziali richiedono un'interazione che nessun servizio può fornire.

Stabilire quale si applica richiede due letture: cosa è configurato per eseguire il servizio e quali file può vedere. Entrambe sono un comando ciascuna, e nessuna disturba una connessione in corso.

Cosa legge davvero il servizio automatico

Il servizio automatico di Community è un involucro che analizza la sua directory di avvio automatico configurata, normalmente config-auto sotto l'installazione, e lancia un processo OpenVPN per ogni profilo corrispondente che trova. Un profilo visibile nel menu GUI di un utente risiede invece sotto il profilo roaming di quell'utente, in una directory che l'account del servizio non legge. La guida al servizio di Windows descrive questa scoperta, e vale la pena leggerla prima di copiare qualsiasi cosa, perché la directory di destinazione è una proprietà dell'installazione e non una convenzione fissa. Copiare un file nella cartella del GUI non cambia quindi nulla per il servizio, e copiarlo in ogni cartella chiamata config crea duplicati invece di una correzione.

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'

L'ultimo comando elenca ciò che l'involucro vedrà davvero, che è il modo più rapido per confermare che un profilo è nel posto sbagliato. La seconda riga mostra anche l'account con cui viene eseguito il servizio, e quell'account decide quali percorsi di file e archivi di certificati sono accessibili.

Perché un accesso desktop funziona e un avvio all'accensione no

Il successo sul desktop può nascondere a lungo una dipendenza dall'input. Un GUI può raccogliere una passphrase di chiave, una password di account o un secondo fattore in una finestra di dialogo, perché viene eseguito in una sessione interattiva con un desktop visibile. Un servizio viene eseguito in una sessione senza desktop, quindi una richiesta di input non ha dove apparire, e la connessione fallisce dopo un timeout che non assomiglia affatto a un problema di credenziali.

L'accesso ai file segue la stessa regola. Una chiave privata memorizzata sotto il profilo dell'utente, o un certificato nell'archivio personale dell'utente, non è disponibile per un servizio eseguito come la macchina. Confrontate percorsi assoluti, autorizzazioni e la scelta del certificato che ogni parte effettua invece di supporre che lo stesso file di profilo implichi lo stesso ambiente.

Un'attività pianificata impostata per l'esecuzione indipendentemente dall'accesso di un utente eredita un vincolo simile. Può avviare con successo l'eseguibile del GUI e produrre comunque un processo che non ottiene mai credenziali, quindi la presenza di un processo nel gestore attività non è prova di un tunnel funzionante.

Scegliete un solo proprietario e testate il ciclo di vita reale

Per una connessione che appartiene a una persona che ha effettuato l'accesso, usate l'avvio automatico supportato del GUI e lasciate fuori il servizio. Per un tunnel che deve esistere prima che qualcuno effettui l'accesso, configurate il servizio, collocate il profilo dove l'involucro lo legge e usate un meccanismo di credenziali non presidiato supportato, come una chiave senza passphrase interattiva o un file di credenziali documentato.

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

Testate il ciclo di vita che conta: un riavvio senza che nessuno effettui l'accesso, poi una riconnessione dopo un cambio di rete. Mantenete un solo proprietario per la connessione, perché due meccanismi di avvio concorrenti producono di solito due istanze che si contendono le stesse route e la stessa sessione server, cosa più difficile da diagnosticare di qualsiasi meccanismo da solo.