Kial la GlobalProtect Linux-kliento fiaskas sur pli novaj Ubuntu

La racia supozo estas, ke la .deb el via GlobalProtect-portalo estas difektita, aŭ ke la vendanto liveris fuŝan konstruaĵon. Kutime ĝi ne estas. La Linux-fasado de la vendanto ankoraŭ ligiĝas al Qt5 WebKit, kaj la pli novaj Ubuntu-eldonoj ne plu liveras ĝin, do la pako petas bibliotekon, kiun via distribuo intence forigis. Tio estas pakaĵa malkongruo, ne difektita elŝuto, kaj tiu diferenco decidas, ĉu vi pasigos la posttagmezon devigante pakojn aŭ dek minutojn elektante alian klienton.

La .deb ne estas difektita

Dependo, kiun la distribuo ne plu portas, estas normala sekvo de malŝaltado de biblioteko. Qt5 WebKit estis forigita el pli postaj Ubuntu-arkivoj kaj el Debian, kaj la kialo estis sekureca prizorgado, ne manko de postulo. Kiam tio okazas, ĉiu pako, kiu ankoraŭ ligiĝas al ĝi, ĉesas esti instalebla, kiom ajn bone ĝi estis konstruita.

Du paneoj estas raportataj kiel la sama cimo kaj ne estas. Sur eldono sen la biblioteko, la instalilo haltas ĉe neplenumita dependo. Sur eldono, kie la kliento instaliĝas kaj poste fiaskas ĉe ensaluto, vi fakte vidas TLS- aŭ SAML-manpreman problemon ene de la enkonstruita retumila komponanto. La unua estas pakaĵado; la dua estas rultempo, kaj neniu el ili ripariĝas per kopiado de malnovaj bibliotekoj en modernan labortablon.

Konfirmu la dependon anstataŭ devigi ĝin

Instalu la pakon eksplicite, por ke la ilo nomu la nesolvitan dependon anstataŭ doni al vi resumon. Poste demandu, ĉu via eldono entute havas kandidaton, ĉar „ne disponebla ĉi tie” kaj „provizore mankanta el ĉi tiu spegulo” kondukas al tute diversaj decidoj:

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

Se apt-cache policy ne raportas eĉ unu kandidaton, ĉesu provi instali ĝin kaj komencu elekti alternativon. La interesaĵo ne estas la mankanta paknomo; ĝi estas la fakto, ke la dependografo de la vendanto ne moviĝis kune kun la distribuaĵoj, kiujn uzas viaj uzantoj.

Kion devigado de malnovaj pakoj faras al la labortablo

La solvo, kiu cirkulas, estas eltiri la bibliotekon el pli malnova eldono. Sur nuna Ubuntu tio finiĝas en konflikto de malĉefa versio de Qt5: la pli malnovaj pakoj tiras libqt5core5t64 malantaŭen, kaj tiam la instalitaj KDE- kaj PyQt-pakoj komencas postuli ABI-version, kiun la degradita biblioteko ne plu provizas. La rezulto estas parta ĝisdatigo, kiu rompas nerilatajn aplikaĵojn, kio estas multe pli malbona posttagmezo ol tiu, kun kiu vi komencis.

Tiu rezulto estas atendata, ne malfeliĉa. La ABI-atendoj de Qt pri malĉefaj versioj estas striktaj, kaj distribuo liveras unu koheran aron. Enmiksi unu bibliotekon el alia eldono ne estas celita riparo; ĝi estas dua, malpli kontrolita ĝisdatigo.

La sama konsilo validas por la rultempa varianto de la paneo. Malaltigi la sistemampleksan sekurecnivelon de OpenSSL, por ke la manpremo de malnova kliento sukcesu, ŝanĝas ĉiun TLS-konekton sur la maŝino por ripari unu aplikaĵon, inkluzive de la pakadministrilo, kiun vi bezonos kiam io alia rompiĝos.

openconnect parolas la protokolon

OpenConnect rekte implementas la protokolon de GlobalProtect, kaj la protokolaj notoj priskribas kaj la alvokon kaj la dividon inter la du servilaj interfacoj. La portalo disdonas agordojn kaj la liston de pordegoj; la pordego finas la tunelon:

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

Se la portalo preterlasas la pordegon, kiun vi bezonas, --usergroup=gateway aŭ URL, kiu finiĝas per /gateway preterlasas la portal-paŝon. Kiam pluraj pordegoj estas proponataj, --authgroup=NAME elektas inter ili. Aŭtentigo estas uzantnomo kaj pasvorto, laŭbezone kun klienta atestilo, kaj SAML-pordegoj praktike funkcias per network-manager-openconnect anstataŭ per mane tajpita komandlinio.

Pordego kun strikta posture-politiko povas ankaŭ postuli HIP-raporton antaŭ ol doni tunelon. OpenConnect povas generi kaj sendi unu, sed se la pordego postulas inventaron, kiun ĝi ne povas produkti, neniu agordo ŝanĝas tiun politikon; tio estas decido ĉe la servila flanko.

Kontrolu la tunelon kaj sciu, kion openconnect ne riparos

Kontrolu, kion la tunelo efektive aplikis, anstataŭ fidi la sukcesan mesaĝon. La pordego sendas enkursigadon kaj agordon kiel XML kaj la kliento aplikas ilin, do mankanta vojo estas agorda aŭ elekta problemo, ne eraro de la kliento:

ip -4 addr show
ip route
resolvectl status

MTU meritas propran rigardon. La agordo de GlobalProtect ĉiam raportas MTU de nulo, do la kliento taksas ĝin el la enkapsuliga superkosto. Grandaj transigoj, kiuj blokiĝas dum malgrandaj petoj trapasas, estas la klasika simptomo, kaj la rimedo estas eksplicita MTU sur la konekto anstataŭ malŝalti vojretrovadon.

IPv6 denove estas aparta afero. PAN aldonis ĝin en GlobalProtect 4.0, kaj la subteno en OpenConnect estas priskribata kiel eksperimenta ekde versio 9.0, do ne supozu, ke la adresfamilio kondutas kiel IPv4 nur ĉar la tunelo leviĝis. Kaj se la pordego trudas posture-kontrolon, kiun la malfermkoda kliento ne povas plenumi, rulu la klienton de la vendanto sur subtenata LTS-eldono, en virtuala maŝino se via laborsubtenilo jam antaŭeniris. Tio konservas la labortablon sendifekta kaj metas la heredan dependon en limon, kiun vi povas rekonstrui.