Pourquoi le client Linux GlobalProtect échoue sur les Ubuntu récents

L’hypothèse raisonnable est que le .deb de votre portail GlobalProtect est cassé, ou que le fournisseur a livré une compilation défectueuse. Ce n’est généralement pas le cas. L’interface Linux du fournisseur se lie toujours à Qt5 WebKit, et les versions récentes d’Ubuntu ne le fournissent plus, donc le paquet réclame une bibliothèque que votre distribution a retirée exprès. C’est une inadéquation d’empaquetage, pas un téléchargement corrompu, et cette différence décide si vous passez l’après-midi à forcer des paquets ou dix minutes à choisir un autre client.

Le .deb n’est pas cassé

Une dépendance que la distribution ne fournit plus est le résultat normal d’une bibliothèque mise au rebut. Qt5 WebKit a été retiré des archives Ubuntu ultérieures et de Debian, et la raison était la maintenance de sécurité et non un manque de demande. Quand cela arrive, tout paquet qui s’y lie encore cesse d’être installable, quelle que soit la qualité de sa construction.

Deux échecs sont signalés comme le même bug et ne le sont pas. Sur une version sans la bibliothèque, l’installateur s’arrête sur une dépendance non satisfaite. Sur une version où le client s’installe puis échoue à la connexion, vous voyez plutôt un problème de poignée de main TLS ou SAML à l’intérieur du composant de navigateur embarqué. Le premier relève de l’empaquetage ; le second de l’exécution, et aucun des deux ne se répare en copiant d’anciennes bibliothèques dans un bureau moderne.

Confirmer la dépendance au lieu de la forcer

Installez le paquet explicitement pour que l’outil nomme la dépendance non résolue au lieu de vous donner un résumé. Demandez ensuite si votre version a le moindre candidat, car « non disponible ici » et « temporairement absent de ce miroir » mènent à des décisions totalement différentes :

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

Si apt-cache policy ne signale aucun candidat, cessez d’essayer de l’installer et commencez à choisir une alternative. Ce qui est intéressant n’est pas le nom du paquet manquant ; c’est le fait que le graphe de dépendances du fournisseur n’a pas suivi les distributions que vos utilisateurs exécutent.

Ce que forcer d’anciens paquets fait au bureau

La solution de contournement qui circule consiste à tirer la bibliothèque d’une version plus ancienne. Sur un Ubuntu actuel, cela finit en conflit de version mineure de Qt5 : les paquets plus anciens entraînent libqt5core5t64 vers l’arrière, et les paquets KDE et PyQt déjà installés se mettent à exiger une version d’ABI que la bibliothèque rétrogradée ne fournit plus. Le résultat est une mise à niveau partielle qui casse des applications sans rapport, ce qui est un après-midi bien pire que celui avec lequel vous avez commencé.

Ce résultat est attendu et non malchanceux. Les attentes d’ABI de Qt pour les versions mineures sont strictes, et une distribution livre un ensemble cohérent. Mélanger une bibliothèque d’une autre version n’est pas une correction ciblée ; c’est une seconde mise à niveau, moins maîtrisée.

Le même conseil vaut pour la variante d’exécution de la panne. Abaisser le niveau de sécurité d’OpenSSL à l’échelle du système pour faire réussir la poignée de main d’un vieux client modifie chaque connexion TLS de la machine afin de réparer une application, y compris le gestionnaire de paquets dont vous aurez besoin quand autre chose cassera.

openconnect parle le protocole

OpenConnect implémente directement le protocole de GlobalProtect, et les notes de protocole décrivent à la fois l’invocation et la séparation entre les deux interfaces serveur. Le portail distribue les paramètres et la liste des passerelles ; la passerelle termine le tunnel :

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

Si le portail omet la passerelle dont vous avez besoin, --usergroup=gateway ou une URL se terminant par /gateway contourne l’étape du portail. Quand plusieurs passerelles sont proposées, --authgroup=NAME choisit parmi elles. L’authentification est un nom d’utilisateur et un mot de passe, éventuellement avec un certificat client, et les passerelles SAML fonctionnent en pratique via network-manager-openconnect plutôt qu’une ligne de commande tapée à la main.

Une passerelle appliquant une politique de posture stricte peut aussi exiger un rapport HIP avant de délivrer un tunnel. OpenConnect peut en générer et en soumettre un, mais si la passerelle exige un inventaire qu’il ne peut pas produire, aucun indicateur ne change cette politique ; c’est une décision côté serveur.

Vérifier le tunnel et savoir ce qu’openconnect ne corrigera pas

Vérifiez ce que le tunnel a réellement appliqué plutôt que de faire confiance au message de réussite. La passerelle envoie le routage et la configuration en XML et le client les applique, donc une route manquante est un problème de configuration ou de sélection et non un bug du client :

ip -4 addr show
ip route
resolvectl status

La MTU mérite un examen à part. La configuration GlobalProtect rapporte toujours une MTU de zéro, donc le client en estime une à partir de la surcharge d’encapsulation. Les transferts volumineux qui se bloquent alors que les petites requêtes passent sont le symptôme classique, et le remède est une MTU explicite sur la connexion plutôt que la désactivation de la découverte de chemin.

IPv6 est encore un autre sujet. PAN l’a ajouté dans GlobalProtect 4.0, et la prise en charge par OpenConnect est décrite comme expérimentale depuis la version 9.0, donc ne supposez pas que la famille d’adresses se comporte comme IPv4 simplement parce que le tunnel s’est établi. Et si la passerelle impose un contrôle de posture que le client open source ne peut pas satisfaire, exécutez le client du fournisseur sur une version LTS prise en charge, dans une machine virtuelle si votre poste de travail a évolué. Cela garde le bureau intact et place la dépendance héritée à l’intérieur d’une frontière que vous pouvez reconstruire.