Perché il client Linux GlobalProtect fallisce sulle Ubuntu più recenti

L’ipotesi ragionevole è che il .deb del tuo portale GlobalProtect sia rotto, o che il fornitore abbia pubblicato una build difettosa. Di solito non è così. L’interfaccia Linux del fornitore è ancora collegata a Qt5 WebKit, e le versioni più recenti di Ubuntu non lo forniscono più, quindi il pacchetto chiede una libreria che la tua distribuzione ha rimosso di proposito. È un disallineamento di pacchettizzazione, non un download corrotto, e questa differenza decide se passi il pomeriggio a forzare pacchetti o dieci minuti a scegliere un client diverso.

Il pacchetto .deb non è rotto

Una dipendenza che la distribuzione non fornisce più è il normale esito di una libreria mandata in pensione. Qt5 WebKit è stato rimosso dagli archivi Ubuntu successivi e da Debian, e il motivo era la manutenzione della sicurezza e non la mancanza di richiesta. Quando accade, ogni pacchetto che vi è ancora collegato smette di essere installabile, per quanto bene sia stato compilato.

Due guasti vengono segnalati come lo stesso bug e non lo sono. Su una versione senza la libreria, l’installer si ferma su una dipendenza non soddisfatta. Su una versione in cui il client si installa e poi fallisce al login, stai invece guardando un problema di handshake TLS o SAML dentro il componente browser incorporato. Il primo è pacchettizzazione; il secondo è runtime, e nessuno dei due si ripara copiando vecchie librerie in un desktop moderno.

Confermare la dipendenza invece di forzarla

Installa il pacchetto in modo esplicito, così lo strumento nomina la dipendenza irrisolta invece di darti un riepilogo. Poi chiedi se la tua versione ha un candidato, perché «non disponibile qui» e «temporaneamente assente da questo mirror» portano a decisioni completamente diverse:

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

Se apt-cache policy non riporta alcun candidato, smetti di provare a installarlo e inizia a scegliere un’alternativa. La parte interessante non è il nome del pacchetto mancante; è il fatto che il grafo delle dipendenze del fornitore non si è mosso con le distribuzioni che usano i tuoi utenti.

Che cosa fa al desktop forzare pacchetti vecchi

Il workaround che circola è tirare la libreria da una versione precedente. Su un Ubuntu attuale questo sfocia in un conflitto di versione minore di Qt5: i pacchetti più vecchi trascinano libqt5core5t64 all’indietro, e poi i pacchetti KDE e PyQt installati iniziano a chiedere una versione di ABI che la libreria retrocessa non fornisce più. Il risultato è un aggiornamento parziale che rompe applicazioni non correlate, cioè un pomeriggio molto peggiore di quello con cui avevi iniziato.

Quell’esito è atteso e non sfortunato. Le aspettative di ABI di Qt sulle versioni minori sono rigide, e una distribuzione fornisce un insieme coerente. Mescolare una libreria di un’altra versione non è una correzione mirata; è un secondo aggiornamento, meno controllato.

Lo stesso consiglio vale per la variante runtime del guasto. Abbassare il livello di sicurezza di OpenSSL a livello di sistema per far riuscire l’handshake di un client vecchio cambia ogni connessione TLS della macchina per riparare una sola applicazione, incluso il gestore di pacchetti che ti servirà quando qualcos’altro si romperà.

openconnect parla il protocollo

OpenConnect implementa direttamente il protocollo di GlobalProtect, e le note sul protocollo descrivono sia l’invocazione sia la separazione tra le due interfacce server. Il portale distribuisce le impostazioni e l’elenco dei gateway; il gateway termina il tunnel:

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

Se il portale omette il gateway che ti serve, --usergroup=gateway oppure un URL che termina con /gateway salta il passaggio dal portale. Quando vengono offerti più gateway, --authgroup=NAME sceglie tra loro. L’autenticazione è un nome utente e una password, eventualmente con un certificato client, e i gateway SAML funzionano in pratica tramite network-manager-openconnect invece che con una riga di comando digitata a mano.

Un gateway con una politica di postura rigida può anche richiedere un report HIP prima di consegnare un tunnel. OpenConnect può generarne e inviarne uno, ma se il gateway esige un inventario che non è in grado di produrre, nessun flag cambia quella politica; è una decisione lato server.

Verificare il tunnel e sapere cosa openconnect non risolverà

Controlla che cosa ha effettivamente applicato il tunnel invece di fidarti del messaggio di successo. Il gateway invia routing e configurazione come XML e il client li applica, quindi una rotta mancante è un problema di configurazione o di selezione e non un bug del client:

ip -4 addr show
ip route
resolvectl status

La MTU merita uno sguardo a parte. La configurazione GlobalProtect riporta sempre una MTU di zero, quindi il client ne stima una dall’overhead di incapsulamento. I trasferimenti grandi che si bloccano mentre le richieste piccole passano sono il sintomo classico, e il rimedio è una MTU esplicita sulla connessione invece di disattivare la scoperta del percorso.

IPv6 è di nuovo un capitolo a parte. PAN l’ha aggiunto in GlobalProtect 4.0, e il supporto di OpenConnect è descritto come sperimentale dalla versione 9.0, quindi non dare per scontato che la famiglia di indirizzi si comporti come IPv4 solo perché il tunnel si è alzato. E se il gateway impone un controllo di postura che il client open source non può soddisfare, esegui il client del fornitore su una versione LTS supportata, in una macchina virtuale se la tua postazione di lavoro è andata avanti. Così il desktop resta intatto e la dipendenza legacy finisce dentro un confine che puoi ricostruire.