Чому клієнт 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, у віртуальній машині, якщо ваша робоча станція вже пішла далі. Це зберігає робочий стіл цілим і кладе застарілу залежність усередину межі, яку ви можете перезібрати.