Ինչու է GlobalProtect-ի Linux հաճախորդը ձախողվում նոր Ubuntu-ներում

Խելամիտ ենթադրությունն այն է, որ ձեր GlobalProtect պորտալից ստացված .deb-ը վնասված է, կամ մատակարարը թողարկել է վատ build։ Սովորաբար այդպես չէ։ Մատակարարի 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 կամ /gateway վերջացող URL-ը շրջանցում է պորտալի քայլը։ Երբ առաջարկվում են մի քանի դարպասներ, --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 թողարկման վրա, վիրտուալ մեքենայում, եթե ձեր աշխատանքային կայանը արդեն առաջ է գնացել։ Դա աշխատասեղանը պահում է անվնաս և հին կախվածությունը դնում է սահմանի ներսում, որը կարող եք վերակառուցել։