योग्य गृहीतक असे आहे की तुमच्या 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 किंवा असा 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 आवृत्तीवर चालवा, व्हर्च्युअल मशीनमध्ये जर तुमचे वर्कस्टेशन पुढे गेले असेल। यामुळे डेस्कटॉप सुरक्षित राहतो आणि जुने अवलंबित्व अशा मर्यादेत ठेवते जी तुम्ही पुन्हा बांधू शकता।

संबंधित लेख