Miks GlobalProtecti Linuxi klient uuematel Ubuntu versioonidel ei tööta

Mõistlik eeldus on, et teie GlobalProtecti portaalist saadud .deb on katki või et tootja saatis välja vigase buildi. Tavaliselt ei ole. Tootja Linuxi liides lingib endiselt Qt5 WebKiti vastu ja uuemad Ubuntu väljalasked ei paku seda enam, seega küsib pakett teeki, mille teie distributsioon meelega eemaldas. See on pakendamise mittevastavus, mitte rikutud allalaadimine, ja see vahe otsustab, kas kulutate pärastlõuna pakettide pealesurumisele või kümme minutit teise kliendi valimisele.

Pakett .deb ei ole katki

Sõltuvus, mida distributsioon enam ei kanna, on teegi kasutuselt kõrvaldamise tavaline tulemus. Qt5 WebKit eemaldati hilisematest Ubuntu arhiividest ja Debianist ning põhjuseks oli turvahooldus, mitte nõudluse puudumine. Kui see juhtub, ei ole enam ükski pakett, mis endiselt selle vastu lingib, paigaldatav, ükskõik kui hästi see ehitati.

Kaks riket teatatakse sama veana ja need ei ole seda. Väljalaskel ilma teegita peatub paigaldaja rahuldamata sõltuvusega. Väljalaskel, kus klient paigaldub ja siis sisselogimisel ebaõnnestub, näete hoopis TLS-i või SAMLi kätlemise probleemi manustatud brauserikomponendi sees. Esimene on pakendamine; teine on käitusaeg, ja kumbagi ei paranda vanade teekide kopeerimine kaasaegsesse töölauda.

Kinnitage sõltuvus, mitte ärge suruge seda peale

Paigaldage pakett selgesõnaliselt, et tööriist nimetaks lahendamata sõltuvuse, selle asemel et anda teile kokkuvõte. Seejärel küsige, kas teie väljalaskel on üldse mõni kandidaat, sest „siin pole saadaval“ ja „selles mirroris ajutiselt puudub“ viivad täiesti erinevate otsusteni:

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

Kui apt-cache policy ei teata ühtegi kandidaati, lõpetage selle paigaldamise proovimine ja hakake alternatiivi valima. Huvitav ei ole puuduva paketi nimi; huvitav on see, et tootja sõltuvusgraaf ei ole liikunud koos distributsioonidega, mida teie kasutajad kasutavad.

Mida vanade pakettide pealesurumine töölauaga teeb

Ringlev lahendus on tõmmata teek vanemast väljalaskest. Praegusel Ubuntul lõpeb see Qt5 alaveriooni konfliktiga: vanemad paketid tõmbavad libqt5core5t64 tagasi ja siis hakkavad paigaldatud KDE ja PyQt paketid nõudma ABI versiooni, mida alandatud teek enam ei paku. Tulemuseks on osaline uuendus, mis lõhub seotud rakendusi, mis on palju hullem pärastlõuna kui see, millega alustasite.

See tulemus on oodatav, mitte õnnetu. Qti ABI ootused alaverioonidele on ranged ja distributsioon tarnib ühe sidusa komplekti. Ühe teegi segamine teisest väljalaskest ei ole sihitud parandus; see on teine, vähem kontrollitud uuendus.

Sama nõuanne kehtib rikke käitusaja variandi kohta. OpenSSL-i süsteemse turvataseme langetamine, et vana kliendi kätlemine õnnestuks, muudab masinas iga TLS-ühendust, et parandada üht rakendust, sealhulgas paketihaldurit, mida vajate, kui midagi muud katki läheb.

openconnect räägib seda protokolli

OpenConnect rakendab GlobalProtecti protokolli otse ja protokolli märkmed kirjeldavad nii väljakutset kui ka kahe serveriliidese vahelist jaotust. Portaal jagab seadeid ja lüüside loendit; lüüs lõpetab tunneli:

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

Kui portaal jätab vajaliku lüüsi välja, --usergroup=gateway või /gateway lõpuga URL jätab portaali sammu vahele. Kui pakutakse mitut lüüsi, --authgroup=NAME valib nende hulgast. Autentimine on kasutajanimi ja parool, soovi korral kliendisertifikaadiga, ja SAMLi lüüsid töötavad praktikas network-manager-openconnect kaudu, mitte käsitsi trükitud käsurealt.

Range posture-poliitikaga lüüs võib enne tunneli andmist nõuda ka HIP-aruannet. OpenConnect suudab selle koostada ja esitada, aga kui lüüs nõuab inventuuri, mida see koostada ei suuda, ei muuda ükski lipp seda poliitikat; see on serveripoolne otsus.

Kontrollige tunnelit ja teadke, mida openconnect ei paranda

Kontrollige, mida tunnel tegelikult rakendas, selle asemel et usaldada õnnestumisteatist. Lüüs saadab marsruutimise ja konfiguratsiooni XML-ina ja klient rakendab selle, seega puuduv marsruut on konfiguratsiooni või valiku probleem, mitte kliendi viga:

ip -4 addr show
ip route
resolvectl status

MTU väärib eraldi pilku. GlobalProtecti konfiguratsioon teatab alati MTU-ks nulli, seega klient hindab selle kapseldamise üldkulust. Suured ülekanded, mis takerduvad, samal ajal kui väikesed päringud lähevad läbi, on klassikaline sümptom, ja ravim on selgesõnaline MTU ühendusel, mitte teeavastuse väljalülitamine.

IPv6 on jälle omaette teema. PAN lisas selle GlobalProtect 4.0-sse ja OpenConnecti tuge kirjeldatakse versioonist 9.0 alates eksperimentaalsena, seega ärge eeldage, et aadresside perekond käitub nagu IPv4, ainult sellepärast et tunnel tõusis. Ja kui lüüs nõuab posture-kontrolli, mida avatud lähtekoodiga klient täita ei suuda, käivitage tootja klient toetatud LTS-väljalaskel, virtuaalmasinas, kui teie tööjaam on juba edasi liikunud. See hoiab töölaua terve ja paneb pärandkohase sõltuvuse piiri sisse, mille saate uuesti üles ehitada.