OpenConnect vpnc-script : quel fichier s’exécute ?

OpenConnect peut terminer la poignée de main du tunnel et vous laisser malgré tout sans route vers le sous-réseau privé, car le client et l’auxiliaire qui modifie l’état du réseau local sont deux programmes différents. L’authentification prouve que la passerelle a accepté la session ; elle ne prouve rien sur l’interface, les routes ou les paramètres du résolveur installés ensuite. La plupart des rapports déroutants viennent du remplacement de l’auxiliaire par une copie issue d’une ancienne réponse, ce qui change le comportement de chaque connexion sur la machine. Localisez l’auxiliaire que le client en cours d’exécution appelle réellement avant d’en modifier quoi que ce soit.

Deux programmes, deux responsabilités

Le client possède le transport, l’authentification et le périphérique du tunnel. Un auxiliaire distinct possède ce qui se passe sur le système local une fois le tunnel créé : l’adressage de l’interface, les routes vers les sous-réseaux annoncés par la passerelle et la configuration du résolveur. La documentation de l’auxiliaire OpenConnect décrit cette séparation et l’environnement que reçoit l’auxiliaire. La distinction compte lors d’une panne, car un mot de passe refusé et une route manquante ne sont pas le même incident, même lorsque le bureau affiche une seule boîte de dialogue pour les deux.

Garder cette séparation en tête explique aussi pourquoi une connexion peut signaler un succès alors que les noms privés ne se résolvent toujours pas. Le tunnel est monté dans les deux cas, et seule l’étape d’intégration locale diffère.

Localisez l’auxiliaire utilisé par le client en cours d’exécution

Le chemin est fixé lors de la construction du paquet et peut être remplacé à chaque invocation, donc le fichier dont vous vous souvenez d’une autre distribution n’a peut-être aucun rapport avec cette connexion. Interrogez le processus en cours plutôt que la documentation que vous avez ouverte.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Si la ligne de processus porte un --script argument, ce fichier l’emporte sur la valeur par défaut compilée. Des chemins plus anciens comme /etc/vpnc/vpnc-script peuvent exister et rester inutilisés, ce qui explique que les supprimer ou les modifier ne change rien sur une compilation récente. Vérifiez aussi la date de modification, car un auxiliaire que personne n’a touché depuis des années est un signe fort que la valeur par défaut empaquetée fait le travail.

L’intégration à NetworkManager est un troisième propriétaire, avec son propre auxiliaire et ses propres réglages de profil. Empiler un second script de routes ou de résolveur sur cette intégration duplique les routes et laisse un résolveur que deux programmes prétendent gérer. Choisissez un seul propriétaire par connexion et désactivez l’autre avant de tester.

Lisez la première opération en échec, pas le dernier avertissement

La configuration de l’interface, l’installation des routes, le choix du résolveur et le nettoyage de l’état obsolète sont des étapes distinctes, et l’avertissement imprimé en dernier est souvent une plainte de nettoyage et non la panne qui a cassé la connexion. Lisez vers le haut jusqu’à la première opération précise qui a échoué. Une erreur d’auxiliaire qui nomme un fichier ou une adresse vaut plus que dix lignes de bruit de démontage.

Comparez le résultat local attendu à celui observé : le périphérique du tunnel existe, une route vers une adresse privée connue passe par lui et le résolveur répond pour un nom privé. Un auxiliaire qui réussit les deux premiers et échoue au troisième pointe la politique du résolveur plutôt que le routage. Un auxiliaire qui ne configure pas du tout le périphérique n’a probablement jamais été exécuté, et c’est une question de permissions, pas de réseau. Confirmez le bit exécutable et le compte de service avant de réécrire la moindre logique.

Vérifiez la connexion, la reconnexion et la déconnexion

La configuration n’est que la moitié du contrat, car le même auxiliaire doit restaurer ou supprimer l’état qu’il possède lorsque le tunnel se ferme. Un auxiliaire qui ajoute des routes et ne les retire jamais laisse la machine avec un chemin obsolète qui survit à la session.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Exécutez les trois premières lignes pendant que vous êtes connecté, déconnectez-vous, puis exécutez-les à nouveau et confirmez que la route et l’entrée du résolveur ont disparu. La quatrième ligne montre si l’auxiliaire a été invoqué tout court et quel chemin exécutable le service a utilisé. Conservez cette paire de sorties dans le ticket, car c’est le avant-après qui rend un bug de nettoyage évident.

Gardez l’auxiliaire empaqueté et exécutable par le compte de service, car un script qui s’exécute dans votre shell peut encore être refusé sous une politique de service restreinte. Lorsqu’une personnalisation est réellement nécessaire, documentez son objet et son propriétaire et comparez-la à la version empaquetée à chaque mise à jour. Un fork inexpliqué d’un auxiliaire est l’une des rares choses qui peuvent faire échouer une connexion fonctionnelle un an plus tard.