RRAS parte prima che il tunnel OpenVPN sia pronto all’avvio

Il server si riavvia, OpenVPN parte e RRAS si avvia mentre l’adattatore o la rotta da cui dipende mancano ancora. Riavviare RRAS a mano un minuto dopo risolve, il che fa sembrare il problema risolto e nasconde quello vero. Qui si confondono due condizioni diverse: il servizio prerequisito è in esecuzione e la risorsa di rete che RRAS richiede davvero è diventata utilizzabile. Una dipendenza di servizio Windows può esprimere la prima condizione e mai la seconda, quindi aggiungerne una senza definire la risorsa vi dà un avvio più ordinato in apparenza e lo stesso guasto.

Come si presenta il sintomo a un avvio a freddo

L’indizio è la differenza tra un avvio a freddo e un riavvio. A un avvio a freddo RRAS dichiara di essere in esecuzione mentre l’adattatore del tunnel è assente, la rotta manca o l’indirizzo del peer non è ancora risolto. Un riavvio manuale poi riesce perché a quel punto la risorsa esiste, e il servizio si limita a rileggere un mondo che un minuto prima non poteva vedere. Il registro del servizio mostrerà un avvio pulito in entrambi i casi, ed è per questo che il visualizzatore eventi da solo raramente spiega la cosa.

Catturate entrambi gli stati prima di cambiare qualcosa: cosa dichiara RRAS all’avvio e cosa esiste nel momento in cui il riavvio manuale riesce. Se queste due osservazioni sono identiche, l’ordine di avvio non è la vostra spiegazione e una dipendenza non aiuterà. Il confronto costa dieci minuti e risparmia una settimana di congetture.

Una dipendenza aggiunta sulla base di «funziona dopo un riavvio» ritarda solo lo stesso guasto del tempo che il servizio prerequisito impiega a dichiarare RUNNING. Rende anche l’avvio più difficile da ragionare, perché il vincolo di ordine ora sembra una spiegazione. Chiedetevi quale oggetto garantisce la dipendenza e se quell’oggetto è quello che RRAS non poteva vedere.

Nominate la risorsa, non solo il servizio

Scrivete la cosa concreta che manca. Può essere un adattatore di tunnel con un indirizzo, una rotta verso una sottorete peer, una risposta DNS o un certificato ancora in fase di provisioning. «Il servizio VPN è in esecuzione» non è una descrizione di risorsa, e nemmeno un’icona verde in un client. Finché non sapete nominare l’oggetto e un comando che lo mostri, non avete definito la condizione che state cercando di attendere.

Stabilite anche come viene avviata questa istanza di OpenVPN. Un tunnel gestito da GUI e un tunnel gestito da servizio hanno cicli di vita di avvio diversi, e il nome del servizio deve venire dalla macchina davanti a voi, non da un esempio scritto per un altro programma di installazione. Elencate i candidati invece di fidarvi di un nome ricordato.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Leggete la catena di dipendenze prima di aggiungervi qualcosa

Il Gestore controllo servizi segnala stati come START_PENDING e RUNNING, e la SERVICE_STATUS reference definisce esattamente cosa significa ogni campo. Nessuno di questi stati promette che un peer, un nome DNS o un’applicazione a valle siano raggiungibili. Questo divario è l’intera ragione per cui questo guasto sopravvive a una dipendenza configurata correttamente.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

La riga DEPENDENCIES di sc.exe qc è l’elenco che dovete conservare, perché sc.exe config RemoteAccess depend= sostituisce l’intero elenco invece di aggiungervi. Lasciar cadere un prerequisito non correlato mentre si aggiunge un servizio VPN crea un secondo guasto che compare a un altro avvio, ed è molto più difficile da diagnosticare dell’originale. Copiate l’elenco esistente nel vostro registro delle modifiche prima di toccarlo.

Le dipendenze cambiano anche il comportamento allo spegnimento, perché fermare un prerequisito ferma i servizi che ne dipendono. Controllate cosa succede durante la manutenzione prima di collegare RRAS a qualcosa che si riavvia spesso.

Subordinate il riavvio a una condizione, non a un timer

Un’attesa fissa presuppone che il tunnel sia sempre pronto entro quella finestra, ed è esattamente l’ipotesi che fallisce all’avvio in cui un certificato è lento o un collegamento è caduto. Controllate la risorsa stessa, con una scadenza, e lasciate che il controllo decida se un riavvio sia necessario.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

Un’attività pianificata all’avvio che esegue questi controlli e riavvia RRAS solo quando l’adattatore o la rotta mancano ancora è limitata, verificabile e facile da rimuovere. L’alternativa, riavviare RRAS a ogni riconnessione, interrompe sessioni sane e trasforma un collegamento instabile in un ciclo di riavvii. Quel ciclo è peggio del guasto originale, perché ora colpisce utenti che stavano bene.

Date al controllo un’attesa massima che corrisponda al tempo che il tunnel impiega ragionevolmente sul vostro hardware, e fate terminare l’attività con uno stato diverso da zero quando rinuncia. Un’attività silenziosa che smette semplicemente di provare è indistinguibile da una riuscita.

Registrate la transizione così che il prossimo avvio si spieghi da solo

Registrate tre marche temporali sulla stessa riga: quando il servizio di dipendenza ha raggiunto RUNNING, quando è comparsa la risorsa richiesta e quando RRAS l’ha infine accettata. Quella singola riga risponde alla domanda che farà il prossimo ingegnere, e produrla non costa quasi nulla. Senza, l’indagine successiva riparte dalle stesse congetture di questa.

Fermate l’automazione dopo un numero definito di tentativi e segnalate un guasto invece di riprovare all’infinito. Un avvio che termina con un messaggio chiaro «la risorsa non è mai comparsa» vale più di uno che continua a riavviare un servizio al buio. Quando quel messaggio compare, il nome della risorsa che avete annotato nella seconda sezione è ciò che cercherà la persona successiva.