Защо Linux клиентът на GlobalProtect не работи на по-новите 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, във виртуална машина, ако работната ви станция вече е отишла напред. Това запазва работния плот непокътнат и поставя остарялата зависимост в граница, която можете да изградите отново.