Чаму кліент GlobalProtect для Linux не працуе на новых Ubuntu

Разумнае меркаванне — што .deb з вашага партала GlobalProtect пашкоджаны або што вытворца выпусціў дрэнную зборку. Звычайна гэта не так. Linux-інтэрфейс вытворцы дагэтуль лінкуецца з Qt5 WebKit, а новыя выпускі Ubuntu яго больш не пастаўляюць, таму пакет просіць бібліятэку, якую вашая дыстрыбуцыя прыбрала наўмысна. Гэта неадпаведнасць пакавання, а не сапсаванае спампоўванне, і гэтая розніца вырашае, ці правядзеце вы дзень, фарсуючы пакеты, ці дзесяць хвілін, выбіраючы іншы кліент.

Пакет .deb не пашкоджаны

Залежнасць, якую дыстрыбуцыя больш не нясе, — звычайны вынік вывядзення бібліятэкі з ужытку. Qt5 WebKit знік з позніх архіваў Ubuntu і з Debian, і прычынай было суправаджэнне бяспекі, а не недахоп попыту. Калі гэта адбываецца, кожны пакет, які дагэтуль з ёй лінкуецца, перастае ўсталёўвацца, як бы добра ён ні быў сабраны.

Дзве адмовы падаюцца як тая самая памылка і такімі не з’яўляюцца. У выпуску без бібліятэкі ўсталёўшчык спыняецца на незадаволенай залежнасці. У выпуску, дзе кліент усталёўваецца і потым падае пры ўваходзе, вы бачыце замест гэтага праблему рукапаціскання TLS або SAML унутры ўбудаванага кампанента браўзера. Першае — пакаванне; другое — асяроддзе выканання, і ні тое, ні другое не выпраўляецца капіраваннем старых бібліятэк у сучасны працоўны стол.

Пацвердзіць залежнасць замест таго, каб фарсаваць яе

Усталюйце пакет яўна, каб інструмент назваў нявырашаную залежнасць, а не выдаў вам зводку. Затым спытайце, ці ёсць у вашым выпуску хоць які кандыдат, бо «тут недаступна» і «часова адсутнічае ў гэтым люстэрку» вядуць да цалкам розных рашэнняў:

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

Калі apt-cache policy не паведамляе ніводнага кандыдата, спыніце спробы ўсталяваць яго і пачніце выбіраць альтэрнатыву. Цікавае не імя адсутнага пакета; цікавы той факт, што граф залежнасцей вытворцы не зрушыў разам з дыстрыбуцыямі, якія выкарыстоўваюць вашыя карыстальнікі.

Што фарсаванне старых пакетаў робіць з працоўным сталом

Абыходны шлях, які ходзіць па руках, — выцягнуць бібліятэку са старэйшага выпуску. На актуальнай Ubuntu гэта выліваецца ў канфлікт мінорнай версіі Qt5: старыя пакеты цягнуць libqt5core5t64 назад, і тады ўсталяваныя пакеты KDE і PyQt пачынаюць патрабаваць версію ABI, якую паніжаная бібліятэка больш не прадастаўляе. Вынік — частковае абнаўленне, якое ламае староннія праграмы, а гэта значна горшы дзень, чым той, з якога вы пачалі.

Такі вынік чаканы, а не няшчасны. Чаканні Qt адносна ABI для мінорных версій строгія, а дыстрыбуцыя пастаўляе адзін узгоднены набор. Падмяшаць бібліятэку з іншага выпуску — не кропкавае выпраўленне; гэта другое, горш кантраляванае абнаўленне.

Той жа савет датычыцца варыянта адмовы падчас выканання. Зніжэнне агульнасістэмнага ўзроўню бяспекі OpenSSL, каб рукапацісканне старога кліента ўдалося, змяняе кожнае TLS-злучэнне на машыне дзеля выпраўлення адной праграмы, уключна з мэнэджарам пакетаў, які спатрэбіцца, калі зламаецца нешта іншае.

openconnect гаворыць гэтым пратаколам

OpenConnect рэалізуе пратакол GlobalProtect напроста, а нататкі пра пратакол апісваюць і выклік, і падзел паміж двума сервернымі інтэрфейсамі. Партал раздае налады і спіс шлюзаў; шлюз завяршае тунэль:

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

Калі партал не ўказвае патрэбны вам шлюз, --usergroup=gateway або URL, які сканчаецца на /gateway прапускае крок партала. Калі прапануецца некалькі шлюзаў, --authgroup=NAME выбірае сярод іх. Аўтэнтыфікацыя — гэта імя карыстальніка і пароль, пры патрэбе з кліенцкім сертыфікатам, а шлюзы SAML на практыцы працуюць праз network-manager-openconnect а не праз набраны ўручную камандны радок.

Шлюз з суровай палітыкай posture можа таксама патрабаваць звестак HIP, перш чым выдаць тунэль. OpenConnect умее сфармаваць і адправіць іх, але калі шлюз патрабуе інвентарызацыю, якую ён не можа стварыць, ніводзін сцяжок гэтай палітыкі не зменіць; гэта рашэнне на баку сервера.

Праверыць тунэль і ведаць, чаго openconnect не выправіць

Праверце, што тунэль сапраўды прымяніў, замест таго каб верыць паведамленню пра поспех. Шлюз дасылае маршрутызацыю і канфігурацыю як XML, а кліент іх прымяняе, таму адсутны маршрут — гэта праблема канфігурацыі або выбару, а не памылка кліента:

ip -4 addr show
ip route
resolvectl status

MTU заслугоўвае асобнага позірку. Канфігурацыя GlobalProtect заўсёды паведамляе MTU, роўны нулю, таму кліент ацэньвае яго з накладных выдаткаў інкапсуляцыі. Вялікія перадачы, якія застраваюць, тады як дробныя запыты праходзяць, — класічны сімптом, і лекі — яўны MTU на злучэнні, а не адключэнне выяўлення шляху.

IPv6 — зноў асобная гісторыя. PAN дадаў яго ў GlobalProtect 4.0, а падтрымка ў OpenConnect апісваецца як эксперыментальная пачынаючы з версіі 9.0, таму не лічыце, што сямейства адрасоў паводзіць сябе як IPv4 толькі таму, што тунэль падняўся. І калі шлюз патрабуе праверку posture, якую кліент з адкрытым кодам не можа прайсці, запускайце кліент вытворцы на падтрымліваным выпуску LTS, у віртуальнай машыне, калі вашая працоўная станцыя ўжо пайшла далей. Гэта захоўвае працоўны стол цэлым і кладзе састарэлую залежнасць усярэдзіне мяжы, якую вы можаце перасабраць.