OpenConnect sous macOS : paquet, archive de version ou clone git

Trois chemins vous donnent un client OpenConnect sur un Mac, et ils laissent des choses différentes sur le disque. Une formule Homebrew installe un binaire compilé et le script réseau qui configure les routes et le DNS. Une archive de version vous donne du code source avec un système de compilation généré. Une copie git vous donne du code source sans lui. Choisir le mauvais chemin est la raison pour laquelle on rencontre un configure manquant quelques minutes après le début d’un tutoriel.

Deux machines différentes sous le même nom

Le chemin du paquet est une seule commande, et c’est le bon choix par défaut pour quiconque a pour métier de se connecter plutôt que de développer.

brew install openconnect

Ce qu’il installe compte plus que la commande. Vous obtenez le binaire du client, et vous obtenez aussi un vpnc-script que le client appelle pour programmer l’interface, les routes et le résolveur. Les deux fonctionnent par paire : le binaire termine la session TLS et remet l’interface obtenue au script, qui est la partie qui sait comment ce système d’exploitation veut que son réseau soit modifié.

Cette séparation explique toute une catégorie de rapports déroutants. Un client qui se connecte, signale un succès puis envoie le trafic sur le mauvais chemin a généralement un problème de script, pas de tunnel, et réinstaller la formule ne le corrige que parce que le script est réinstallé lui aussi. Vérifiez la prise en charge actuelle de la formule pour macOS et l’architecture du processeur avant de planifier dessus ; un Mac qui exécute parfaitement un shell peut encore n’avoir aucun paquet actuel construit pour lui.

Ce que fait réellement le chemin de la source

Une archive de version arrive avec un système de compilation généré, donc le fameux ./configure existe dès le départ. Une copie git non, car les fichiers générés sont des produits de compilation et non des choses que le projet stocke. C’est toute la raison pour laquelle ./autogen.sh figure dans les instructions pour les copies et non pour les archives de version.

./autogen.sh
./configure
make
make install

Chaque ligne fait quelque chose de précis, et savoir laquelle a échoué épargne beaucoup de conjectures. L’étape autogen exécute les autotools pour produire configure. L’étape configure teste le compilateur, les bibliothèques et les en-têtes dont le client a besoin, puis écrit les makefiles qui reflètent ce qu’elle a trouvé. L’étape make compile. L’étape install copie les résultats quelque part dans votre chemin.

C’est à cette dernière ligne que les conseils tournent souvent mal. L’installation n’est pas la preuve que la compilation a fonctionné, et l’exécuter dans un dossier de téléchargement quelconque avec des privilèges élevés est un bon moyen de disperser des fichiers dont vous ne vous souviendrez pas. Si configure échoue sur une bibliothèque manquante, la sortie utile est la première erreur imprimée, pas les vingt dernières lignes du journal.

La session et la configuration réseau sont séparées

Cette distinction décide si une connexion transporte réellement du trafic. Établir la session TLS vous donne une interface côté client. Appliquer des routes, des adresses et des résolveurs DNS est une deuxième étape effectuée via le script réseau, et une compilation qui a produit un binaire sans le script a la moitié d’un client.

La même séparation explique pourquoi deux machines dotées de clients identiques se comportent différemment : le script consulte la configuration réseau du système, et cette configuration inclut tout ce qui d’autre a revendiqué une route. Quand un tunnel divisé envoie le trafic ailleurs qu’attendu, le tunnel fait son travail et c’est la décision de routage qu’il faut examiner.

Alors, quand vous déboguez, demandez quelle couche a échoué. Une session qui ne s’établit jamais relève du protocole, du certificat ou des identifiants. Une session qui s’établit et ne transmet rien relève de l’interface et du script. Un client installé qui fonctionne depuis un réseau et pas depuis un autre relève de l’accessibilité, et aucune recompilation n’y changera rien.

Sachez quel binaire vous exécutez

Une compilation installée à la main et un binaire empaqueté peuvent coexister paisiblement, et celui qui s’exécute dépend de votre chemin et non de vos intentions. Vérifiez-le avant de communiquer un numéro de version à qui que ce soit.

which -a openconnect
openconnect --version
brew list --versions openconnect

La première commande liste chaque copie que votre shell voit, dans l’ordre où il les essaierait. La deuxième vous dit laquelle a répondu. Quand cela ne correspond pas à vos attentes, vous exécutez une compilation issue d’une ancienne expérience, et aucun changement de configuration ne la fera bouger.

Installer un client n’est pas une approbation de passerelle

Un binaire qui fonctionne ne rend pas un déploiement compatible. Confirmez le protocole de la passerelle, son flux d’authentification et toute exigence d’appareil géré auprès des personnes qui en sont responsables, car ce sont des faits de politique et de couche applicative qu’une compilation ne peut pas fournir.

Les instructions de compilation du projet couvrent plus en détail la séquence autotools et l’exigence du script réseau, et c’est la référence à suivre plutôt qu’un billet de blog antérieur à votre version de macOS. Si le but est simplement de se connecter, prenez le paquet, gardez le script et laissez le compilateur de côté.