OpenVPN sous Windows : démarrer le tunnel automatiquement et conserver les routes

Deux exigences s’entremêlent ici : le tunnel doit monter avant que quiconque ouvre une session, et le trafic d’un second site doit le suivre. Ce sont deux problèmes distincts avec deux mécanismes distincts. Le démarrage du service décide du premier, et la durée de vie de la route du second. Résoudre l’un laisse l’autre exactement où il était.

Première étape : placez le profil là où le service le cherche

Le service Windows lit les profils dans un répertoire fixe, et l’interface graphique lit au même endroit, donc un profil qui fonctionne à l’import peut rester invisible au démarrage. Placez les fichiers .ovpn dans le répertoire config de l’installation, qui se trouve normalement sous Program Files. Un profil laissé dans le dossier Downloads d’un utilisateur n’entre pas du tout dans le périmètre du service.

Les anciennes consignes indiquent un dossier config-auto, que certaines versions de l’époque 2.5 respectaient et les versions ultérieures non. C’est pourquoi une mise à niveau peut transformer un démarrage automatique qui fonctionne en silence, sans rien dans le journal au sujet des identifiants. Vérifiez quel répertoire la version installée lit réellement avant de déplacer le moindre fichier.

Avec plusieurs profils sur une même machine, donnez à chacun un adaptateur nommé via dev-node. Sinon ils se disputent la même interface et le second échoue d’une manière qui ressemble à un problème d’identifiants.

Deuxième étape : démarrez le service, pas l’icône de la zone de notification

Mettre le service OpenVPN en Automatic le fait démarrer au boot sans ouverture de session. C’est le mécanisme, et l’icône de la zone de notification n’en fait pas partie. Quand le service possède la connexion, l’interface graphique peut n’afficher ni icône ni état, ce qui est attendu et non une panne.

La conséquence est que déconnecter signifie arrêter le service, et non cliquer sur Disconnect. Dites-le à qui assure le support de la machine, sinon le premier appel au support portera sur une icône manquante.

Vérifiez que le compte du service peut lire le profil et le matériel de clé. Un problème de permissions au démarrage ressemble dans le journal exactement à un échec d’authentification.

Troisième étape : liez la route au tunnel

Une entrée persistante est le mauvais outil ici. Ajouter une route avec -P la fait survivre aux redémarrages et, pire, la fait survivre à la fermeture du tunnel. VPN arrêté, le préfixe pointe encore vers une passerelle qui n’existe plus, donc l’hôte ne peut pas atteindre cette destination tant que quelqu’un n’a pas supprimé l’entrée.

Trois alternatives se comportent correctement. Poussez la route depuis le serveur, qui l’ajoute à la connexion et la retire à la déconnexion. Ajoutez-la dans un script route-up qui lit route_vpn_gateway, pour que le saut suivant vienne du tunnel négocié. Ou utilisez Add-VpnConnectionRoute avec un profil VPN natif de Windows, qui lie le préfixe à cette connexion.

Quand le serveur offre plus que ce site n’en a besoin, route-nopull refuse les routes poussées et laisse la table entièrement locale. Cela convient à un profil partagé dont les utilisateurs ne doivent pas recevoir de route par défaut d’entreprise.

Quatrième étape : survivez à un démarrage à froid

Démarrer le service avant que la pile réseau existe produit une tentative échouée et aucune reprise. Le passer en Automatic (Delayed Start), ou ajouter une dépendance au service réseau, supprime cette course. Répétez ensuite le test de démarrage et vérifiez qu’une seconde tentative n’est plus nécessaire.

Les changements de route et d’adaptateur demandent des droits d’administrateur. Un raccourci de démarrage par utilisateur ne les a pas, donc un script qui fonctionne depuis un shell élevé peut ne rien faire silencieusement à l’ouverture de session. Planifiez-le comme tâche avec les privilèges les plus élevés, ou laissez le service prendre en charge le changement. Testez-le ensuite en tant qu’utilisateur qui se connectera réellement.

Testez la séquence que vous déployez réellement, pas celle que vous pouvez déclencher à la main. Un démarrage à froid est le seul test qui exerce l’ordre.

Cinquième étape : vérifiez sans l’interface graphique

Après un redémarrage et une ouverture de session, vérifiez trois choses sans ouvrir l’interface graphique. L’adaptateur doit détenir une adresse,la table de routage doit montrer le préfixe du site avec la passerelle du tunnel comme saut suivant, et un ping vers une adresse de l’autre côté doit répondre. Chaque vérification correspond à un mécanisme différent des étapes ci-dessus.

Quand l’adaptateur n’apparaît jamais, le suspect est le pilote et non le profil. Ces deux défaillances ne se ressemblent pas du tout dans le journal, et une seule des deux réagit à une réinstallation du logiciel.