Varför GlobalProtect Linux-klienten misslyckas på nyare Ubuntu
Deb-paketet är okej: nyare Ubuntu-versioner har tagit bort Qt5 WebKit, som leverantörens gränssnitt fortfarande länkas mot. Bekräfta beroendet och välj sedan openconnect eller en äldre LTS.
Det rimliga antagandet är att .deb-paketet från din GlobalProtect-portal är trasigt, eller att leverantören skickat en dålig build. Oftast är det inte så. Leverantörens Linux-gränssnitt länkas fortfarande mot Qt5 WebKit, och de nyare Ubuntu-versionerna levererar det inte längre, så paketet ber om ett bibliotek som din distribution medvetet har tagit bort. Det är en paketeringskrock, inte en skadad nedladdning, och skillnaden avgör om du lägger eftermiddagen på att tvinga fram paket eller tio minuter på att välja en annan klient.
.deb-paketet är inte trasigt
Ett beroende som distributionen inte längre har är ett normalt utfall av att ett bibliotek pensioneras. Qt5 WebKit togs bort från senare Ubuntu-arkiv och från Debian, och skälet var säkerhetsunderhåll snarare än bristande efterfrågan. När det händer slutar varje paket som fortfarande länkas mot det att gå att installera, hur väl det än byggdes.
Två fel rapporteras som samma bugg och är det inte. På en version utan biblioteket stannar installationsprogrammet med ett ouppfyllt beroende. På en version där klienten installeras och sedan misslyckas vid inloggning ser du i stället ett TLS- eller SAML-handskakningsproblem inuti den inbäddade webbläsarkomponenten. Det första är paketering; det andra är runtime, och inget av dem lagas genom att kopiera in gamla bibliotek i ett modernt skrivbord.
Bekräfta beroendet i stället för att tvinga fram det
Installera paketet explicit så att verktyget namnger det olösta beroendet i stället för att ge dig en sammanfattning. Fråga sedan om din version över huvud taget har någon kandidat, eftersom ”inte tillgänglig här” och ”tillfälligt saknad i den här speglingen” leder till helt olika beslut:
sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5
Om apt-cache policy inte rapporterar någon kandidat, sluta försöka installera det och börja välja ett alternativ. Det intressanta är inte det saknade paketnamnet; det är att leverantörens beroendegraf inte har följt med de distributioner dina användare kör.
Vad påtvingade gamla paket gör med skrivbordet
Den workaround som cirkulerar är att hämta biblioteket från en äldre version. På en aktuell Ubuntu landar det i en Qt5-minorversionskonflikt: de äldre paketen drar libqt5core5t64 bakåt, och då börjar installerade KDE- och PyQt-paket kräva en ABI-version som det nedgraderade biblioteket inte längre tillhandahåller. Resultatet är en partiell uppgradering som bryter orelaterade program, vilket är en mycket sämre eftermiddag än den du började med.
Det utfallet är väntat och inte otur. Qts ABI-förväntningar på minorversioner är strikta, och en distribution levererar en sammanhängande uppsättning. Att blanda in ett bibliotek från en annan version är ingen riktad fix; det är en andra, mindre kontrollerad uppgradering.
Samma råd gäller runtime-varianten av felet. Att sänka OpenSSL:s säkerhetsnivå systembrett för att få en gammal klients handskakning att lyckas ändrar varje TLS-anslutning på maskinen för att laga ett program, inklusive pakethanteraren du behöver när något annat går sönder.
openconnect talar protokollet
OpenConnect implementerar GlobalProtects protokoll direkt, och protokollanteckningarna beskriver både anropet och delningen mellan de två servergränssnitten. Portalen delar ut inställningar och gatewaylistan; gatewayen avslutar tunneln:
openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com
Om portalen utelämnar den gateway du behöver, --usergroup=gateway eller en URL som slutar på /gateway hoppar över portalsteget. När flera gateways erbjuds, --authgroup=NAME väljer bland dem. Autentisering är ett användarnamn och lösenord, eventuellt med ett klientcertifikat, och SAML-gateways fungerar i praktiken via network-manager-openconnect snarare än en handskriven kommandorad.
En gateway med en strikt posture-policy kan också kräva en HIP-rapport innan den lämnar ut en tunnel. OpenConnect kan skapa och skicka in en, men om gatewayen kräver en inventering som den inte kan producera ändrar ingen flagga den policyn; det är ett beslut på serversidan.
Verifiera tunneln och vet vad openconnect inte fixar
Kontrollera vad tunneln faktiskt tillämpade i stället för att lita på framgångsmeddelandet. Gatewayen skickar routing och konfiguration som XML och klienten tillämpar det, så en saknad rutt är ett konfigurations- eller urvalsproblem och inte en klientbugg:
ip -4 addr show
ip route
resolvectl status
MTU förtjänar en egen titt. GlobalProtect-konfigurationen rapporterar alltid MTU noll, så klienten uppskattar en utifrån inkapslings-overhead. Stora överföringar som stannar medan små förfrågningar lyckas är det klassiska symptomet, och botemedlet är en explicit MTU på anslutningen i stället för att stänga av path discovery.
IPv6 är återigen separat. PAN lade till det i GlobalProtect 4.0, och OpenConnects stöd beskrivs som experimentellt från version 9.0, så anta inte att adressfamiljen beter sig som IPv4 bara för att tunneln kom upp. Och om gatewayen tvingar fram en posture-kontroll som klienten med öppen källkod inte kan uppfylla, kör leverantörsklienten på en stödd LTS-version, i en virtuell maskin om din arbetsstation har flyttat vidare. Det håller skrivbordet intakt och sätter det gamla beroendet innanför en gräns du kan bygga om.