De ce clientul Linux GlobalProtect eșuează pe Ubuntu mai noi

Presupunerea rezonabilă este că .deb-ul din portalul dumneavoastră GlobalProtect este stricat sau că producătorul a livrat o compilare defectuoasă. De obicei nu este. Interfața Linux a producătorului încă se leagă de Qt5 WebKit, iar versiunile mai noi de Ubuntu nu îl mai livrează, așa că pachetul cere o bibliotecă pe care distribuția dumneavoastră a eliminat-o intenționat. Este o nepotrivire de împachetare, nu o descărcare coruptă, iar această diferență decide dacă petreceți după-amiaza forțând pachete sau zece minute alegând un alt client.

Fișierul .deb nu este stricat

O dependență pe care distribuția nu o mai are este rezultatul normal al retragerii unei biblioteci. Qt5 WebKit a fost eliminat din arhivele Ubuntu ulterioare și din Debian, iar motivul a fost întreținerea securității, nu lipsa cererii. Când se întâmplă asta, fiecare pachet care încă se leagă de el nu mai poate fi instalat, oricât de bine ar fi fost construit.

Două defecțiuni sunt raportate ca aceeași eroare și nu sunt. Pe o versiune fără bibliotecă, instalatorul se oprește la o dependență nesatisfăcută. Pe o versiune pe care clientul se instalează și apoi eșuează la autentificare, vedeți de fapt o problemă de handshake TLS sau SAML în interiorul componentei de browser încorporate. Prima este împachetare; a doua este timp de execuție, și niciuna nu se repară copiind biblioteci vechi într-un desktop modern.

Confirmați dependența în loc să o forțați

Instalați pachetul explicit, astfel încât instrumentul să numească dependența nerezolvată în loc să vă dea un rezumat. Apoi întrebați dacă versiunea dumneavoastră are măcar un candidat, pentru că „indisponibil aici” și „lipsește temporar din această oglindă” duc la decizii complet diferite:

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

Dacă apt-cache policy nu raportează niciun candidat, opriți-vă din a încerca să îl instalați și începeți să alegeți o alternativă. Interesant nu este numele pachetului lipsă; este faptul că graful de dependențe al producătorului nu s-a mișcat odată cu distribuțiile pe care le rulează utilizatorii dumneavoastră.

Ce face desktopului forțarea pachetelor vechi

Soluția ocolitoare care circulă este să scoți biblioteca dintr-o versiune mai veche. Pe un Ubuntu actual asta ajunge într-un conflict de versiune minoră Qt5: pachetele mai vechi trag libqt5core5t64 înapoi, iar apoi pachetele KDE și PyQt instalate încep să ceară o versiune ABI pe care biblioteca retrogradată nu o mai oferă. Rezultatul este o actualizare parțială care rupe aplicații fără legătură, ceea ce este o după-amiază mult mai rea decât cea cu care ați început.

Acest rezultat este de așteptat și nu este ghinion. Așteptările Qt privind ABI-ul pentru versiunile minore sunt stricte, iar o distribuție livrează un singur set coerent. Să amesteci o bibliotecă din altă versiune nu este o corectare punctuală; este o a doua actualizare, mai puțin controlată.

Același sfat se aplică variantei de execuție a defecțiunii. Coborârea nivelului de securitate OpenSSL la nivel de sistem pentru ca handshake-ul unui client vechi să reușească schimbă fiecare conexiune TLS de pe mașină pentru a repara o singură aplicație, inclusiv managerul de pachete de care veți avea nevoie când se strică altceva.

openconnect vorbește protocolul

OpenConnect implementează direct protocolul GlobalProtect, iar notele de protocol descriu atât invocarea, cât și separarea dintre cele două interfețe de server. Portalul distribuie setările și lista de gateway-uri; gateway-ul termină tunelul:

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

Dacă portalul omite gateway-ul de care aveți nevoie, --usergroup=gateway sau un URL care se termină în /gateway sare peste pasul portalului. Când sunt oferite mai multe gateway-uri, --authgroup=NAME alege dintre ele. Autentificarea este un nume de utilizator și o parolă, opțional cu un certificat de client, iar gateway-urile SAML funcționează în practică prin network-manager-openconnect în loc de o linie de comandă tastată manual.

Un gateway cu o politică strictă de posture poate cere și un raport HIP înainte de a livra un tunel. OpenConnect poate genera și trimite unul, dar dacă gateway-ul cere un inventar pe care nu îl poate produce, niciun flag nu schimbă acea politică; este o decizie pe partea de server.

Verificați tunelul și știți ce nu va repara openconnect

Verificați ce a aplicat de fapt tunelul în loc să vă încredeți în mesajul de succes. Gateway-ul trimite rutarea și configurația ca XML, iar clientul le aplică, deci o rută lipsă este o problemă de configurare sau de selecție, nu un bug al clientului:

ip -4 addr show
ip route
resolvectl status

MTU merită o privire separată. Configurația GlobalProtect raportează întotdeauna un MTU de zero, așa că clientul estimează unul din costul de încapsulare. Transferurile mari care se blochează în timp ce cererile mici trec sunt simptomul clasic, iar remediul este un MTU explicit pe conexiune, nu dezactivarea descoperirii căii.

IPv6 este din nou o chestiune separată. PAN l-a adăugat în GlobalProtect 4.0, iar suportul din OpenConnect este descris ca experimental începând cu versiunea 9.0, așa că nu presupuneți că familia de adrese se comportă ca IPv4 doar pentru că tunelul a pornit. Și dacă gateway-ul impune o verificare de posture pe care clientul open source nu o poate îndeplini, rulați clientul producătorului pe o versiune LTS acceptată, într-o mașină virtuală dacă stația dumneavoastră de lucru a avansat. Asta păstrează desktopul intact și pune dependența veche în interiorul unei limite pe care o puteți reconstrui.