Il servizio OpenVPN fallisce su un profilo che la GUI apre: cinque controlli

Due launcher aprono lo stesso profilo su una macchina, e solo la GUI si connette. Il file è intatto e l’installer è probabilmente a posto; ciò che differisce è il contesto che ogni launcher dà a openvpn.exe. La directory di lavoro, l’identità dell’account e gli attributi del file viaggiano tutti con quel contesto. Controllali in questo ordine e fermati al primo che spiega l’errore.

Conferma quale launcher fallisce

Inizia dimostrando la separazione. Se la GUI si connette e il servizio no, con lo stesso percorso del profilo, il file è leggibile da qualcuno e la domanda diventa chi lo legge e da dove. Se entrambi falliscono, il profilo è rotto e nulla di questo si applica. Annota il nome del servizio e l’esatto profilo che gli è stato chiesto di caricare.

Un servizio puntato alla propria directory di avvio automatico potrebbe non caricare il file che hai aperto in un editor. Confronta il percorso nella configurazione del servizio con il percorso nella GUI, carattere per carattere, perché un nome di cartella in coda o una lettera di unità diversa basta a mandarti sul ramo sbagliato.

Dove si risolvono i percorsi relativi

Un profilo che fa riferimento a ca.crt o a uno script ausiliario solo per nome chiede una ricerca relativa a dove si trova il processo. La GUI parte nella cartella di configurazione, quindi quei nomi si risolvono. Un servizio avviato dal gestore dei servizi non ha un tale punto di partenza, e la ricerca fallisce prima che venga letto qualsiasi certificato. Ecco perché lo stesso profilo funziona in un launcher e non nell’altro.

Dai al wrapper una directory in cui partire, oppure rendi assoluto ogni riferimento. Riprodurre il contesto della GUI su una riga di comando assomiglia a questo:

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

Aumentare la verbosità di quel comando mostra il percorso esatto che è stato tentato. Fallo prima di cambiare i permessi, perché un file mancante e una lettura negata richiedono correzioni diverse. Il log predefinito non li distingue. Un flag in più risparmia un’ora di congetture.

Quando l’identità del servizio non può leggere

Un servizio viene eseguito come identità di sistema, non come te. Un’ACL che concede al tuo utente il controllo completo e a nessun altro fallisce lì mentre funziona perfettamente nella tua sessione. Un profilo tenuto su un’unità mappata o su una condivisione autenticata fallisce per la stessa ragione. Conferma i permessi del file prima di guardare qualsiasi altra cosa.

Il controllo è una lettura dei permessi effettivi più una lettura tentata come identità del servizio. Esegui la prima parte da un prompt elevato:

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

Poi tenta la stessa lettura come identità del servizio, per esempio con psexec -s -i di Sysinternals, e osserva se il file si apre. Se non si apre, nessuna correzione del percorso aiuterà. Correggi l’ACL o sposta il profilo in una posizione che l’identità del servizio può leggere.

La cifratura a livello di file è il secondo caso, più raro. Un profilo contrassegnato dall’attributo Encrypting File System viene decifrato in modo trasparente per l’utente che lo ha cifrato e resta illeggibile per un account di servizio. Ecco perché lo stesso file si apre nel tuo editor e non sotto il servizio.

L’attributo è visibile da un prompt elevato, e controllarlo non apre il profilo. Esegui entrambi i comandi e leggi l’output:

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

Cancellare l’attributo rende il file leggibile, e rimuove anche la protezione che portava. Se il profilo deve restare protetto, metti il materiale segreto dove l’identità del servizio ha una concessione esplicita invece di affidarti alla cifratura per utente. Una tale disposizione sopravvive a un cambio di password, e rende l’accesso verificabile da qualcuno diverso dalla persona che ha cifrato il file.

Decidere chi possiede il tunnel

La GUI può chiedere una password e può leggere un certificato dal tuo archivio utente. Il servizio non può fare né l’una né l’altra, quindi un profilo che dipende da un segreto interattivo non partirà mai senza sorveglianza, per quanto si correggano i percorsi. Quel limite è una decisione di progettazione, non un difetto da aggirare. Scegli un solo proprietario prima di cambiare qualsiasi altra cosa.

Se il tunnel deve essere attivo prima dell’accesso, dai al servizio una fonte di credenziali senza sorveglianza e una propria copia del profilo. Se deve esistere solo mentre sei alla scrivania, tienilo nella GUI e rimuovi la copia del servizio. Entrambi insieme è la configurazione che produce conflitti di adattatore e rotte duplicate.

Quel conflitto viene di solito diagnosticato come un errore di configurazione invece che come due proprietari che litigano per un adattatore. Il registro eventi mostrerà un processo che non riesce ad aprire il dispositivo TAP, cosa che sembra un problema di permessi e non lo è. Conta prima i proprietari.

Che cosa avvia davvero il wrapper del servizio

Il punto di ingresso del servizio è un piccolo wrapper che legge i propri parametri memorizzati e poi avvia openvpn.exe. Quando la riga di comando nel registro eventi non corrisponde alle tue aspettative, sono quei valori la cosa da ispezionare. Reinstallare li riporta ai valori predefiniti e distrugge le prove. Leggili prima.

I valori vivono nel registro sotto la chiave propria del servizio, e sc qc mostra il percorso del binario che il gestore dei servizi avvierà. Confronta quel percorso con la configurazione memorizzata del wrapper prima di modificare l’uno o l’altro.

Sostituire il wrapper con uno script che controlli è più invasivo, ma ripiega la riga di comando effettiva in un unico file leggibile. Termina con un riavvio, poi leggi il log per profilo finché non compare la prima riga di avvio riuscita. Uno stato del servizio in esecuzione significa solo che il wrapper non è uscito, il che è vero anche quando il suo figlio è morto subito.