Hvorfor GlobalProtect Linux-klienten feiler på nyere Ubuntu

Den rimelige antakelsen er at .deb-filen fra GlobalProtect-portalen din er ødelagt, eller at leverandøren sendte en dårlig build. Vanligvis er den ikke det. Leverandørens Linux-grensesnitt lenker fortsatt mot Qt5 WebKit, og de nyere Ubuntu-utgivelsene leverer det ikke lenger, så pakken ber om et bibliotek som distribusjonen din fjernet med vilje. Det er et pakkingsavvik, ikke en ødelagt nedlasting, og den forskjellen avgjør om du bruker ettermiddagen på å tvinge pakker eller ti minutter på å velge en annen klient.

.deb-filen er ikke ødelagt

En avhengighet distribusjonen ikke lenger har, er et normalt resultat av at et bibliotek pensjoneres. Qt5 WebKit ble fjernet fra senere Ubuntu-arkiver og fra Debian, og grunnen var sikkerhetsvedlikehold og ikke manglende etterspørsel. Når det skjer, slutter hver pakke som fortsatt lenker mot det å være installerbar, uansett hvor godt den ble bygget.

To feil rapporteres som samme bug og er det ikke. På en utgivelse uten biblioteket stopper installasjonsprogrammet på en uoppfylt avhengighet. På en utgivelse der klienten installeres og så feiler ved innlogging, ser du i stedet et TLS- eller SAML-håndtrykkproblem inne i den innebygde nettleserkomponenten. Det første er pakking; det andre er kjøretid, og ingen av dem repareres ved å kopiere gamle biblioteker inn i et moderne skrivebord.

Bekreft avhengigheten i stedet for å tvinge den

Installer pakken eksplisitt, slik at verktøyet navngir den uløste avhengigheten i stedet for å gi deg et sammendrag. Spør så om utgivelsen din i det hele tatt har noen kandidat, fordi «ikke tilgjengelig her» og «midlertidig mangler i dette speilet» fører til helt forskjellige beslutninger:

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

Hvis apt-cache policy ikke rapporterer noen kandidat, slutt å prøve å installere den og begynn å velge et alternativ. Det interessante er ikke det manglende pakkenavnet; det er at leverandørens avhengighetsgraf ikke har flyttet seg med distribusjonene brukerne dine kjører.

Hva tvinging av gamle pakker gjør med skrivebordet

Omgåelsen som sirkulerer er å hente biblioteket fra en eldre utgivelse. På en aktuell Ubuntu ender det i en Qt5-mindreverse-konflikt: de eldre pakkene drar libqt5core5t64 bakover, og da begynner installerte KDE- og PyQt-pakker å kreve en ABI-versjon som det nedgraderte biblioteket ikke lenger tilbyr. Resultatet er en delvis oppgradering som ødelegger urelaterte programmer, noe som er en mye verre ettermiddag enn den du begynte med.

Det resultatet er forventet og ikke uflaks. Qts ABI-forventninger til mindreverse er strenge, og en distribusjon leverer ett sammenhengende sett. Å blande inn ett bibliotek fra en annen utgivelse er ikke en målrettet retting; det er en andre, mindre kontrollert oppgradering.

Samme råd gjelder kjøretidsvarianten av feilen. Å senke OpenSSLs sikkerhetsnivå systemvidt for at håndtrykket til en gammel klient skal lykkes, endrer hver TLS-tilkobling på maskinen for å reparere ett program, inkludert pakkebehandleren du trenger når noe annet ryker.

openconnect snakker protokollen

OpenConnect implementerer GlobalProtect-protokollen direkte, og protokollnotatene beskriver både kallet og delingen mellom de to servergrensesnittene. Portalen deler ut innstillinger og gateway-listen; gatewayen avslutter tunnelen:

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

Hvis portalen utelater gatewayen du trenger, --usergroup=gateway eller en URL som slutter på /gateway hopper over portalsteget. Når flere gatewayer tilbys, --authgroup=NAME velger blant dem. Autentisering er et brukernavn og et passord, eventuelt med et klientcertifikat, og SAML-gatewayer fungerer i praksis via network-manager-openconnect i stedet for en håndskrevet kommandolinje.

En gateway med en streng posture-policy kan også kreve en HIP-rapport før den gir ut en tunnel. OpenConnect kan generere og sende inn en, men hvis gatewayen krever en inventarliste den ikke kan produsere, endrer ingen flagg den policyen; det er en beslutning på serversiden.

Verifiser tunnelen, og vit hva openconnect ikke retter

Sjekk hva tunnelen faktisk anvendte i stedet for å stole på suksessmeldingen. Gatewayen sender ruting og konfigurasjon som XML og klienten anvender det, så en manglende rute er et konfigurasjons- eller valgproblem og ikke en klientfeil:

ip -4 addr show
ip route
resolvectl status

MTU fortjener et eget blikk. GlobalProtect-konfigurasjonen rapporterer alltid MTU null, så klienten anslår en fra innkapslingsoverheaden. Store overføringer som stopper mens små forespørsler går gjennom, er det klassiske symptomet, og botemiddelet er en eksplisitt MTU på tilkoblingen i stedet for å slå av stioppdagelse.

IPv6 er igjen noe for seg selv. PAN la det til i GlobalProtect 4.0, og OpenConnects støtte beskrives som eksperimentell fra versjon 9.0, så ikke anta at adressefamilien oppfører seg som IPv4 bare fordi tunnelen kom opp. Og hvis gatewayen håndhever en posture-sjekk som åpen kildekode-klienten ikke kan oppfylle, kjør leverandørklienten på en støttet LTS-utgivelse, i en virtuell maskin hvis arbeidsstasjonen din allerede har flyttet seg videre. Det holder skrivebordet intakt og setter den gamle avhengigheten innenfor en grense du kan bygge på nytt.