Waarom de GlobalProtect Linux-client faalt op nieuwere Ubuntu-versies

De redelijke aanname is dat het .deb uit je GlobalProtect-portaal kapot is, of dat de leverancier een slechte build heeft geleverd. Meestal is dat niet zo. De Linux-interface van de leverancier linkt nog steeds tegen Qt5 WebKit, en de nieuwere Ubuntu-releases leveren dat niet meer mee, dus vraagt het pakket om een bibliotheek die je distributie bewust heeft verwijderd. Dat is een verpakkingsmismatch, geen beschadigde download, en dat verschil bepaalt of je de middag aan het forceren van pakketten besteedt of tien minuten aan het kiezen van een andere client.

Het .deb is niet kapot

Een afhankelijkheid die de distributie niet meer meelevert is een normale uitkomst van een bibliotheek die met pensioen gaat. Qt5 WebKit is uit latere Ubuntu-archieven en uit Debian verdwenen, en de reden was veiligheidsonderhoud en niet een gebrek aan vraag. Als dat gebeurt, wordt elk pakket dat er nog tegen linkt oninstalleerbaar, hoe goed het ook gebouwd is.

Twee fouten worden als dezelfde bug gemeld en zijn dat niet. Op een release zonder de bibliotheek stopt de installer met een onvervulde afhankelijkheid. Op een release waar de client installeert en dan bij het inloggen faalt, kijk je naar een TLS- of SAML-handshake-probleem in de ingebedde browsercomponent. Het eerste is verpakking; het tweede is runtime, en geen van beide wordt gerepareerd door oude bibliotheken in een moderne desktop te kopiëren.

Bevestig de afhankelijkheid in plaats van haar te forceren

Installeer het pakket expliciet, zodat de tooling de onopgeloste afhankelijkheid noemt in plaats van je een samenvatting te geven. Vraag dan of je release überhaupt een kandidaat heeft, want „hier niet beschikbaar” en „tijdelijk ontbrekend in deze mirror” leiden tot heel verschillende beslissingen:

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

Als apt-cache policy geen kandidaat meldt, stop dan met proberen het te installeren en begin een alternatief te kiezen. Het interessante deel is niet de ontbrekende pakketnaam; het is het feit dat de afhankelijkheidsgraaf van de leverancier niet is meebewogen met de distributies die je gebruikers draaien.

Wat het forceren van oude pakketten met de desktop doet

De workaround die rondgaat is de bibliotheek uit een oudere release trekken. Op een actuele Ubuntu loopt dat uit in een Qt5-minorversieconflict: de oudere pakketten trekken libqt5core5t64 terug, en dan gaan geïnstalleerde KDE- en PyQt-pakketten een ABI-versie eisen die de teruggezette bibliotheek niet meer levert. Het resultaat is een gedeeltelijke upgrade die niet-verwante toepassingen breekt, wat een veel slechtere middag is dan die waarmee je begon.

Die uitkomst is te verwachten en niet ongelukkig. De ABI-verwachtingen van Qt voor minorversies zijn streng, en een distributie levert één samenhangende set. Eén bibliotheek uit een andere release inmengen is geen gerichte fix; het is een tweede, minder beheerste upgrade.

Hetzelfde advies geldt voor de runtime-variant van de fout. Het systeembrede OpenSSL-beveiligingsniveau verlagen om de handshake van een oude client te laten slagen, verandert elke TLS-verbinding op de machine om één toepassing te repareren, inclusief de pakketbeheerder die je nodig hebt als er iets anders stukgaat.

openconnect spreekt het protocol

OpenConnect implementeert het protocol van GlobalProtect rechtstreeks, en de protocolnotities beschrijven zowel de aanroep als de splitsing tussen de twee serverinterfaces. Het portaal verdeelt instellingen en de gatewaylijst; de gateway beëindigt de tunnel:

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

Als het portaal de gateway die je nodig hebt weglaat, --usergroup=gateway of een URL die eindigt op /gateway slaat de portaalstap over. Als er meerdere gateways worden aangeboden, --authgroup=NAME kiest daaruit. Authenticatie is een gebruikersnaam en wachtwoord, optioneel met een clientcertificaat, en SAML-gateways werken in de praktijk via network-manager-openconnect in plaats van een met de hand getypte commandoregel.

Een gateway met een strikt posturebeleid kan ook een HIP-rapport eisen voordat hij een tunnel uitgeeft. OpenConnect kan er een genereren en indienen, maar als de gateway een inventaris eist die het niet kan produceren, verandert geen vlag dat beleid; dat is een beslissing aan de serverkant.

Controleer de tunnel, en weet wat openconnect niet oplost

Controleer wat de tunnel daadwerkelijk heeft toegepast in plaats van de succesmelding te vertrouwen. De gateway stuurt routing en configuratie als XML en de client past die toe, dus een ontbrekende route is een configuratie- of selectieprobleem en geen clientbug:

ip -4 addr show
ip route
resolvectl status

MTU verdient een eigen blik. De GlobalProtect-configuratie meldt altijd een MTU van nul, dus schat de client er een uit de encapsulatie-overhead. Grote overdrachten die vastlopen terwijl kleine verzoeken slagen zijn het klassieke symptoom, en het middel is een expliciete MTU op de verbinding in plaats van het uitzetten van path discovery.

IPv6 is weer apart. PAN voegde het toe in GlobalProtect 4.0, en de ondersteuning van OpenConnect wordt vanaf versie 9.0 als experimenteel beschreven, dus ga er niet van uit dat de adresfamilie zich als IPv4 gedraagt alleen omdat de tunnel opkwam. En als de gateway een posturecheck afdwingt waaraan de opensource-client niet kan voldoen, draai de leveranciersclient dan op een ondersteunde LTS-release, in een virtuele machine als je werkplek is doorgeschoven. Dat houdt de desktop intact en zet de oude afhankelijkheid binnen een grens die je opnieuw kunt bouwen.