Kohtuullinen oletus on, että GlobalProtect-portaalistasi saatu .deb on rikki tai että toimittaja toimitti huonon buildin. Yleensä ei ole. Toimittajan Linux-käyttöliittymä linkittyy edelleen Qt5 WebKitiin, eivätkä uudemmat Ubuntu-julkaisut enää toimita sitä, joten paketti pyytää kirjastoa, jonka jakelusi poisti tarkoituksella. Kyse on paketointien yhteensopimattomuudesta, ei vioittuneesta latauksesta, ja tämä ero ratkaisee, vietätkö iltapäivän pakottelemalla paketteja vai kymmenen minuuttia valitsemalla toisen asiakasohjelman.

Paketti .deb ei ole rikki

Riippuvuus, jota jakelu ei enää sisällä, on kirjaston käytöstä poistamisen normaali seuraus. Qt5 WebKit poistettiin myöhemmistä Ubuntu-arkistoista ja Debianista, ja syynä oli tietoturvaylläpito, ei kysynnän puute. Kun niin käy, jokainen paketti, joka linkittyy siihen edelleen, lakkaa olemasta asennettavissa, riippumatta siitä, miten hyvin se rakennettiin.

Kaksi vikaa raportoidaan samana bugina, eivätkä ne ole sama. Julkaisussa ilman kirjastoa asentaja pysähtyy tyydyttämättömään riippuvuuteen. Julkaisussa, jossa asiakasohjelma asentuu ja epäonnistuu sitten kirjautumisessa, näetkin upotetun selainkomponentin sisäisen TLS- tai SAML-kättelyn ongelman. Ensimmäinen on paketointia; toinen on ajonaikaista, eikä kumpaakaan korjata kopioimalla vanhoja kirjastoja nykyaikaiseen työpöytään.

Vahvista riippuvuus pakottamisen sijaan

Asenna paketti eksplisiittisesti, jotta työkalu nimeää ratkaisemattoman riippuvuuden sen sijaan että antaisi yhteenvedon. Kysy sitten, onko julkaisullasi ylipäätään ehdokasta, sillä ”ei saatavilla täällä” ja ”tilapäisesti puuttuu tästä peilistä” johtavat täysin erilaisiin päätöksiin:

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

Jos apt-cache policy ei ilmoita yhtään ehdokasta, lopeta sen asentamisen yrittäminen ja ala valita vaihtoehtoa. Kiinnostavaa ei ole puuttuvan paketin nimi; kiinnostavaa on se, että toimittajan riippuvuusgraafi ei ole liikkunut niiden jakelujen mukana, joita käyttäjäsi ajavat.

Mitä vanhojen pakettien pakottaminen tekee työpöydälle

Kiertävä kiertotie on vetää kirjasto vanhemmasta julkaisusta. Nykyisessä Ubuntussa se päätyy Qt5:n alaversiokonfliktiin: vanhemmat paketit vetävät libqt5core5t64 taaksepäin, ja sitten asennetut KDE- ja PyQt-paketit alkavat vaatia ABI-versiota, jota alennettu kirjasto ei enää tarjoa. Tuloksena on osittainen päivitys, joka rikkoo asiaankuulumattomia sovelluksia, eli paljon huonompi iltapäivä kuin se, jolla aloitit.

Tuo tulos on odotettavissa eikä huonoa onnea. Qt:n ABI-odotukset alaversioille ovat tiukat, ja jakelu toimittaa yhden yhtenäisen joukon. Yhden kirjaston sekoittaminen toisesta julkaisusta ei ole kohdennettu korjaus; se on toinen, heikommin hallittu päivitys.

Sama neuvo pätee vian ajonaikaiseen muotoon. OpenSSL:n järjestelmänlaajuisen turvatason laskeminen, jotta vanhan asiakasohjelman kättely onnistuu, muuttaa koneen jokaista TLS-yhteyttä yhden sovelluksen korjaamiseksi, mukaan lukien paketinhallinta, jota tarvitset, kun jotain muuta hajoaa.

openconnect puhuu protokollaa

OpenConnect toteuttaa GlobalProtectin protokollan suoraan, ja protokollamuistiinpanot kuvaavat sekä kutsun että kahden palvelinrajapinnan välisen jaon. Portaali jakaa asetukset ja yhdyskäytävien luettelon; yhdyskäytävä päättää tunnelin:

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

Jos portaali jättää pois tarvitsemasi yhdyskäytävän, --usergroup=gateway tai /gateway sisältävä URL ohittaa portaalivaiheen. Kun tarjolla on useita yhdyskäytäviä, --authgroup=NAME valitsee niiden joukosta. Todennus on käyttäjänimi ja salasana, halutessa asiakasvarmenne, ja SAML-yhdyskäytävät toimivat käytännössä network-manager-openconnect kautta eikä käsin kirjoitetulla komentorivillä.

Tiukan posture-käytännön yhdyskäytävä voi myös vaatia HIP-raportin ennen tunnelin luovuttamista. OpenConnect osaa luoda ja lähettää sellaisen, mutta jos yhdyskäytävä vaatii inventaarion, jota se ei pysty tuottamaan, mikään vipu ei muuta tätä käytäntöä; se on palvelinpuolen päätös.

Varmista tunneli ja tiedä, mitä openconnect ei korjaa

Tarkista, mitä tunneli todella sovelsi, sen sijaan että luotat onnistumisviestiin. Yhdyskäytävä lähettää reitityksen ja kokoonpanon XML:nä ja asiakasohjelma soveltaa sen, joten puuttuva reitti on kokoonpanon tai valinnan ongelma eikä asiakasohjelman bugi:

ip -4 addr show
ip route
resolvectl status

MTU ansaitsee oman katsauksensa. GlobalProtect-kokoonpano ilmoittaa aina MTU:ksi nollan, joten asiakasohjelma arvioi sen kapselointilisästä. Suuret siirrot, jotka pysähtyvät pienten pyyntöjen mennessä läpi, ovat klassinen oire, ja lääke on eksplisiittinen MTU yhteydellä eikä polunetsinnän sammuttaminen.

IPv6 on jälleen eri asia. PAN lisäsi sen GlobalProtect 4.0:aan, ja OpenConnectin tuki kuvataan kokeelliseksi versiosta 9.0 alkaen, joten älä oleta, että osoiteperhe käyttäytyy kuin IPv4 vain siksi, että tunneli nousi. Ja jos yhdyskäytävä vaatii posture-tarkistuksen, jota avoimen lähdekoodin asiakasohjelma ei voi täyttää, aja toimittajan asiakasohjelmaa tuetulla LTS-julkaisulla, virtuaalikoneessa jos työasemasi on jo siirtynyt eteenpäin. Se pitää työpöydän ehjänä ja sijoittaa perintöriippuvuuden rajaan, jonka voit rakentaa uudelleen.

Aiheeseen liittyvät artikkelit