Maintenir un VPN Windows actif : déclencher rasdial sur l’événement de déconnexion

Windows ne propose aucune politique de recomposition pour son client VPN, donc une connexion qui tombe à minuit est encore coupée au petit-déjeuner. Une tâche planifiée qui surveille la déconnexion et exécute rasdial comble cette lacune sans client tiers. Que la tâche se comporte comme un opérateur ou comme une boucle tient à trois détails : quels événements elle filtre, quel identifiant elle peut voir et ce qu’elle fait du résultat. Aucun des trois n’est difficile, et en omettre un seul suffit à produire une tâche qui compose indéfiniment.

Pourquoi un minuteur est le mauvais déclencheur

Un minuteur compose selon son propre calendrier, que le tunnel soit coupé ou non. Cela produit des tentatives dont personne n’avait besoin, et une tentative pendant une session de travail peut l’interrompre. Un déclencheur d’événement ne se déclenche que lorsque la connexion change d’état, ce qui coûte moins cher et se raisonne plus facilement. L’événement porte aussi la raison, et la raison est ce qui sépare une panne réseau d’une personne qui se déconnecte volontairement.

Cette distinction fait la différence entre une tâche utile et une qui se bat avec l’utilisateur chaque soir. C’est aussi la partie qui manque souvent dans les recettes qui ne décrivent que l’action.

La paire d’événements, et celui qu’il faut supprimer

Le client du service d’accès distant écrit des enregistrements de cycle de vie dans le journal Application sous le fournisseur RasClient. 20226 marque une connexion terminée, et 20227 marque une tentative échouée, donc l’un comme l’autre peut justifier une nouvelle composition. Tout le reste de la tâche dépend de la correspondance exacte de ces deux identifiants. Ils sont stables depuis des années, ce qui explique pourquoi les recettes qui s’appuient dessus circulent encore, mais une construction qui renomme le fournisseur ou les identifiants fait que la requête ne renvoie rien. Réexécutez l’étape de preuve après chaque mise à jour de fonctionnalité plutôt que d’attendre que la tâche cesse de se déclencher.

Une terminaison doit être exclue. L’erreur 631 signifie que l’utilisateur a déconnecté le port, et une recomposition à ce moment-là se bat avec la personne qui vient de changer de réseau volontairement. Placez l’exclusion dans le filtre du déclencheur plutôt que dans le script, pour que la tâche ne démarre pas du tout. Elle doit s’appliquer à un seul identifiant d’événement, car un prédicat EventData ne correspond que lorsque l’élément nommé existe, et une clause partagée écarterait silencieusement chaque événement de l’autre identifiant. Lisez le nom de l’élément dans un enregistrement réel avant d’écrire le filtre :

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

Le XML montre les noms exacts de Data dans cet enregistrement. ErrorCode est l’orthographe habituelle, et un enregistrement qui utilise autre chose demande que ce nom soit remplacé dans le filtre ci-dessous.

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

Collez cela dans le filtre personnalisé du déclencheur et prouvez-le comme requête avant qu’il ne devienne un déclencheur. Le même XPath s’exécute depuis PowerShell sur le journal en direct, ce qui est le moyen le moins coûteux de voir à quoi il correspond tant que l’historique des tâches n’est pas encore impliqué.

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

Un déclencheur qui ne correspond silencieusement à rien ressemble exactement à une tâche qui s’exécute et échoue. Les deux se présentent comme « l’automatisation ne fonctionne pas », et aucun ne dit quelle moitié manque. Vérifiez d’abord la sortie de la requête, car elle sépare les deux cas en une étape.

La composition échoue parce que personne n’est là pour taper le mot de passe

L’action exécute rasdial avec le nom de la connexion. Lorsque le profil n’a aucun identifiant en cache, la composition échoue immédiatement parce que personne ne peut répondre à l’invite. C’est la raison la plus fréquente pour laquelle une tâche correctement déclenchée ne fait rien de visible, alors vérifiez-la avant de toucher au déclencheur. Composer à la main depuis une invite de commandes sépare un problème d’identifiants d’un problème de planification.

Enregistrez l’identifiant une fois sous le compte avec lequel la tâche s’exécutera, et faites de ce compte une partie de la conception. Une tâche exécutée en tant que SYSTEM ne peut pas lire un identifiant mis en cache par votre compte interactif, et une tâche exécutée en tant que quelqu’un d’autre non plus. Le nom doit aussi correspondre exactement au profil, y compris tout préfixe de domaine dans le champ utilisateur.

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

La première commande liste les noms que Windows connaît. La deuxième compose par nom avec l’identifiant en cache, et la troisième est la forme qu’une action PowerShell devrait utiliser, car elle attend et renvoie une valeur que la tâche peut enregistrer.

Lisez le code de sortie plutôt que la fenêtre

Une tâche qui lance un processus sans attendre signale un succès dès que le processus existe. Pour une composition qui peut échouer une seconde plus tard, ce verdict ne vaut rien. Attendre le code de sortie transforme l’action en résultat réel. L’historique des tâches à lui seul montre seulement qu’un processus a démarré, jamais qu’un tunnel s’est levé.

Journalisez la valeur avec un horodatage à chaque exécution. Un échec isolé après une coupure est normal, tandis que trois échecs d’affilée avec le même code pointent vers l’identifiant ou le profil plutôt que vers le réseau. C’est ce motif qui rend l’historique digne d’être lu.

Ajoutez un court intervalle de répétition comme assurance, et soyez explicite sur la façon dont il interagit avec un déclencheur d’événement. Une répétition toutes les minutes pendant cinq minutes fournit la seconde tentative lorsque l’internet est revenu avec le tunnel, et sous Paramètres, « Si la tâche est déjà en cours d’exécution, la règle suivante s’applique », la tâche veut « Ne pas démarrer une nouvelle instance » pour qu’une répétition ne chevauche pas une composition encore en cours. Sans ce paramètre, deux processus rasdial peuvent se disputer le même port et le second échoue sans raison utile.

Prouvez le chemin de récupération

Testez les deux directions délibérément. Déconnectez à la main et confirmez qu’aucune recomposition n’a lieu, puis désactivez la carte réseau et confirmez que la tâche se déclenche au retour du lien. Ces deux tests couvrent la règle de suppression et le cas réel de panne, et rien d’autre ne le fait.

Lisez ensuite l’historique des tâches plutôt que l’icône de connexion. L’historique enregistre quand la tâche s’est exécutée, quel compte elle a utilisé et ce que l’action a renvoyé, et c’est la preuve nécessaire lorsque la même machine retombera le mois prochain.