Waarom die GlobalProtect Linux-kliënt op nuwer Ubuntu misluk

Die redelike aanname is dat die .deb uit jou GlobalProtect-portaal stukkend is, of dat die verskaffer ’n slegte bou gelewer het. Gewoonlik is dit nie. Die verskaffer se Linux-koppelvlak skakel steeds teen Qt5 WebKit, en die nuwer Ubuntu-weergawes lewer dit nie meer nie, so die pakket vra vir ’n biblioteek wat jou verspreiding doelbewus verwyder het. Dit is ’n verpakkingswanpassing, nie ’n beskadigde aflaai nie, en dié verskil bepaal of jy die middag aan gedwonge pakkette spandeer of tien minute aan die keuse van ’n ander kliënt.

Die .deb is nie stukkend nie

’n Afhanklikheid wat die verspreiding nie meer dra nie, is ’n normale uitkoms wanneer ’n biblioteek afgetree word. Qt5 WebKit is uit latere Ubuntu-argiewe en uit Debian verwyder, en die rede was sekuriteitsonderhoud eerder as ’n gebrek aan vraag. Wanneer dit gebeur, hou elke pakket wat steeds daarteen skakel op om installeerbaar te wees, maak nie saak hoe goed dit gebou is nie.

Twee foute word as dieselfde bug gerapporteer en is nie. Op ’n weergawe sonder die biblioteek stop die installeerder met ’n onbevredigde afhanklikheid. Op ’n weergawe waar die kliënt installeer en dan by aanmelding misluk, kyk jy eerder na ’n TLS- of SAML-handdrukprobleem binne die ingebedde blaaierkomponent. Die eerste is verpakking; die tweede is looptyd, en nie een word herstel deur ou biblioteke in ’n moderne werkskerm te kopieer nie.

Bevestig die afhanklikheid eerder as om dit te forseer

Installeer die pakket eksplisiet sodat die gereedskap die onopgeloste afhanklikheid noem eerder as om jou ’n opsomming te gee. Vra dan of jou weergawe hoegenaamd ’n kandidaat het, want ”nie hier beskikbaar nie” en ”tydelik afwesig uit hierdie spieël” lei tot heeltemal verskillende besluite:

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

As apt-cache policy geen kandidaat rapporteer nie, stop om dit te probeer installeer en begin ’n alternatief kies. Die interessante deel is nie die ontbrekende pakketnaam nie; dit is die feit dat die verskaffer se afhanklikheidsgraf nie saam met die verspreidings beweeg het wat jou gebruikers gebruik nie.

Wat gedwonge ou pakkette aan die werkskerm doen

Die workaround wat rondgaan is om die biblioteek uit ’n ouer weergawe te trek. Op ’n huidige Ubuntu loop dit in ’n Qt5-mineurweergawekonflik in: die ouer pakkette trek libqt5core5t64 agteruit, en dan begin geïnstalleerde KDE- en PyQt-pakkette ’n ABI-weergawe eis wat die afgegradeerde biblioteek nie meer verskaf nie. Die resultaat is ’n gedeeltelike opgradering wat onverwante toepassings breek, wat ’n veel slegter middag is as die een waarmee jy begin het.

Daardie uitkoms is verwag en nie ongelukkig nie. Qt se ABI-verwagtings vir mineurweergawes is streng, en ’n verspreiding lewer een samehangende stel. Om een biblioteek uit ’n ander weergawe in te meng is nie ’n gerigte regstelling nie; dit is ’n tweede, minder beheerde opgradering.

Dieselfde raad geld vir die looptyd-variant van die fout. Om die stelselwye OpenSSL-sekuriteitsvlak te verlaag sodat ’n ou kliënt se handdruk slaag, verander elke TLS-verbinding op die masjien om een toepassing te herstel, insluitend die pakketbestuurder wat jy nodig het wanneer iets anders breek.

openconnect praat die protokol

OpenConnect implementeer GlobalProtect se protokol direk, en die protokolnotas beskryf beide die aanroep en die verdeling tussen die twee bedienerkoppelvlakke. Die portaal deel instellings en die gateway-lys uit; die gateway beëindig die tonnel:

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

As die portaal die gateway weglaat wat jy nodig het, --usergroup=gateway of ’n URL wat eindig op /gateway slaan die portaalstap oor. Wanneer verskeie gateways aangebied word, --authgroup=NAME kies tussen hulle. Verifikasie is ’n gebruikersnaam en wagwoord, opsioneel met ’n kliëntsertifikaat, en SAML-gateways werk in die praktyk deur network-manager-openconnect eerder as ’n met die hand getikte opdraglyn.

’n Gateway met ’n streng postuurbeleid kan ook ’n HIP-verslag vereis voordat dit ’n tonnel uitdeel. OpenConnect kan een genereer en indien, maar as die gateway ’n inventaris eis wat dit nie kan produseer nie, verander geen vlag daardie beleid nie; dit is ’n besluit aan die bedienerkant.

Verifieer die tonnel, en weet wat openconnect nie sal regmaak nie

Kontroleer wat die tonnel werklik toegepas het eerder as om die suksesboodskap te vertrou. Die gateway stuur roetering en konfigurasie as XML en die kliënt pas dit toe, so ’n ontbrekende roete is ’n konfigurasie- of keuseprobleem eerder as ’n kliëntfout:

ip -4 addr show
ip route
resolvectl status

MTU verdien sy eie kyk. Die GlobalProtect-konfigurasie rapporteer altyd ’n MTU van nul, so die kliënt skat een uit die inkapselings-oorhoof. Groot oordragte wat vasval terwyl klein versoeke slaag, is die klassieke simptoom, en die middel is ’n eksplisiete MTU op die verbinding eerder as om padontdekking af te skakel.

IPv6 is weer apart. PAN het dit in GlobalProtect 4.0 bygevoeg, en OpenConnect se ondersteuning word vanaf weergawe 9.0 as eksperimenteel beskryf, so moet nie aanneem dat die adresfamilie hom soos IPv4 gedra net omdat die tonnel opgekom het nie. En as die gateway ’n postuurkontrole afdwing wat die oopbron-kliënt nie kan bevredig nie, bedryf die verskafferkliënt op ’n ondersteunde LTS-weergawe, in ’n virtuele masjien as jou werkstasie al verder geskuif het. Dit hou die werkskerm ongeskonde en plaas die ou afhanklikheid binne ’n grens wat jy kan herbou.