Trois questions tranchent, et trois seulement. Le client crée-t-il une entrée de connexion dans le système d'exploitation qui survit à un redémarrage ? Fournit-il une ligne de commande capable de prendre un secret ailleurs que dans sa liste d'arguments ? Son exigence d'identité force-t-elle un humain à répondre à une invite du navigateur ? Répondez dans cet ordre et le choix cesse d'être une affaire de goût, car une tâche planifiée ne peut être aussi sans interface que le permet la plus faible des trois réponses.

Associez le client aux trois couches scriptables

Un profil natif du système d'exploitation, une CLI d'éditeur, un client uniquement graphique et un client avec SSO navigateur demandent quatre approches différentes. Les deux premières survivent aux redémarrages sans surveillance, et les redémarrages sans surveillance sont tout l'enjeu. Les deux autres exigent une décision de conception avant d'exiger un script.

What the client exposesWhat to scriptWhat still bites
OS-native connection entryrasdial, scutil --nc, nmcliTunnel is up before DNS and routes settle
Vendor CLI reading stdinCLI wrapped by the scheduler, secret from the credential storePrompt text changes between releases
GUI onlyPinned version plus a state assertionLocale and DPI break the click targets

Voie une : le système d'exploitation possède déjà le profil

C'est la voie la moins chère et celle que la plupart des gens négligent. Sous Windows, rasdial "Office" se connecte et rasdial "Office" /disconnect ferme la connexion ; rasphone -d "Office" pilote la même entrée via l'interface d'accès distant. macOS liste les services enregistrés avec scutil --nc list et en démarre un avec scutil --nc start. Linux confie la tâche à NetworkManager.

rasdial "Office" user *
scutil --nc start "Office"
nmcli connection up id Office
nmcli -t -f GENERAL.STATE connection show Office

Ces interfaces ne connaissent que les profils détenus par le système d'exploitation, elles ne peuvent donc pas piloter un client tiers quelconque. Quand le profil manque, créez-le une fois et laissez le script le vérifier plutôt que de le recréer à chaque exécution. Rendez le script idempotent : lisez l'état courant, connectez-vous seulement si la connexion est coupée, puis testez le nom privé dont la tâche a réellement besoin.

Voie deux : l'éditeur fournit une ligne de commande

Certains clients exposent assez de ligne de commande pour être enveloppés : Cisco AnyConnect a longtemps eu un assistant de connexion seule, et OpenConnect parle les protocoles AnyConnect, GlobalProtect et Pulse depuis un seul binaire. L exigence qui compte n'est pas la liste des options mais d'où vient le secret, car un mot de passe dans la liste des arguments est lisible par quiconque peut lister les processus.

printf '%s\n' "$VPN_PASS" | openconnect --protocol=anyconnect \
  --user "$VPN_USER" --passwd-on-stdin vpn.example.com

FortiClient et certaines versions de GlobalProtect n'ont aucune CLI prise en charge, et un client communautaire ou un remplacement sous licence de l'éditeur est une décision d'achat, pas un contournement. En CI, accordez au compte de service des droits sur ce binaire précis et non sur un shell, afin qu'un argument injecté ne puisse devenir une commande root.

Voie trois : l'automatisation graphique, et pourquoi elle vient en dernier

Quand le client officiel n'a pas d'interface, les scripts cliquent sur des boutons via des messages de fenêtre ou SendKeys. C'est fragile face à la version et à la langue, cela peut laisser une session à moitié connectée, et cela échoue silencieusement quand une boîte de dialogue apparaît dans la mauvaise langue. Si vous prenez cette voie, figez la version du client, vérifiez ensuite l'état de connexion obtenu, et gardez une solution manuelle documentée à côté du script.

La même prudence s'applique à la déconnexion forcée d'un client en tuant son processus. Le tunnel peut survivre au processus, ou un superviseur peut le relancer, donc tuer-puis-redémarrer n'est pas non plus une remise à zéro fiable.

Ce qui casse une fois le tunnel établi

Une connexion réussie prouve l'authentification et rien d'autre. Testez la ressource pour laquelle la tâche existe, avec son propre protocole et un délai court, et nommez l'étape dans le message d'échec. Les profils, certificats et identifiants stockés visibles sur votre bureau peuvent être invisibles pour la session de service, alors exécutez la tâche une fois sous le compte du planificateur lui-même avant de lui faire confiance.

Bornez les tentatives. Une boucle qui répète un identifiant rejeté verrouille les comptes, et une invite MFA ne peut pas être traitée par une tâche sans interface sans conception d'enrôlement ; les tentatives scriptées contre un flux SSO navigateur ne font que consumer des essais. Préférez une charge VPN livrée par MDM ou un profil de configuration pour un parc, où la plateforme détient le cycle de vie des identifiants, et gardez les scripts pour les clients qui ne peuvent pas être gérés ainsi.

Journalisez le code de sortie et la première ressource en échec, pas le fait que le script ait tourné. Cette seule ligne transforme une alerte du planificateur en diagnostic de cinq minutes.

Articles similaires