Nima uchun GlobalProtect Linux mijozi yangi Ubuntu'da ishlamaydi

O'rinli taxmin shuki, GlobalProtect portalingizdan olingan .deb buzilgan yoki vendor yomon build chiqargan. Odatda unday emas. Vendorning Linux interfeysi hali ham Qt5 WebKit bilan bog'lanadi, yangi Ubuntu nashrlari esa uni endi yetkazib bermaydi, shuning uchun paket distributivingiz ataylab olib tashlagan kutubxonani so'raydi. Bu paketlash nomuvofiqligi, buzilgan yuklab olish emas, va bu farq tushdan keyingi vaqtni paketlarni majburlashga yoki o'n daqiqani boshqa mijoz tanlashga sarflashingizni hal qiladi.

.deb buzilmagan

Distributiv endi olib yurmaydigan bog'liqlik kutubxonaning iste'moldan chiqarilishining odatiy natijasidir. Qt5 WebKit keyingi Ubuntu arxivlaridan va Debian'dan olib tashlandi, sabab esa talab yo'qligi emas, xavfsizlik xizmati edi. Bu sodir bo'lganda, u bilan hali ham bog'langan har bir paket qanchalik yaxshi qurilgan bo'lsa ham o'rnatilmaydigan bo'ladi.

Ikki nosozlik bir xil xato deb xabar qilinadi va unday emas. Kutubxona yo'q nashrda o'rnatuvchi qanoatlanmagan bog'liqlikda to'xtaydi. Mijoz o'rnatilib, keyin kirishda muvaffaqiyatsiz bo'lgan nashrda esa siz o'rnatilgan brauzer komponenti ichidagi TLS yoki SAML qo'l siqish muammosini ko'rasiz. Birinchisi paketlash; ikkinchisi ishlash vaqti, va hech biri eski kutubxonalarni zamonaviy ish stoliga ko'chirish bilan tuzatilmaydi.

Bog'liqlikni majburlash o'rniga tasdiqlang

Paketni aniq o'rnating, shunda vosita hal qilinmagan bog'liqlikni nomlaydi, sizga xulosa bermaydi. So'ng nashringizda umuman nomzod bor-yo'qligini so'rang, chunki „bu yerda mavjud emas” va „bu oynada vaqtincha yo'q” butunlay boshqa qarorlarga olib keladi:

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

Agar apt-cache policy hech qanday nomzod haqida xabar bermasa, uni o'rnatishga urinishni to'xtating va alternativa tanlashni boshlang. Qiziq narsa yo'qolgan paket nomi emas; qiziq narsa vendorning bog'liqlik grafi foydalanuvchilaringiz ishlatadigan distributivlar bilan birga harakat qilmaganidir.

Eski paketlarni majburlash ish stoliga nima qiladi

Tarqalgan yechim kutubxonani eskiroq nashrdan tortib olishdir. Hozirgi Ubuntu'da bu Qt5 kichik versiya konfliktiga olib keladi: eski paketlar libqt5core5t64 orqaga tortadi, so'ng o'rnatilgan KDE va PyQt paketlari pasaytirilgan kutubxona endi bermaydigan ABI versiyasini talab qila boshlaydi. Natija bog'liq bo'lmagan ilovalarni buzadigan qisman yangilanishdir, bu esa boshlagan kuningizdan ancha yomonroq.

Bu natija kutilgan, omadsizlik emas. Qt ning kichik versiyalarga ABI kutishlari qat'iy, va bitta distributiv bitta uyg'un to'plam yetkazib beradi. Boshqa nashrdan bitta kutubxonani aralashtirish maqsadli tuzatish emas; bu ikkinchi, kamroq nazorat qilinadigan yangilanish.

Xuddi shu maslahat nosozlikning ishlash vaqti variantiga ham tegishli. Eski mijozning qo'l siqishi muvaffaqiyatli bo'lishi uchun OpenSSL ning tizim bo'ylab xavfsizlik darajasini pasaytirish bitta ilovani tuzatish uchun mashinadagi har bir TLS ulanishini o'zgartiradi, jumladan boshqa narsa buzilganda kerak bo'ladigan paket menejerini ham.

openconnect bu protokolda gapiradi

OpenConnect GlobalProtect protokolini to'g'ridan-to'g'ri amalga oshiradi, va protokol eslatmalari chaqiruvni ham, ikkita server interfeysi o'rtasidagi bo'linishni ham tasvirlaydi. Portal sozlamalar va shlyuzlar ro'yxatini tarqatadi; shlyuz tunnelni tugatadi:

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

Agar portal sizga kerakli shlyuzni tashlab ketsa, --usergroup=gateway yoki oxiri /gateway bilan tugaydigan URL portal qadamini o'tkazib yuboradi. Bir nechta shlyuz taklif qilinsa, --authgroup=NAME ularning orasidan tanlaydi. Autentifikatsiya foydalanuvchi nomi va parol, ixtiyoriy ravishda mijoz sertifikati bilan, SAML shlyuzlari esa amalda network-manager-openconnect orqali ishlaydi, qo'lda yozilgan buyruq satri orqali emas.

Qat'iy posture siyosatiga ega shlyuz tunnel berishdan oldin HIP hisobotini ham talab qilishi mumkin. OpenConnect uni yaratib yubora oladi, lekin agar shlyuz yarata olmaydigan inventar talab qilsa, hech qanday bayroq bu siyosatni o'zgartirmaydi; bu server tomonidagi qaror.

Tunnelni tekshiring va openconnect nimani tuzatmasligini biling

Muvaffaqiyat xabariga ishonish o'rniga tunnel aslida nima qo'llaganini tekshiring. Shlyuz marshrutlash va konfiguratsiyani XML sifatida yuboradi va mijoz ularni qo'llaydi, shuning uchun yo'qolgan marshrut konfiguratsiya yoki tanlov muammosi, mijoz xatosi emas:

ip -4 addr show
ip route
resolvectl status

MTU alohida qarashga loyiq. GlobalProtect konfiguratsiyasi doim nol MTU haqida xabar beradi, shuning uchun mijoz uni inkapsulyatsiya xarajatidan baholaydi. Kichik so'rovlar o'tayotganda tiqilib qoladigan katta uzatmalar klassik simptomdir, davo esa yo'l aniqlashni o'chirish emas, ulanishda aniq MTU dir.

IPv6 yana alohida mavzu. PAN uni GlobalProtect 4.0 da qo'shdi, OpenConnect qo'llab-quvvatlashi esa 9.0 versiyasidan boshlab eksperimental deb ta'riflanadi, shuning uchun tunnel ko'tarildi deb manzillar oilasi IPv4 kabi ishlaydi deb o'ylamang. Va agar shlyuz ochiq kodli mijoz bajara olmaydigan posture tekshiruvini talab qilsa, vendor mijozini qo'llab-quvvatlanadigan LTS nashrida ishlating, ish stansiyangiz oldinga ketgan bo'lsa virtual mashinada. Bu ish stolini buzilmasdan saqlaydi va eski bog'liqlikni qayta qurishingiz mumkin bo'lgan chegara ichiga qo'yadi.