RRAS démarre avant que le tunnel OpenVPN ne soit prêt au démarrage

Le serveur redémarre, OpenVPN démarre et RRAS se lance alors que l’adaptateur ou la route dont il dépend manque encore. Redémarrer RRAS à la main une minute plus tard corrige le problème, ce qui le fait paraître résolu et masque le vrai. Deux conditions différentes sont confondues ici : le service prérequis est en cours d’exécution, et la ressource réseau dont RRAS a réellement besoin est devenue utilisable. Une dépendance de service Windows peut exprimer la première condition et jamais la seconde, donc en ajouter une sans définir la ressource vous offre un démarrage plus propre en apparence et la même panne.

À quoi ressemble le symptôme lors d’un démarrage à froid

L’indice est la différence entre un démarrage à froid et un redémarrage. Lors d’un démarrage à froid, RRAS se déclare en cours d’exécution alors que l’adaptateur du tunnel est absent, que la route manque ou que l’adresse du pair n’est pas encore résolue. Un redémarrage manuel réussit ensuite parce qu’à ce moment la ressource existe, et le service relit simplement un monde qu’il ne pouvait pas voir une minute plus tôt. Le journal du service montrera un démarrage propre dans les deux cas, et c’est pourquoi l’observateur d’événements seul explique rarement cela.

Capturez les deux états avant de changer quoi que ce soit : ce que RRAS signale au démarrage et ce qui existe au moment où le redémarrage manuel réussit. Si ces deux observations sont identiques, l’ordre de démarrage n’est pas votre explication et une dépendance n’aidera pas. La comparaison coûte dix minutes et épargne une semaine de conjectures.

Une dépendance ajoutée sur la base de « ça marche après un redémarrage » ne fait que retarder la même panne du temps que le service prérequis met à signaler RUNNING. Elle rend aussi le démarrage plus difficile à comprendre, car la contrainte d’ordre ressemble désormais à une explication. Demandez quel objet la dépendance garantit et si cet objet est bien celui que RRAS ne pouvait pas voir.

Nommez la ressource, pas seulement le service

Écrivez la chose précise qui manque. Ce peut être un adaptateur de tunnel avec une adresse, une route vers un sous-réseau pair, une réponse DNS ou un certificat encore en cours de provisionnement. « Le service VPN fonctionne » n’est pas une description de ressource, et une icône verte dans un client non plus. Tant que vous ne pouvez pas nommer l’objet et une commande qui l’affiche, vous n’avez pas défini la condition que vous essayez d’attendre.

Établissez aussi comment cette instance d’OpenVPN est lancée. Un tunnel géré par GUI et un tunnel géré par service ont des cycles de vie de démarrage différents, et le nom du service doit venir de la machine devant vous, pas d’un exemple écrit pour un autre programme d’installation. Énumérez les candidats au lieu de faire confiance à un nom mémorisé.

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

Lisez la chaîne de dépendances avant d’y ajouter quoi que ce soit

Le Gestionnaire de contrôle des services signale des états comme START_PENDING et RUNNING, et la SERVICE_STATUS reference définit exactement ce que signifie chaque champ. Aucun de ces états ne promet qu’un pair, un nom DNS ou une application en aval est joignable. Cet écart est toute la raison pour laquelle cette panne survit à une dépendance correctement configurée.

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

La ligne DEPENDENCIES issue de sc.exe qc est la liste que vous devez conserver, car sc.exe config RemoteAccess depend= remplace toute la liste au lieu d’y ajouter. Laisser tomber un prérequis sans rapport en ajoutant un service VPN crée une seconde panne qui apparaît lors d’un autre démarrage, et elle est bien plus difficile à diagnostiquer que l’originale. Copiez la liste existante dans votre journal des changements avant d’y toucher.

Les dépendances changent aussi le comportement à l’arrêt, car arrêter un prérequis arrête les services qui en dépendent. Vérifiez ce qui se passe lors de la maintenance avant de lier RRAS à quelque chose qui redémarre souvent.

Conditionnez le redémarrage à une condition, pas à un minuteur

Une attente fixe suppose que le tunnel sera toujours prêt dans cette fenêtre, et c’est précisément l’hypothèse qui échoue au démarrage lorsqu’un certificat est lent ou qu’une liaison est coupée. Vérifiez la ressource elle-même, avec une échéance, et laissez la vérification décider si un redémarrage est nécessaire.

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'

Une tâche planifiée au démarrage qui exécute ces vérifications et ne redémarre RRAS que lorsque l’adaptateur ou la route manque encore est limitée, auditable et facile à retirer. L’alternative, redémarrer RRAS à chaque reconnexion, interrompt des sessions saines et transforme une liaison instable en boucle de redémarrages. Cette boucle est pire que la panne d’origine, car elle touche désormais des utilisateurs qui allaient bien.

Donnez à la vérification une attente maximale correspondant au temps que le tunnel prend raisonnablement sur votre matériel, et faites en sorte que la tâche se termine avec un état non nul lorsqu’elle abandonne. Une tâche silencieuse qui cesse simplement d’essayer est indiscernable d’une tâche qui a réussi.

Journalisez la transition pour que le prochain démarrage s’explique de lui-même

Enregistrez trois horodatages sur la même ligne : quand le service de dépendance a atteint RUNNING, quand la ressource requise est apparue et quand RRAS l’a finalement acceptée. Cette seule ligne répond à la question que posera l’ingénieur suivant, et la produire ne coûte presque rien. Sans elle, l’enquête suivante repart des mêmes conjectures que celle-ci.

Arrêtez l’automatisation après un nombre défini de tentatives et signalez un échec au lieu de réessayer indéfiniment. Un démarrage qui se termine par un message clair « la ressource n’est jamais apparue » vaut mieux qu’un démarrage qui continue de redémarrer un service dans le noir. Quand ce message apparaît, le nom de ressource que vous avez noté dans la deuxième section est ce que la personne suivante recherchera.