Kvifor GlobalProtect Linux-klienten feilar på nyare Ubuntu

Den rimelege føresetnaden er at .deb-fila frå GlobalProtect-portalen din er øydelagd, eller at leverandøren sende ein dårleg build. Vanlegvis er ho ikkje det. Linux-grensesnittet til leverandøren lenkjer framleis mot Qt5 WebKit, og dei nyare Ubuntu-utgåvene leverer det ikkje lenger, så pakken ber om eit bibliotek som distribusjonen din fjerna med vilje. Det er eit pakkingsavvik, ikkje ei øydelagd nedlasting, og den skilnaden avgjer om du brukar ettermiddagen på å tvinge pakkar eller ti minutt på å velje ein annan klient.

Deb-fila er ikkje øydelagd

Ein avhengnad distribusjonen ikkje lenger har, er eit normalt resultat av at eit bibliotek blir pensjonert. Qt5 WebKit vart fjerna frå seinare Ubuntu-arkiv og frå Debian, og grunnen var sikkerheitsvedlikehald og ikkje manglande etterspurnad. Når det skjer, sluttar kvar pakke som framleis lenkjer mot det å vere installerbar, same kor godt ho vart bygd.

To feil blir rapporterte som same bug og er det ikkje. På ei utgåve utan biblioteket stoggar installasjonsprogrammet på ein uoppfylt avhengnad. På ei utgåve der klienten blir installert og så feilar ved innlogging, ser du i staden eit TLS- eller SAML-handtrykkproblem inne i den innebygde nettlesarkomponenten. Det første er pakking; det andre er køyretid, og ingen av dei blir reparerte ved å kopiere gamle bibliotek inn i eit moderne skrivebord.

Stadfest avhengnaden i staden for å tvinge han

Installer pakken eksplisitt, slik at verktøyet namngir den uløyste avhengnaden i staden for å gje deg eit samandrag. Spør så om utgåva di i det heile har nokon kandidat, fordi «ikkje tilgjengeleg her» og «mellombels manglar i dette spegelen» fører til heilt ulike avgjerder:

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

Viss apt-cache policy ikkje rapporterer nokon kandidat, slutt å prøve å installere han og byrj å velje eit alternativ. Det interessante er ikkje det manglande pakkenamnet; det er at avhengnadsgrafen til leverandøren ikkje har flytta seg med distribusjonane brukarane dine køyrer.

Kva tvinging av gamle pakkar gjer med skrivebordet

Omgåinga som sirkulerer er å hente biblioteket frå ei eldre utgåve. På ein aktuell Ubuntu endar det i ein Qt5-mindreverse-konflikt: dei eldre pakkane dreg libqt5core5t64 bakover, og då byrjar installerte KDE- og PyQt-pakkar å krevje ein ABI-versjon som det nedgraderte biblioteket ikkje lenger tilbyr. Resultatet er ein delvis oppgradering som øydelegg urelaterte program, noko som er ein mykje verre ettermiddag enn den du byrja med.

Det resultatet er venta og ikkje uflaks. ABI-forventningane til Qt til mindreverse er strenge, og ein distribusjon leverer eitt samanhengjande sett. Å blande inn eitt bibliotek frå ei anna utgåve er ikkje ei målretta retting; det er ein andre, mindre kontrollert oppgradering.

Same rådet gjeld køyretidsvarianten av feilen. Å senke tryggingsnivået til OpenSSL systemvidt for at handtrykket til ein gammal klient skal lukkast, endrar kvar TLS-tilkopling på maskinen for å reparere eitt program, inkludert pakkehandsamaren du treng når noko anna ryker.

openconnect snakkar protokollen

OpenConnect implementerer GlobalProtect-protokollen direkte, og protokollnotata skildrar både kallet og delinga mellom dei to servergrensesnitta. Portalen deler ut innstillingar og gateway-lista; gatewayen avsluttar tunnelen:

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

Viss portalen utelèt gatewayen du treng, --usergroup=gateway eller ein URL som sluttar på /gateway hoppar over portalsteget. Når fleire gatewayar blir tilbodne, --authgroup=NAME vel blant dei. Autentisering er eit brukarnamn og eit passord, eventuelt med eit klientcertifikat, og SAML-gatewayar fungerer i praksis via network-manager-openconnect i staden for ei handskriven kommandolinje.

Ein gateway med ein streng posture-policy kan også krevje ein HIP-rapport før han gir ut ein tunnel. OpenConnect kan generere og sende inn ein, men viss gatewayen krev ei inventarliste han ikkje kan produsere, endrar ingen flagg den policyen; det er ei avgjerd på serversida.

Verifiser tunnelen, og vit kva openconnect ikkje rettar

Sjekk kva tunnelen faktisk brukte i staden for å stole på suksessmeldinga. Gatewayen sender ruting og konfigurasjon som XML og klienten brukar det, så ei manglande rute er eit konfigurasjons- eller valproblem og ikkje ein klientfeil:

ip -4 addr show
ip route
resolvectl status

MTU fortener eit eige blikk. GlobalProtect-konfigurasjonen rapporterer alltid MTU null, så klienten anslår ein frå innkapslingsoverheaden. Store overføringar som stoppar medan små førespurnader går gjennom, er det klassiske symptomet, og botemiddelet er ein eksplisitt MTU på tilkoplinga i staden for å slå av stioppdaging.

IPv6 er igjen noko for seg sjølv. PAN la det til i GlobalProtect 4.0, og støtta i OpenConnect blir skildra som eksperimentell frå versjon 9.0, så ikkje gå ut frå at adressefamilien oppfører seg som IPv4 berre fordi tunnelen kom opp. Og viss gatewayen handhevar ein posture-sjekk som open kjeldekode-klienten ikkje kan oppfylle, køyr leverandørklienten på ei støtta LTS-utgåve, i ein virtuell maskin viss arbeidsstasjonen din allereie har flytta seg vidare. Det held skrivebordet intakt og set den gamle avhengnaden innanfor ei grense du kan byggje på nytt.