Wêrom't de GlobalProtect Linux-klient mislearret op nijere Ubuntu

De ridlike oanname is dat de .deb fan jo GlobalProtect-portaal stikken is, of dat de leveransier in minne build levere hat. Meastentiids is dat net sa. De Linux-interface fan de leveransier is noch keppele oan Qt5 WebKit, en de nijere Ubuntu-releases leverje dat net mear, dus freget it pakket om in bibleteek dy't jo distribúsje mei opsetsin fuorthelle hat. Dat is in ferpakkingsmisferstân, gjin skansearre download, en dat ferskil bepaalt oft jo de middei oan it twingen fan pakketten besteegje of tsien minuten oan it kiezen fan in oare klient.

De .deb is net stikken

In ôfhinklikens dy't de distribúsje net mear hat is in normaal gefolch fan it ôftsjen fan in bibleteek. Qt5 WebKit waard fuorthelle út lettere Ubuntu-argiven en út Debian, en de reden wie feilichheidsûnderhâld en net in gebrek oan fraach. As dat bart, is elk pakket dat der noch oan keppele is net mear te ynstallearjen, hoe goed oft it ek boud is.

Twa flaters wurde as deselde bug rapportearre en binne dat net. Op in release sûnder de bibleteek stiet de ynstallearder stil by in net-ferfolle ôfhinklikens. Op in release dêr't de klient ynstallearret en dan by it oanmelden mist, sjogge jo in TLS- of SAML-handshake-probleem yn de ynbêde browserkomponint. It earste is ferpakking; it twadde is runtime, en gjin fan beide wurdt reparearre troch âlde bibleteken yn in moderne buroblêd te kopiearjen.

Befêstigje de ôfhinklikens ynstee fan dy te twingen

Ynstallearje it pakket eksplisyt, sadat it ark de net-oploste ôfhinklikens beneamt ynstee fan jo in gearfetting te jaan. Freegje dan oft jo release hielendal in kandidaat hat, want „hjir net beskikber” en „tydlik ûntbrekt yn dizze spegel” liede ta folslein ferskillende besluten:

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

As apt-cache policy gjin kandidaat meldt, stopje dan mei besykjen it te ynstallearjen en begjinne in alternatyf te kiezen. It nijsgjirrige is net de ûntbrekkende pakketnamme; it is it feit dat de ôfhinklikensgraf fan de leveransier net meinommen is mei de distribúsjes dy't jo brûkers draaie.

Wat it twingen fan âlde pakketten mei it buroblêd docht

De workaround dy't rûn giet is de bibleteek út in âldere release te lûken. Op in aktuele Ubuntu rint dat út op in Qt5-minorferzje-konflikt: de âldere pakketten lûke libqt5core5t64 efterút, en dan begjinne ynstallearre KDE- en PyQt-pakketten in ABI-ferzje te easkjen dy't de weromsette bibleteek net mear leveret. It resultaat is in partiele upgrade dy't net-relatearre applikaasjes brekt, wat in folle slimmer middei is as dy't jo begûn.

Dat resultaat is ferwachte en net ûngelokkich. De ABI-ferwachtings fan Qt foar minorferzjes binne strang, en in distribúsje leveret ien gearhingjend set. Ien bibleteek út in oare release bymengje is gjin rjochte fix; it is in twadde, minder beheinde upgrade.

Itselde advys jildt foar de runtime-fariant fan de flater. It systeembreed ferleegjen fan it OpenSSL-feilichheidsnivo om de handshake fan in âlde klient slagje te litten feroaret elke TLS-ferbining op de masine om ien applikaasje te reparearjen, ynklusyf de pakketbehearder dy't jo nedich hawwe as wat oars brekt.

openconnect praat it protokol

OpenConnect implementearret it protokol fan GlobalProtect direkt, en de protokolnotysjes beskriuwe sawol de oanrop as de splitsing tusken de twa tsjinnerinterfaces. It portaal ferdielt ynstellingen en de gatewaylist; de gateway beëiniget de tunnel:

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

As it portaal de gateway dy't jo nedich hawwe weilitten hat, --usergroup=gateway of in URL dy't einiget op /gateway slacht de portaalmstap oer. As der ferskate gateways oanbean wurde, --authgroup=NAME kiest dêrút. Autentikaasje is in brûkersnamme en wachtwurd, opsjoneel mei in klientsertifikaat, en SAML-gateways wurkje yn de praktyk fia network-manager-openconnect ynstee fan in mei de hân typte kommandorigel.

In gateway mei in strang posturebelied kin ek in HIP-rapport easkje foardat er in tunnel jout. OpenConnect kin der ien generearje en ynstjoere, mar as de gateway in ynventaris easket dy't it net meitsje kin, feroaret gjin flagge dat belied; dat is in beslút oan de tsjinnerkant.

Ferifiearje de tunnel, en wyt wat openconnect net reparearret

Kontrolearje wat de tunnel eins tapast hat ynstee fan it suksesberjocht te fertrouwen. De gateway stjoert routing en konfiguraasje as XML en de klient tapast dat ta, dus in ûntbrekkende rûte is in konfiguraasje- of seleksjeprobleem en gjin klientbug:

ip -4 addr show
ip route
resolvectl status

MTU fertsjinnet in eigen eachopslach. De GlobalProtect-konfiguraasje meldt altyd in MTU fan nul, dus skat de klient ien út de ynkapselings-oerhead. Grutte oerdrachten dy't fêstrinne wylst lytse oanfragen trochgeane binne it klassike symptoom, en it middel is in eksplisite MTU op de ferbining ynstee fan it útsetten fan paadûntdekking.

IPv6 is wer apart. PAN foege it ta yn GlobalProtect 4.0, en de stipe fan OpenConnect wurdt fanôf ferzje 9.0 as eksperiminteel beskreaun, dus nim net oan dat de adresfamylje him as IPv4 gedraacht allinnich om't de tunnel omheech kaam. En as de gateway in posture-kontrôle ôftwingt dy't de iepenboarne-klient net ferfolje kin, draai dan de leveransiersklient op in stipe LTS-release, yn in firtuele masine as jo wurkstasjon al fierder gien is. Dat hâldt it buroblêd yntakt en set de âlde ôfhinklikens binnen in grins dy't jo opnij bouwe kinne.