కొత్త Ubuntu పై GlobalProtect Linux క్లయింట్ ఎందుకు విఫలమవుతుంది
.deb సరిగ్గా ఉంది: కొత్త Ubuntu విడుదలలు Qt5 WebKit ను తొలగించాయి, దానితో విక్రేత ఇంటర్ఫేస్ ఇప్పటికీ లింక్ అయి ఉంది. డిపెండెన్సీని నిర్ధారించి, తర్వాత openconnect లేదా పాత LTS ఎంచుకోండి.
సహేతుకమైన ఊహ ఏమిటంటే మీ GlobalProtect పోర్టల్ నుండి వచ్చిన .deb పాడైంది, లేదా విక్రేత చెడ్డ బిల్డ్ విడుదల చేసింది. సాధారణంగా అలా ఉండదు. విక్రేత 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 విడుదలపై నడపండి, మీ వర్క్స్టేషన్ ముందుకు సాగి ఉంటే వర్చువల్ మెషీన్లో. ఇది డెస్క్టాప్ను కాపాడి పాత డిపెండెన్సీని మళ్లీ నిర్మించగల హద్దులో ఉంచుతుంది.