Niyə GlobalProtect Linux klienti daha yeni Ubuntu-da uğursuz olur

Ağlabatan fərziyyə odur ki, GlobalProtect portalınızdan gələn .deb xarabdır və ya satıcı pis build buraxıb. Adətən belə deyil. Satıcının Linux interfeysi hələ də Qt5 WebKit ilə bağlanır, daha yeni Ubuntu buraxılışları isə onu artıq təqdim etmir, ona görə paket distribusiyanızın qəsdən sildiyi kitabxananı tələb edir. Bu, paketləmə uyğunsuzluğudur, korlanmış yükləmə deyil, və bu fərq günortadan sonrakı vaxtı paketləri məcbur etməyə və ya on dəqiqəni başqa klient seçməyə sərf edəcəyinizi müəyyən edir.

.deb xarab deyil

Distribusiyanın artıq daşımadığı asılılıq kitabxananın istifadədən çıxarılmasının normal nəticəsidir. Qt5 WebKit sonrakı Ubuntu arxivlərindən və Debian-dan çıxarıldı, səbəb isə tələbin olmaması deyil, təhlükəsizlik xidməti idi. Bu baş verdikdə, onunla hələ də bağlanan hər bir paket nə qədər yaxşı qurulsa da, quraşdırıla bilməz olur.

İki nasazlıq eyni baq kimi bildirilir və elə deyil. Kitabxana olmayan buraxılışda quraşdırıcı ödənilməmiş asılılıqda dayanır. Klientin quraşdırıldığı və sonra girişdə uğursuz olduğu buraxılışda isə siz əvəzində quraşdırılmış brauzer komponentinin içində TLS və ya SAML əl sıxma problemini görürsünüz. Birincisi paketləmədir; ikincisi icra vaxtıdır və heç biri köhnə kitabxanaları müasir masaüstünə kopyalamaqla düzəlmir.

Asılılığı məcbur etmək əvəzinə təsdiqləyin

Paketi açıq şəkildə quraşdırın ki, alət həll olunmamış asılılığı adlandırsın, sizə xülasə verməsin. Sonra soruşun ki, buraxılışınızda ümumiyyətlə namizəd varmı, çünki „burada mövcud deyil” və „bu güzgüdə müvəqqəti yoxdur” tamamilə fərqli qərarlara aparır:

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

Əgər apt-cache policy heç bir namizəd bildirmirsə, onu quraşdırmağa çalışmağı dayandırın və alternativ seçməyə başlayın. Maraqlı olan itkin paket adı deyil; maraqlı olan satıcının asılılıq qrafının istifadəçilərinizin işlətdiyi distribusiyalarla birlikdə hərəkət etməməsidir.

Köhnə paketləri məcbur etmək masaüstünə nə edir

Dolaşan həll yolu kitabxananı daha köhnə buraxılışdan çəkməkdir. Mövcud Ubuntu-da bu, Qt5 kiçik versiya konfliktinə gətirib çıxarır: köhnə paketlər libqt5core5t64 geri çəkir, sonra quraşdırılmış KDE və PyQt paketləri aşağı salınmış kitabxananın artıq təqdim etmədiyi ABI versiyasını tələb etməyə başlayır. Nəticə əlaqəsiz tətbiqləri sındıran qismən yeniləmədir, bu isə başladığınız gündən qat-qat pisdir.

Bu nəticə gözləniləndir, bədbəxtlik deyil. Qt-nin kiçik versiyalara dair ABI gözləntiləri sərtdir və bir distribusiya bir ahəngdar dəst təqdim edir. Başqa buraxılışdan bir kitabxananı qarışdırmaq məqsədli düzəliş deyil; bu, ikinci, daha az nəzarət olunan yeniləmədir.

Eyni məsləhət nasazlığın icra vaxtı variantına da aiddir. Köhnə klientin əl sıxması uğurlu olsun deyə OpenSSL-in sistem üzrə təhlükəsizlik səviyyəsini aşağı salmaq bir tətbiqi düzəltmək üçün maşındakı hər TLS bağlantısını dəyişir, o cümlədən başqa bir şey sındıqda lazım olacaq paket menecerini.

openconnect bu protokolla danışır

OpenConnect GlobalProtect protokolunu birbaşa tətbiq edir və protokol qeydləri həm çağırışı, həm də iki server interfeysi arasındakı bölgünü təsvir edir. Portal parametrləri və şlüz siyahısını paylayır; şlüz tuneli bitirir:

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

Əgər portal sizə lazım olan şlüzü buraxmırsa, --usergroup=gateway və ya sonu /gateway ilə bitən URL portal addımını atlayır. Bir neçə şlüz təklif olunanda, --authgroup=NAME onların arasından seçir. Autentifikasiya istifadəçi adı və paroldur, istəyə bağlı olaraq klient sertifikatı ilə, SAML şlüzləri isə praktikada network-manager-openconnect vasitəsilə işləyir, əl ilə yazılmış əmr sətri ilə deyil.

Sərt posture siyasəti olan şlüz tunel verməzdən əvvəl HIP hesabatı da tələb edə bilər. OpenConnect onu yaradıb göndərə bilər, lakin şlüz yarada bilmədiyi inventar tələb edirsə, heç bir bayraq bu siyasəti dəyişmir; bu, server tərəfindəki qərardır.

Tuneli yoxlayın və openconnect-in nəyi düzəltməyəcəyini bilin

Uğur mesajına güvənmək əvəzinə tunelin həqiqətən nə tətbiq etdiyini yoxlayın. Şlüz marşrutlaşdırma və konfiqurasiyanı XML kimi göndərir və klient onları tətbiq edir, ona görə itkin marşrut konfiqurasiya və ya seçim problemidir, klient xətası deyil:

ip -4 addr show
ip route
resolvectl status

MTU ayrıca baxışa layiqdir. GlobalProtect konfiqurasiyası həmişə sıfır MTU bildirir, ona görə klient onu inkapsulyasiya xərcindən təxmin edir. Kiçik sorğular keçərkən ilişib qalan böyük ötürmələr klassik simptomdur, dərman isə yol aşkarlanmasını söndürmək deyil, bağlantıda açıq MTU-dur.

IPv6 yenə ayrı mövzudur. PAN onu GlobalProtect 4.0-da əlavə etdi və OpenConnect dəstəyi 9.0 versiyasından eksperimental kimi təsvir olunur, ona görə tunel qalxdı deyə ünvan ailəsinin IPv4 kimi davrandığını güman etməyin. Və əgər şlüz açıq mənbə klientinin yerinə yetirə bilmədiyi posture yoxlaması tələb edirsə, satıcı klientini dəstəklənən LTS buraxılışında işlədin, iş stansiyanız irəli getmişsə virtual maşında. Bu, masaüstünü toxunulmaz saxlayır və köhnə asılılığı yenidən qura biləcəyiniz sərhədin içinə qoyur.