Miért nem működik a GlobalProtect Linux kliense az újabb Ubuntukon

Az ésszerű feltételezés az, hogy a GlobalProtect-portáljáról származó .deb hibás, vagy hogy a gyártó rossz buildet adott ki. Általában nem az. A gyártó Linux-felülete továbbra is a Qt5 WebKithez kapcsolódik, az újabb Ubuntu-kiadások pedig már nem szállítják, ezért a csomag olyan könyvtárat kér, amelyet a disztribúciója szándékosan eltávolított. Ez csomagolási eltérés, nem sérült letöltés, és ez a különbség dönti el, hogy a délutánt a csomagok erőltetésével tölti-e, vagy tíz percet egy másik kliens kiválasztásával.

A .deb nem hibás

Egy olyan függőség, amelyet a disztribúció már nem tartalmaz, egy könyvtár kivonásának normális következménye. A Qt5 WebKit eltűnt a későbbi Ubuntu-archívumokból és a Debianból, és az ok a biztonsági karbantartás volt, nem a kereslet hiánya. Amikor ez megtörténik, minden csomag, amely még mindig hozzá kapcsolódik, telepíthetetlenné válik, akármilyen jól is építették.

Két hibát ugyanazon bugként jelentenek, és nem azok. A könyvtár nélküli kiadáson a telepítő egy kielégítetlen függőségnél megáll. Azon a kiadáson, ahol a kliens települ, majd bejelentkezéskor meghibásodik, valójában egy TLS- vagy SAML-kézfogási problémát lát a beágyazott böngészőkomponensben. Az első csomagolás; a második futásidejű, és egyiket sem javítja meg régi könyvtárak másolása egy modern asztali rendszerbe.

Erősítse meg a függőséget, ne erőltesse

Telepítse a csomagot kifejezetten, hogy az eszköz megnevezze a fel nem oldott függőséget, ahelyett hogy összefoglalót adna. Ezután kérdezze meg, van-e egyáltalán jelöltje a kiadásának, mert az „itt nem érhető el” és az „ideiglenesen hiányzik ebből a tükörből” teljesen eltérő döntésekhez vezet:

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

Ha apt-cache policy nem jelent egyetlen jelöltet sem, hagyja abba a telepítés próbálgatását, és kezdjen alternatívát választani. Az érdekes nem a hiányzó csomagnév; az az tény, hogy a gyártó függőségi gráfja nem mozdult együtt azokkal a disztribúciókkal, amelyeket a felhasználói futtatnak.

Mit tesz a régi csomagok erőltetése az asztali rendszerrel

A keringő megoldás az, hogy régebbi kiadásból húzzák elő a könyvtárat. Egy jelenlegi Ubuntun ez Qt5 alverzió-konfliktusba torkollik: a régebbi csomagok libqt5core5t64 visszafelé húzzák, és akkor a telepített KDE- és PyQt-csomagok olyan ABI-verziót kezdenek követelni, amelyet a lefokozott könyvtár már nem nyújt. Az eredmény egy részleges frissítés, amely független alkalmazásokat tör el, ami sokkal rosszabb délután, mint amellyel kezdte.

Ez az eredmény várható, és nem balszerencse. A Qt ABI-elvárásai az alverziókra szigorúak, és a disztribúció egyetlen összefüggő készletet szállít. Egy könyvtárat egy másik kiadásból bekeverni nem célzott javítás; ez egy második, kevésbé ellenőrzött frissítés.

Ugyanez a tanács vonatkozik a hiba futásidejű változatára. Az OpenSSL rendszerszintű biztonsági szintjének csökkentése, hogy egy régi kliens kézfogása sikerüljön, minden TLS-kapcsolatot megváltoztat a gépen egyetlen alkalmazás javításáért, beleértve a csomagkezelőt, amelyre szüksége lesz, amikor valami más elromlik.

openconnect beszéli a protokollt

Az OpenConnect közvetlenül valósítja meg a GlobalProtect protokollját, és a protokolljegyzetek leírják a hívást és a két kiszolgálói interfész közötti felosztást is. A portál osztja szét a beállításokat és az átjárók listáját; az átjáró zárja le az alagutat:

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

Ha a portál kihagyja a szükséges átjárót, --usergroup=gateway vagy /gateway végű URL kihagyja a portál lépését. Ha több átjárót kínálnak, --authgroup=NAME választ közülük. A hitelesítés felhasználónév és jelszó, opcionálisan kliens-tanúsítvánnyal, és a SAML-átjárók a gyakorlatban a network-manager-openconnect révén működnek, nem kézzel gépelt parancssoron.

Egy szigorú posture-szabályzatú átjáró HIP-jelentést is kérhet, mielőtt alagutat ad. Az OpenConnect képes ilyet készíteni és beküldeni, de ha az átjáró olyan leltárt követel, amelyet nem tud előállítani, egyetlen kapcsoló sem változtat ezen a szabályzaton; ez kiszolgálóoldali döntés.

Ellenőrizze az alagutat, és tudja, mit nem javít meg az openconnect

Ellenőrizze, mit alkalmazott valójában az alagút, ahelyett hogy a sikerüzenetben bízna. Az átjáró XML-ben küldi az útválasztást és a konfigurációt, a kliens pedig alkalmazza, ezért a hiányzó útvonal konfigurációs vagy kiválasztási probléma, nem klienshiba:

ip -4 addr show
ip route
resolvectl status

Az MTU külön pillantást érdemel. A GlobalProtect konfigurációja mindig nulla MTU-t jelent, ezért a kliens a csomagolási többletből becsüli meg. A nagy átvitelek, amelyek elakadnak, miközben a kis kérések átmennek, a klasszikus tünet, és az orvosság az explicit MTU a kapcsolaton, nem az útvonal-felfedezés kikapcsolása.

Az IPv6 megint külön történet. A PAN a GlobalProtect 4.0-ban adta hozzá, az OpenConnect támogatását pedig a 9.0-s verziótól kísérletinek írják le, ezért ne feltételezze, hogy a címcsalád úgy viselkedik, mint az IPv4, csak mert az alagút felállt. És ha az átjáró olyan posture-ellenőrzést kényszerít ki, amelyet a nyílt forráskódú kliens nem tud teljesíteni, futtassa a gyártó kliensét támogatott LTS-kiadáson, virtuális gépen, ha a munkaállomása már továbblépett. Ez érintetlenül tartja az asztali rendszert, és a régi függőséget egy Ön által újraépíthető határba teszi.